- ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-565 ] ttf2afm fails to include characters specified with uniXXXX
by noreply＠sarovar.org 25 Jul '06

25 Jul '06

Bugs item #565, was opened at 2006-05-29 16:37 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=565&group_id=106 Category: None >Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: Mike Spivey (spivey) >Assigned to: The Thanh Han (hanthethanh) Summary: ttf2afm fails to include characters specified with uniXXXX Initial Comment: If characters are specified in an encoding vector as uniXXXX (with XXXX a hexadecimal unicode value), then these characters are not included in the AFM output, unlike characters that are specified by name. The same goes for characters specifed by position. A suggested patch is attached. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-07-25 19:46 Message: Logged In: YES user_id=421 Thanh, ttf2afm is your baby. :-) Pleae check. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=565&group_id=106

1 0

[ pdftex-Bugs-564 ] cannot compile pdftex under cygwin anymore
by noreply＠sarovar.org 25 Jul '06

25 Jul '06

Bugs item #564, was opened at 2006-05-26 02:31 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=564&group_id=106 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Robert (schlcht) Assigned to: Nobody (None) Summary: cannot compile pdftex under cygwin anymore Initial Comment: I've recently updated my cygwin system, and since then am not able to compile pdftex anymore. gcc -v gives: | gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) The last lines of build.sh's output are: | srcdir=../../../src/texk/web2c /bin/sh ../../../src/texk/web2c/web2c/convert tangleboot | gcc -DHAVE_CONFIG_H -I. -I../../../src/texk/web2c -I.. -I../../../src/texk/web2c/.. -g -O2 -c tangleboot.c -o tangleboot.o | In file included from tangleboot.c:94: | tangleboot.h:34: error: conflicting types for 'getline' | /usr/include/sys/stdio.h:31: error: previous declaration of 'getline' was here | tangleboot.h:34: error: conflicting types for 'getline' | /usr/include/sys/stdio.h:31: error: previous declaration of 'getline' was here | make: *** [tangleboot.o] Error 1 What to do? ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-05-26 03:05 Message: Logged In: NO It's a bug in Cygwin. See the following links: http://www.mail-archive.com/tetex@dbs.uni-hannover.de/msg00961.html http://ftp.tug.org/mail/archives/pdftex/2006-February/006370.html Best, v. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=564&group_id=106

1 0

[ pdftex-Feature Requests-573 ] add \ArtBox to pages
by noreply＠sarovar.org 25 Jul '06

25 Jul '06

Feature Requests item #573, was opened at 2006-06-20 07:32 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=573&group_id=106 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Alexei Gilchrist (alexei2) Assigned to: Martin Schröder (oneiros) Summary: add \ArtBox to pages Initial Comment: Hi, Is it possible to add an \ArtBox entry to the pages produces by pdftex (with a tight boundingbox)? This way the output of pdftex could be used as input into other progs that use pdf such as a pdf annotating tool. At the moment latex -> dvips -E -> dvitopdf seems to be the only way. thanks, Alexei ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-07-25 11:04 Message: Logged In: YES user_id=421 That would be hard to do, but can be easily done with other applications: gs -sDEVICE=bbox gives you the bounding box, and adding it to the pages should be easy with e.g. pdftk. ---------------------------------------------------------------------- Comment By: Alexei Gilchrist (alexei2) Date: 2006-07-25 03:04 Message: Logged In: YES user_id=3683 By "tight" I mean a boundingbox that contains just the added ink on a page, not the page bounding box. This way the output could be used by other programs that don't assume that TeX will be the final step in the production process. Imagine generating a latex equation as a pdf, then wanting to place that equation somewhere on a graph generated by other means - if you know a tight bounding box around that equation then it's pretty easy to place the pdf object in the right place. If all you've got is the page dimensions then it's pretty hopeless. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-24 23:55 Message: Logged In: YES user_id=421 You can already add it manually with \pdfpage{s}attr. But you probably want an automatic entry. Define "tight": pdfTeX knows only the MediaBox (i.e. page dimensions). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=573&group_id=106

1 0

