October 2006 - ntg-pdftex - NTG Mailing Lists

[ pdftex-Patches-453 ] Object Streams for PDF-1.5
by noreply＠sarovar.org 17 Oct '06

17 Oct '06

Patches item #453, was opened at 2005-11-26 18:05 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=453&group_id=106 Category: Object Streams >Group: v1.40.0 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Martin Schröder (oneiros) Summary: Object Streams for PDF-1.5 Initial Comment: Rough early patch, work in progress, produces PDF-1.5 object streams and cross reference streams. With the patch, and enabled by \pdfminorversion=5, and with luck, pdfetex produces e. g. from its WEB source a PDF file with size 5.97 MByte instead of 11.2 MByte without object streams. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 12:23 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-01-07 01:06 Message: Logged In: YES user_id=929 objstream.ch updated: 1. object stream statistics added. 2. maximum allocation values are added in brackets. Example: PDF statistics: 630 PDF objects out of 1000 (max. 8388607) 577 compressed objects within 6 object streams 113 named destinations out of 1000 (max. 131072) 8353 words of extra memory for PDF output out of 10000 (max. 10000000) Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-12-26 20:21 Message: Logged In: YES user_id=929 Patch update. Object stream writing is now controlled by primitive \pdfobjcompresslevel = 0...3 (/pdfobjectstreams primitive removed). 0 = no object streams at all, 1 = compress objects excluding the ones from embedded PDF files (for handling of problematic PDF files) and /Info dictionary (for legibility), 2 = also compress objects from embedded PDF files, but leave /Info uncompressed, 3 = compress everything. Testing welcome. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=453&group_id=106

1 0

[ pdftex-Patches-466 ] \primitive and \ifprimitive
by noreply＠sarovar.org 17 Oct '06

17 Oct '06

Patches item #466, was opened at 2006-01-07 17:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=466&group_id=106 Category: Primitives >Group: v1.40.0 Status: Closed Resolution: Accepted Priority: 4 Submitted By: Taco Hoekwater (taco) Assigned to: Martin Schröder (oneiros) Summary: \primitive and \ifprimitive Initial Comment: This patch implements two new primitives: \primitive \par This will run the 'primitive' command \par, even if it has been re- or undefined in the meantime. \primitive is not expandable, because it may be asked to execute unexpandable primitives as well as expandable ones. If you supply a nonexistant primitive, it will be ignored (no error is raised). The second primitive is a new type of \if: \ifprimitive \par ... \else .. \fi returns true if the current meaning of \par is the 'primitive' command \par. The patch is against alpha-20051226, i hope that is not too old (?). I expect to do at least one minor update during the beta cycle, after the pdftex code is flattened. It was quite a struggle to make this change file work ok, and as a result, there are a few ugly web hacks. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 12:27 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-14 08:17 Message: Logged In: YES user_id=3344 IMHO it would be better to rephrase the above to (and change the implementation accordingly :-(): <quote mode="changed"> \primitive is expandable, because it may asked to execute expandable primitives as well as unexpandable ones. \primitive<cs> will expand to one token, the original TeX primitive. This token will then be processed further as usual. </quote> If \primitive is left unexpandable, a lot of programming techniques seems to be unavailable, e.g., all redefined expandable primitives in expandable-only context. Or any assignment to the get the original primitive, like \edef\orignumber{\expandafter\noexpand\primitive\number} \expandafter\let\expandafter\orignumber\primitive\number Sidenote: The new \primitive seems to implement a subset of a full-blown namespace mechanism. If (pdf)TeX would have namespaces, one simply has to access the appropriate token within the "primitive" namespace (e.g. \primitive::number to access the original \number primitive, assuming the notation \<namespace>::<csname>). How about choosing an appropriate namespace mechanism for (pdf)TeX and implementing it instead? ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-02-13 18:56 Message: Logged In: YES user_id=1608 We need to think about this. I see your point, but making \primitive expandable forces the introduction of un-redefinable tokens, and that has its own problematic side-effects (like slowing down each and every definition). I welcome third opinions on whether the benefits outweigh that downside. At one point I tried making the expandability depend on the referred primitive, but that gave me headaches at the implementation stage (a pity, because that would have been nice). Yet another solution is to have an expandable command as well as an unexpandable command (two primitives instead of just the single \primitive). On the side note: I will happily write an implementation ... but only if someone comes up with a specification that works under all conditions instead of only under specific programming styles :-) ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-13 17:40 Message: Logged In: YES user_id=3344 IMHO it would be better to rephrase the above to (and change the implementation accordingly :-(): <quote mode="changed"> \primitive is expandable, because it may asked to execute expandable primitives as well as unexpandable ones. \primitive<cs> will expand to one token, the original TeX primitive. This token will then be processed further as usual. </quote> If \primitive is left unexpandable, a lot of programming techniques seems to be unavailable, e.g., all redefined expandable primitives in expandable-only context. Or any assignment to the get the original primitive, like \edef\orignumber{\expandafter\noexpand\primitive\number} \expandafter\let\expandafter\orignumber\primitive\number Sidenote: The new \primitive seems to implement a subset of a full-blown namespace mechanism. If (pdf)TeX would have namespaces, one simply has to access the appropriate token within the "primitive" namespace (e.g. \primitive::number to access the original \number primitive, assuming the notation \<namespace>::<csname>). How about choosing an appropriate namespace mechanism for (pdf)TeX and implementing it instead? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=466&group_id=106