[ pdftex-Feature Requests-573 ] add \ArtBox to pages
by noreply＠sarovar.org 25 Jul '06

25 Jul '06

Feature Requests item #573, was opened at 2006-06-20 05:32 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=573&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexei Gilchrist (alexei2) Assigned to: Martin Schröder (oneiros) Summary: add \ArtBox to pages Initial Comment: Hi, Is it possible to add an \ArtBox entry to the pages produces by pdftex (with a tight boundingbox)? This way the output of pdftex could be used as input into other progs that use pdf such as a pdf annotating tool. At the moment latex -> dvips -E -> dvitopdf seems to be the only way. thanks, Alexei ---------------------------------------------------------------------- >Comment By: Alexei Gilchrist (alexei2) Date: 2006-07-25 01:04 Message: Logged In: YES user_id=3683 By "tight" I mean a boundingbox that contains just the added ink on a page, not the page bounding box. This way the output could be used by other programs that don't assume that TeX will be the final step in the production process. Imagine generating a latex equation as a pdf, then wanting to place that equation somewhere on a graph generated by other means - if you know a tight bounding box around that equation then it's pretty easy to place the pdf object in the right place. If all you've got is the page dimensions then it's pretty hopeless. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-24 21:55 Message: Logged In: YES user_id=421 You can already add it manually with \pdfpage{s}attr. But you probably want an automatic entry. Define "tight": pdfTeX knows only the MediaBox (i.e. page dimensions). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=573&group_id=106

1 0

[ pdftex-Feature Requests-385 ] \pdfnoligatures should leave kerning intact
by noreply＠sarovar.org 25 Jul '06

25 Jul '06

Feature Requests item #385, was opened at 2005-07-10 17:38 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=385&group_id=106 Category: None Group: None >Status: Closed >Resolution: Postponed Priority: 5 Submitted By: Robert (schlcht) >Assigned to: Taco Hoekwater (taco) Summary: \pdfnoligatures should leave kerning intact Initial Comment: % The new \ptexnoligatures primitive will break the % horizontal positioning of \mathaccents if the base % character is slanted. % There is no problem with \accent, nor with \mathaccent % on upright characters: $\dot{A} \dot{\rm{A}} \dot{\Delta} \dot{\mit\Delta}$ {\tenit \accent'137 A} \ptexnoligatures\tenit % OK \ptexnoligatures\textfont0 % = cmr10, \rm % OK \ptexnoligatures\textfont1 % = cmmi10, \mit % breaks shift $\dot{A} \dot{\rm{A}} \dot{\Delta} \dot{\mit\Delta}$ {\tenit \accent'137 A} \bye, Robert ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-07-25 00:14 Message: Logged In: YES user_id=421 I think further effort on this is wasted, as \ptexnoligatures will be reimplemented with OpenType fonts anyway, i.e. in the near future. So we should just document the current behaviour and carry on. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-02-20 17:50 Message: Logged In: YES user_id=1608 Maybe we should just document the weird behaviour then and keep the thing marked experimental? I do not have lots of time to spend on this hack right now, nor do I want to, since everything I do now will have to be thrown out again for version 1.50. The change file that is attached to this feature item can then be ignored, except for that one line that re-enables \tagcode. ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-20 17:32 Message: Logged In: YES user_id=3344 Looking at Taco's change file, it should be possible to break his "non-vmode fix" by inserting \vbox{\pdfnoligatures\font} or \vadjust{\pdfligatures\font} in hmode. A final fix is to reimplement this \pdfnoligatures primitive: Either do not only change the |tag| field in the char_info for all font glyphs, but remove the ligs from the lig/kern program. Or save the information that no ligature should be constructed within the hlist (using a special node to start and end the nolig part similar to the setlanguage whatsit nodes or by adding the nolig flag to the character nodes). ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-02-20 16:40 Message: Logged In: YES user_id=2217 Ah, I didn't realize it had such confusing effects. However, I still believe that disallowing it in non-vmode is too restrictive. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-02-20 09:56 Message: Logged In: YES user_id=1608 But it is not global for the current paragraph, it is only applied to words that are looked at for hyphenation. Try this test, and have a close look at the first and third word of the paragraph. There are even stranger possibilities when \language is taken into account. \font\tst=cmr10 \hsize=2in \noindent \tst efficiency efficiency \hbox{efficiency} \pdfnoligatures\tst efficiency efficiency efficiency \bye ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-02-19 19:19 Message: Logged In: YES user_id=2217 In my opinion, this latest patch is too restrictive. It should be sufficient to document \pdfnoligatures as one of those commands whose scope is global to the current paragraph (and the rest of the document), just like setting, say, \hyphenpenalty or \hsize in the middle of a paragraph affects the complete paragraph. The current behaviour is also consistent with that of the hz-related stuff: \rpcode and friends have a retroactive effect, too. (Besides, the patch would break microtype.sty, which sets up the fonts as they are being loaded, which would happen in horizontal mode, mostly... ;-) PS. If it was for me, this feature request could be closed; I totally accept the "known limitation". ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-02-15 10:58 Message: Logged In: YES user_id=1608 The attached patch disallows \pdfnoligatures and \tagcode in non-vmodes, and restores the assignment functionality of \tagcode (that was an unrelated bug in 1.40-beta) ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-02-15 10:17 Message: Logged In: YES user_id=1608 We can disallow the primitive in non-vertical mode. Makes sense. ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-15 10:10 Message: Logged In: YES user_id=3344 Another limitation which should be documented: If \ptexnoligatures<font> is applied within a paragraph, the ligs and kerns created and inserted before this command are removed depending if a hyphenation pass is necessary to justify the paragraph. \ptexnoligatures<font> has the _global_ side effect to suppress all ligs and kerns of the font which are created _afterwards in time_. TeX breaks the lines of a paragraph at the end of the paragraph. If hyphenation has to be applied, ligs are remapped to single chars, (implicit) kerns are removed ... and reconstituted afterwards using the font information valid at this (later) time. If the font info is changed in between, which is true if \ptexnoligatures<font> is applied, already inserted ligs and kerns are removed. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-07-12 22:23 Message: Logged In: YES user_id=421 Changing this into a feature request. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-07-10 18:50 Message: Logged In: YES user_id=1608 This is because it (\ptexnoligatures) also disables the kerning information for the font. You'll have to accept that as a "known limitation" for now. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=385&group_id=106

1 0

[ pdftex-Feature Requests-572 ] non-compression of pdfxform
by noreply＠sarovar.org 25 Jul '06

25 Jul '06

Feature Requests item #572, was opened at 2006-06-10 23:11 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=572&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: ivo welch (iaw4) Assigned to: Nobody (None) Summary: non-compression of pdfxform Initial Comment: would it be possible to add a feature to avoid compression of the user defined pdfxform stream? [goal: I want to define a string that I can then change via a shell/perl script in the .pdf file itself. I know I have to keep the same number of characters.] \newcount\XOBJA \setbox1=\hbox{12345678909876543210123456789} % this is a special string that one can later replace in the pdf file by hand \pdfxform 1 \XOBJA=\pdflastxform \begin{document} Here is my string on page \arabic{page}: \pdfrefxform \XOBJA \end{document} $ sed 's/12345678909876543210123456789/for user pdftex.../' < myfile.pdf I experimented with setting pdfcompresslevel and resetting it, but it is not reliable in when compression starts. in any case, I do not want the rest at low compression, just my own XOBJ xform. regards, /iaw ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-07-25 00:02 Message: Logged In: YES user_id=421 Ivo, sorry for not reacting earlier. Adding this feature seems possible. Is it still needed? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=572&group_id=106

1 0

[ pdftex-Feature Requests-573 ] add \ArtBox to pages
by noreply＠sarovar.org 24 Jul '06

24 Jul '06

Feature Requests item #573, was opened at 2006-06-20 07:32 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=573&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexei Gilchrist (alexei2) >Assigned to: Martin Schröder (oneiros) Summary: add \ArtBox to pages Initial Comment: Hi, Is it possible to add an \ArtBox entry to the pages produces by pdftex (with a tight boundingbox)? This way the output of pdftex could be used as input into other progs that use pdf such as a pdf annotating tool. At the moment latex -> dvips -E -> dvitopdf seems to be the only way. thanks, Alexei ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-07-24 23:55 Message: Logged In: YES user_id=421 You can already add it manually with \pdfpage{s}attr. But you probably want an automatic entry. Define "tight": pdfTeX knows only the MediaBox (i.e. page dimensions). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=573&group_id=106