1 0

[ pdftex-Patches-473 ] \ifabsnum and \ifabsdim
by noreply＠sarovar.org 17 Oct '06

17 Oct '06

Patches item #473, was opened at 2006-01-27 15:20 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=473&group_id=106 Category: Primitives >Group: v1.40.0 Status: Closed Resolution: Accepted Priority: 4 Submitted By: Taco Hoekwater (taco) Assigned to: Martin Schröder (oneiros) Summary: \ifabsnum and \ifabsdim Initial Comment: Here is a small change file that implements two new etex primitives : \ifabsnum \ifabsdim Usage is the same as \ifnum and \ifdim. The only difference is that they negate the values if they are negative before comparing. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 12:28 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2006-01-27 15:31 Message: Logged In: YES user_id=927 intended usage: \ifabsdim \dimexpr \maxheight - \currentheight \relax < .5pt assume that we're done \fi it can also be used to handle rounding errors when doing roundtrip calculations ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=473&group_id=106

1 0

[ pdftex-Patches-466 ] \primitive and \ifprimitive
by noreply＠sarovar.org 17 Oct '06

17 Oct '06

Patches item #466, was opened at 2006-01-07 17:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=466&group_id=106 Category: Primitives Group: v1.30.0 >Status: Closed Resolution: Accepted Priority: 4 Submitted By: Taco Hoekwater (taco) Assigned to: Martin Schröder (oneiros) Summary: \primitive and \ifprimitive Initial Comment: This patch implements two new primitives: \primitive \par This will run the 'primitive' command \par, even if it has been re- or undefined in the meantime. \primitive is not expandable, because it may be asked to execute unexpandable primitives as well as expandable ones. If you supply a nonexistant primitive, it will be ignored (no error is raised). The second primitive is a new type of \if: \ifprimitive \par ... \else .. \fi returns true if the current meaning of \par is the 'primitive' command \par. The patch is against alpha-20051226, i hope that is not too old (?). I expect to do at least one minor update during the beta cycle, after the pdftex code is flattened. It was quite a struggle to make this change file work ok, and as a result, there are a few ugly web hacks. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 12:27 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-14 08:17 Message: Logged In: YES user_id=3344 IMHO it would be better to rephrase the above to (and change the implementation accordingly :-(): <quote mode="changed"> \primitive is expandable, because it may asked to execute expandable primitives as well as unexpandable ones. \primitive<cs> will expand to one token, the original TeX primitive. This token will then be processed further as usual. </quote> If \primitive is left unexpandable, a lot of programming techniques seems to be unavailable, e.g., all redefined expandable primitives in expandable-only context. Or any assignment to the get the original primitive, like \edef\orignumber{\expandafter\noexpand\primitive\number} \expandafter\let\expandafter\orignumber\primitive\number Sidenote: The new \primitive seems to implement a subset of a full-blown namespace mechanism. If (pdf)TeX would have namespaces, one simply has to access the appropriate token within the "primitive" namespace (e.g. \primitive::number to access the original \number primitive, assuming the notation \<namespace>::<csname>). How about choosing an appropriate namespace mechanism for (pdf)TeX and implementing it instead? ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-02-13 18:56 Message: Logged In: YES user_id=1608 We need to think about this. I see your point, but making \primitive expandable forces the introduction of un-redefinable tokens, and that has its own problematic side-effects (like slowing down each and every definition). I welcome third opinions on whether the benefits outweigh that downside. At one point I tried making the expandability depend on the referred primitive, but that gave me headaches at the implementation stage (a pity, because that would have been nice). Yet another solution is to have an expandable command as well as an unexpandable command (two primitives instead of just the single \primitive). On the side note: I will happily write an implementation ... but only if someone comes up with a specification that works under all conditions instead of only under specific programming styles :-) ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-13 17:40 Message: Logged In: YES user_id=3344 IMHO it would be better to rephrase the above to (and change the implementation accordingly :-(): <quote mode="changed"> \primitive is expandable, because it may asked to execute expandable primitives as well as unexpandable ones. \primitive<cs> will expand to one token, the original TeX primitive. This token will then be processed further as usual. </quote> If \primitive is left unexpandable, a lot of programming techniques seems to be unavailable, e.g., all redefined expandable primitives in expandable-only context. Or any assignment to the get the original primitive, like \edef\orignumber{\expandafter\noexpand\primitive\number} \expandafter\let\expandafter\orignumber\primitive\number Sidenote: The new \primitive seems to implement a subset of a full-blown namespace mechanism. If (pdf)TeX would have namespaces, one simply has to access the appropriate token within the "primitive" namespace (e.g. \primitive::number to access the original \number primitive, assuming the notation \<namespace>::<csname>). How about choosing an appropriate namespace mechanism for (pdf)TeX and implementing it instead? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=466&group_id=106