1 0

[ pdftex-Bugs-577 ] Type 3 fonts: on screen fine, on paper filled and displaced
by noreply＠sarovar.org 24 Jul '06

24 Jul '06

Bugs item #577, was opened at 2006-06-28 13:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=577&group_id=106 Category: Fonts Group: v1.30.0 Status: Open >Resolution: Works For Me Priority: 5 Submitted By: Peter Dyballa (ballapete) Assigned to: Hartmut Henkel (hhenkel) Summary: Type 3 fonts: on screen fine, on paper filled and displaced Initial Comment: Hello! It's pdfeTeX, Version 3.141592-1.30.4-2.2 (Web2C 7.5.5), on Mac OS X 10.4.6, PPC. The Type 3 font is dijkstra, a famous person's handwriting, as distributed by many SunOS and Solaris versions. Until mid May I had no problem with pdfTeX, dijkstra, and my EPSON EPL-5800 (PostScript 3). This week I again wanted to print a personal letter with Prof. Dijkstra's handwriting used for my letter head. And some letters were filled (P,e,9), others were horizontally and/or vertically displaced from their correct positions. Dijkstra was installed with fontinst. Can this be a pdfTeX problem? End of May I added almost 1 GB of files to update SDKs etc. in Mac OS X to be able to produce Universal Binaries. The last few Tiger versions are known as a bit buggy. My last TeX binaries updates happened in the middle of May, but I have no LOG files from this. The recent LOGs from making the format files contain the string above ... Greetings Pete ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-07-24 23:46 Message: Logged In: YES user_id=421 [Sorry for not reacting earlier, but gforge sends no mail when a file is attached; you also have to add a comment.] The attached file uses a Type 1 font and prints perfectly on an Lexmark Optra T612 (which has a PS3 RIP)... ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-06-28 16:09 Message: Logged In: YES user_id=421 Please provide a pdf showing the problems (attach it to this bug). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=577&group_id=106

1 0

[ pdftex-Patches-580 ] Patch to make ToUnicode for Type1 fonts
by noreply＠sarovar.org 19 Jul '06

19 Jul '06

Patches item #580, was opened at 2006-07-14 20:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=580&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: Patch to make ToUnicode for Type1 fonts Initial Comment: This is a patch to pdftex so that it can create ToUnicode entries for Type1 fonts. The main purpose is to make ligatures and some other glyphs like smallcap letters or oldstyle digits from OpenType fonts searchable. This patch also contains a minor fix that allows use of fonts without embedding, for example MinionPro or MyriadPro (which are distributed with Acrobat Reader >= 7.0 but from their use is restricted with Acrobat Reader only). How to apply: ~~~~~~~~~~~~~ - this patch applies to the pristine pdftex-1.40.0-beta-20060213 sources only; if you have applied another patch(es) to the sources, please discard them and start from the fresh ones. - how to apply: ,-------- | cd /path/to/pdftex-1.40.0-beta-20060213/src | cat /path/to/the/patch | patch -p1 | ./configure | cd texk/web2c | make pdfetex `-------- If you want to be careful, try the patch with the option '--dry-run' first to see whether the patch can be applied without problems. Usage: ~~~~~~ add the following lines into your document, somewhere at the beginning: ,-------- | \input glyphtounicode.tex | \pdfgentounicode=1 `-------- Customization: ~~~~~~~~~~~~~ If pdftex cannot generate the right ToUnicode value for some glyphs (probably because the glyph name is not ``known'' to pdftex), it's possible to add further entries so pdftex can learn how to generate unicode for such ``unknown'' glyphs. The syntax is simple: \pdfglyphtounicode{<glyph-name>}{<unicode-value>} Example: \pdfglyphtounicode{A}{0041} says that glyph 'A' has its unicode U+0041 The entries in glyphtounicode.tex cover Adobe Glyph List (glyphlist.txt version 2.0) and some addtional glyphs (texglyphlist.txt version 2.33, coming from from lcdf-typetools), plus some additional entries for ligatures. If some glyph name cannot be found, pdftex does some simple name translations: - remove any ".xxx" suffix from glyph name, where "xxx" is a string consisting of alphabetic characters. For example "A.sc" => "A" - remove suffix like "small", "oldstyle", "inferior" and "superior" from glyph name. For example "Asmall" => "A" The result name then is looked up again to find a unicode. Ligatures require a special form of ToUnicode. Example: \pdfglyphtounicode{ff}{00660066} here '0066' is the unicode string for 'f'. Some ligatures have their name like 'f_f_i', in such case the command should be \pdfglyphtounicode{f_f_i}{006600660069} ie '_' is removed from the glyph name, and then all letters are translated to their unicode string. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2006-07-19 06:08 Message: Logged In: YES user_id=710 patch updated to fix a bug reported by Dohyun Kim ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-07-16 11:19 Message: Logged In: YES user_id=710 patch updated by a bug fix from Akira ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=580&group_id=106