1 0

[ pdftex-Bugs-479 ] Nested links
by noreply＠sarovar.org 11 Oct '06

11 Oct '06

Bugs item #479, was opened at 2006-02-09 18:08 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=479&group_id=106 Category: Annotations Group: v1.30.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Hartmut Henkel (hhenkel) Summary: Nested links Initial Comment: Hello, Dario Teixeira reported a problem on the pdfTeX mailing list: > I have come across an interesting issue with hyperref > and pdftex. Whenever one hyperlink is nested inside > another, the entire remainder of the line is shown > as an hyperlink. > > If you are wondering why on earth would someone want > to have nested hyperlinks, please take a look at this > sample document I created; it also displays the "feature": > http://www.dse.nl/~dario/misc/nestedlinks.pdf [50KB] I consider this as bug in pdfTeX and have generated a small test file (plain format): \showboxbreadth=\maxdimen \showboxdepth=\maxdimen [part before] \pdfstartlink goto name{Hello} [hello start \pdfstartlink attr{/C[1 0 0]} goto name{World} [inside world]% \pdfendlink\space stop]% \pdfendlink\space [part after]\par \showlists \vfill\eject \pdfdest name{Hello}XYZ\relax Hello \vfill\eject \pdfdest name{World}XYZ\relax World \end Three annotations are generated by pdfTeX 1.30.4: 7 0 obj << /Type /Annot /Rect [148.989 757.436 540 767.399] /Subtype /Link /A << /S /GoTo /D (Hello) >> >> endobj 8 0 obj << /Type /Annot /C[1 0 0] /Rect [199.439 757.436 257.361 767.399] /Subtype /Link /A << /S /GoTo /D (World) >> >> endobj 9 0 obj << /Type /Annot /Rect [257.361 757.436 281.769 767.399] /Subtype /Link /A << /S /GoTo /D (Hello) >> >> endobj Either there should be two overlapping annotations or three distinct ones. At any case "540" in the first rect is too large. As workaround, the outer/enclosing annotation can put into a box (\hbox in plain TeX, \mbox in LaTeX). But it does not solve the problem, because now the link cannot be broken across lines. Therefore the algorithm for annotations needs to be reviewed and corrected. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-10-11 15:35 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-11 11:21 Message: Logged In: YES user_id=710 This is an attempt to fix bug #479 - This patch applies to the pristine pdftex-1.40.0-beta-20060928 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-20060928/src | cat /path/to/the/patch | patch -p1 | ./configure | cd texk/web2c | make pdftex `-------- - Example is included in the zip archive. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-02-13 00:07 Message: Logged In: YES user_id=421 Confirmed with the latest beta. _Can_ links be nested? And if they can, is there a limit on the nesting depth? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=479&group_id=106

1 0

[ pdftex-Bugs-479 ] Nested links
by noreply＠sarovar.org 11 Oct '06

11 Oct '06

Bugs item #479, was opened at 2006-02-09 17:08 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=479&group_id=106 Category: Annotations Group: v1.30.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Hartmut Henkel (hhenkel) Summary: Nested links Initial Comment: Hello, Dario Teixeira reported a problem on the pdfTeX mailing list: > I have come across an interesting issue with hyperref > and pdftex. Whenever one hyperlink is nested inside > another, the entire remainder of the line is shown > as an hyperlink. > > If you are wondering why on earth would someone want > to have nested hyperlinks, please take a look at this > sample document I created; it also displays the "feature": > http://www.dse.nl/~dario/misc/nestedlinks.pdf [50KB] I consider this as bug in pdfTeX and have generated a small test file (plain format): \showboxbreadth=\maxdimen \showboxdepth=\maxdimen [part before] \pdfstartlink goto name{Hello} [hello start \pdfstartlink attr{/C[1 0 0]} goto name{World} [inside world]% \pdfendlink\space stop]% \pdfendlink\space [part after]\par \showlists \vfill\eject \pdfdest name{Hello}XYZ\relax Hello \vfill\eject \pdfdest name{World}XYZ\relax World \end Three annotations are generated by pdfTeX 1.30.4: 7 0 obj << /Type /Annot /Rect [148.989 757.436 540 767.399] /Subtype /Link /A << /S /GoTo /D (Hello) >> >> endobj 8 0 obj << /Type /Annot /C[1 0 0] /Rect [199.439 757.436 257.361 767.399] /Subtype /Link /A << /S /GoTo /D (World) >> >> endobj 9 0 obj << /Type /Annot /Rect [257.361 757.436 281.769 767.399] /Subtype /Link /A << /S /GoTo /D (Hello) >> >> endobj Either there should be two overlapping annotations or three distinct ones. At any case "540" in the first rect is too large. As workaround, the outer/enclosing annotation can put into a box (\hbox in plain TeX, \mbox in LaTeX). But it does not solve the problem, because now the link cannot be broken across lines. Therefore the algorithm for annotations needs to be reviewed and corrected. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2006-10-11 09:21 Message: Logged In: YES user_id=710 This is an attempt to fix bug #479 - This patch applies to the pristine pdftex-1.40.0-beta-20060928 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-20060928/src | cat /path/to/the/patch | patch -p1 | ./configure | cd texk/web2c | make pdftex `-------- - Example is included in the zip archive. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-02-12 23:07 Message: Logged In: YES user_id=421 Confirmed with the latest beta. _Can_ links be nested? And if they can, is there a limit on the nesting depth? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=479&group_id=106

1 0

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

07 Oct '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-10-07 09:44 Message: Logged In: YES user_id=710 Patch updated to fix a bug reported by Akira. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-06 11:34 Message: Logged In: YES user_id=710 This is a patch to pdftex that includes: - a fix for bug #611 - some changes to ToUnicode support (patch #580) to make the implementation follow guidelines at http://partners.adobe.com/public/developer/opentype/index_glyph.html How to apply: ~~~~~~~~~~~~~ - this patch applies to the pristine pdftex-1.40.0-beta-20060928 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-20060928/src | cat /path/to/the/patch | patch -p1 | ./configure | cd texk/web2c | make pdftex `-------- 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. \pdfglyphtounicode requires that the second parameter consists of uppercase hexadecimal digits (0..9, A..F) and spaces. If this is not the case the entry is simply discarded (with a warning). Later entries overwrite previous entries with the same name (1st arg). The entries in glyphtounicode.tex cover: - glyphlist.txt (Adobe Glyph List v2.0) - zapfdingbats.txt (ITC Zapf Dingbats Glyph List v2.0) - texglyphlist.txt (lcdf-typetools texglyphlist.txt v2.33) - additional.tex (additional entries) Ligatures require a special form of ToUnicode. Example: ,-------- | \pdfglyphtounicode{ff}{00660066} `-------- here '0066' is the unicode string for 'f'. Spaces are ignored in the second parameter of \pdfglyphtounicode, hence it is possible to write the above command as ,-------- | \pdfglyphtounicode{ff}{0066 0066} `-------- which is easier to read and understand IMO. ---------------------------------------------------------------------- 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 06 Oct '06