1 0

[ pdftex-Patches-580 ] Patch to make ToUnicode for Type1 fonts
by noreply＠sarovar.org 16 Jul '06

16 Jul '06

Patches item #580, was opened at 2006-07-14 20:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=580&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: Patch to make ToUnicode for Type1 fonts Initial Comment: This is a patch to pdftex so that it can create ToUnicode entries for Type1 fonts. The main purpose is to make ligatures and some other glyphs like smallcap letters or oldstyle digits from OpenType fonts searchable. This patch also contains a minor fix that allows use of fonts without embedding, for example MinionPro or MyriadPro (which are distributed with Acrobat Reader >= 7.0 but from their use is restricted with Acrobat Reader only). How to apply: ~~~~~~~~~~~~~ - this patch applies to the pristine pdftex-1.40.0-beta-20060213 sources only; if you have applied another patch(es) to the sources, please discard them and start from the fresh ones. - how to apply: ,-------- | cd /path/to/pdftex-1.40.0-beta-20060213/src | cat /path/to/the/patch | patch -p1 | ./configure | cd texk/web2c | make pdfetex `-------- If you want to be careful, try the patch with the option '--dry-run' first to see whether the patch can be applied without problems. Usage: ~~~~~~ add the following lines into your document, somewhere at the beginning: ,-------- | \input glyphtounicode.tex | \pdfgentounicode=1 `-------- Customization: ~~~~~~~~~~~~~ If pdftex cannot generate the right ToUnicode value for some glyphs (probably because the glyph name is not ``known'' to pdftex), it's possible to add further entries so pdftex can learn how to generate unicode for such ``unknown'' glyphs. The syntax is simple: \pdfglyphtounicode{<glyph-name>}{<unicode-value>} Example: \pdfglyphtounicode{A}{0041} says that glyph 'A' has its unicode U+0041 The entries in glyphtounicode.tex cover Adobe Glyph List (glyphlist.txt version 2.0) and some addtional glyphs (texglyphlist.txt version 2.33, coming from from lcdf-typetools), plus some additional entries for ligatures. If some glyph name cannot be found, pdftex does some simple name translations: - remove any ".xxx" suffix from glyph name, where "xxx" is a string consisting of alphabetic characters. For example "A.sc" => "A" - remove suffix like "small", "oldstyle", "inferior" and "superior" from glyph name. For example "Asmall" => "A" The result name then is looked up again to find a unicode. Ligatures require a special form of ToUnicode. Example: \pdfglyphtounicode{ff}{00660066} here '0066' is the unicode string for 'f'. Some ligatures have their name like 'f_f_i', in such case the command should be \pdfglyphtounicode{f_f_i}{006600660069} ie '_' is removed from the glyph name, and then all letters are translated to their unicode string. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2006-07-16 11:19 Message: Logged In: YES user_id=710 patch updated by a bug fix from Akira ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=580&group_id=106

1 0