06 Oct '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-10-06 11:34 Message: Logged In: YES user_id=710 This is a patch to pdftex that includes: - a fix for bug #611 - some changes to ToUnicode support (patch #580) to make the implementation follow guidelines at http://partners.adobe.com/public/developer/opentype/index_glyph.html How to apply: ~~~~~~~~~~~~~ - this patch applies to the pristine pdftex-1.40.0-beta-20060928 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-20060928/src | cat /path/to/the/patch | patch -p1 | ./configure | cd texk/web2c | make pdftex `-------- 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. \pdfglyphtounicode requires that the second parameter consists of uppercase hexadecimal digits (0..9, A..F) and spaces. If this is not the case the entry is simply discarded (with a warning). Later entries overwrite previous entries with the same name (1st arg). The entries in glyphtounicode.tex cover: - glyphlist.txt (Adobe Glyph List v2.0) - zapfdingbats.txt (ITC Zapf Dingbats Glyph List v2.0) - texglyphlist.txt (lcdf-typetools texglyphlist.txt v2.33) - additional.tex (additional entries) Ligatures require a special form of ToUnicode. Example: ,-------- | \pdfglyphtounicode{ff}{00660066} `-------- here '0066' is the unicode string for 'f'. Spaces are ignored in the second parameter of \pdfglyphtounicode, hence it is possible to write the above command as ,-------- | \pdfglyphtounicode{ff}{0066 0066} `-------- which is easier to read and understand IMO. ---------------------------------------------------------------------- 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-Bugs-609 ] Pdf "convert" primitives bug
by noreply＠sarovar.org 04 Oct '06

04 Oct '06

Bugs item #609, was opened at 2006-09-28 18:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=609&group_id=106 Category: Primitives Group: v1.40.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Taco Hoekwater (taco) >Summary: Pdf "convert" primitives bug Initial Comment: The problem: When tex calls `conv_toks()' to execute `convert' commands, a string may already be being built. A call to scan_toks (pdf_scan_ext_toks) at that moment will incorporate that partial string to the argument of the `convert' primitive, and erase it from the output. Example code: \message{\pdfmdfivesum{knuth}} \input knuth\pdfmdfivesum{} \bye Affected primitives: \pdfescapestring \pdfescapename \pdfescapehex \pdfunescapehex \pdffilemoddate \pdffilesize \pdffiledump \pdfmdfivesum \pdfstrcmp The needed fix: Somewhen before calling scan_pdf_ext_toks, you have to store the partial string as a true tex string, then its `partialness' has to be restored sometime later before leaving conv_toks(). ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2006-10-04 16:43 Message: Logged In: YES user_id=1608 patch against pdftex.web from 20060928 attached. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-09-28 18:52 Message: Logged In: YES user_id=1608 sorry, it is a bug, of course ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=609&group_id=106

1 0

[ pdftex-Bugs-611 ] Bug of pdftex beta upon reading some truetype
by noreply＠sarovar.org 02 Oct '06

02 Oct '06

Bugs item #611, was opened at 2006-09-30 02:17 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=611&group_id=106 Category: Fonts Group: v1.40.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dohyun Kim (nomos) Assigned to: The Thanh Han (hanthethanh) Summary: Bug of pdftex beta upon reading some truetype Initial Comment: I have recently installed pdftex beta on my Linux box. But I am puzzled by a strange behavior of newly installed pdftex. For your test, I've put a minimal tarball (1.6M) to a server: http://210.94.201.157/~nomos/KTUG/truetypetest.tar.gz On my i686 Linux machine, compiling the following file (which is included in the tarball above) with pdftex beta version 20060906 fails with Segmentation Fault. ==================== %\pdfmapline{+oungtb4e <oungtb4e.enc <UnDotumBold.ttf} %%% it works. \pdfmapline{+oungtb@Unicode@ <UnDotumBold.ttf} %%% it segfaults. \font\mytt=oungtb4e\relax \mytt \char0 \char1 \bye ==================== PDFTeX beta 20060928, the most recent version at the time of this reporting, crashes too. Please inspect the problem. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-02 22:53 Message: Logged In: YES user_id=710 sorry for the mess -- I forgot to attach the patch ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-02 22:47 Message: Logged In: YES user_id=710 sorry, ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-02 22:45 Message: Logged In: YES user_id=710 here is my attempt to fix the bug. Please apply the attached patch as follows: ,-------- | cd /path/to/pdftex-1.40.0-beta-20060928/src | cat /path/to/the/patch | patch -p1 | ./configure | cd texk/web2c | make pdfetex `-------- ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-30 19:30 Message: Logged In: YES user_id=421 Just FTR: I've tried to attach the file from nomos to this bug, but this fails silently; probably some size limit. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=611&group_id=106

1 0