- ntg-pdftex - NTG Mailing Lists

[ 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 21:52 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: Nobody (None) Date: 2006-10-17 18:46 Message: Logged In: NO > This patch implements two new primitives: > \primitive \par This wording is very misleading : \par is not a new primitive, and should not be mentioned here. Its place (if it has one) should be under examples of possible usage. Presumably the second new primitive is \ifprimitive, which occurs much later in the prose. Regarding the expandability or otherwise of \primitive, the very worst of all worlds would be "making the expandability depend on the referred primitive"; a primitive should either be expandable or not expandable, not vary its behaviour according to the phase of the moon ! ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 15:57 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-14 12:47 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 23:26 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 22:10 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-603 ] Patch ColorStackTransformMatrix
by noreply＠sarovar.org 17 Oct '06

17 Oct '06

Patches item #603, was opened at 2006-09-07 10:35 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=603&group_id=106 Category: Primitives Group: v1.40.0 Status: Open >Resolution: Accepted Priority: 8 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Martin Schröder (oneiros) Summary: Patch ColorStackTransformMatrix Initial Comment: Subject: Patch ColorStackTransformMatrix Date: 2006/09/07 Author: Heiko Oberdiek The patch is based on pdftex-1.40.0-beta-20060906 It tries to solve two FAQ problems: * missing color stack * wrong annotation rectangles (links, anchors) if the material was scaled or rotated. Files: ColorStackTransformMatrix.patch The patch, apply it in src/texk/web2c/pdftexdir: patch <ColorStackTransformMatrix.patch pdftex.def A modified version that uses the patch if the new primitives are found. A short test file: \documentclass{article} \usepackage{color} \usepackage{pdflscape} \usepackage{hyperref} \begin{document} \tableofcontents \section{Hello World} \label{sec:hello} \textcolor{blue}{Blue\newpage Blue} \begin{landscape} See \autoref{sec:hello}. \end{landscape} \end{document} Without the patch: * Text on first page before "Blue" is blue instead of black. * Text on second page is black instead of blue. * The link frame on page three is misplaced. With the patch and modified pdftex.def these things are fixed. New commands % color stack * \pdfcolorstackinit * \pdfcolorstack % matrix transformations * \pdfsetmatrix * \pdfsave * \pdfrestore Syntax: %% expandable commands: \pdfcolorstackinit [page] [direct] <general text> %% general commands: \pdfcolorstack <stack number> <stack action> <general text> \pdfsetmatrix \pdfsave \pdfrestore <stack action> ::= set | push | pop | current Description for color stack: This color stack implementation allows several independent stacks (upto 32686): * Stacks can be used for other properties than color, especially other graphics state parameters. * Several "text flows across pages" can be supported by color stacks. Example: footnotes. \pdfcolorstackinit [page] [direct] {<initial value>} A stack is initialized by \pdfcolorstackinit. It expands to the number of the new stack. The common case, the traditinal color stack is already initialized as first stack: \pdfcolorstackinit page direct {0 g 0 G} The keyword "page" means, that this stack is page based. At the start of the new page, the current stack value is automatically set: \textcolor{blue}{A\newpage B} The second page with "B" will start with blue setting. The keyword "direct" has the same meaning as "direct" for \pdfliteral. If the stack value is set, it is done by an equivalent of \pdfliteral direct {...}. The mandatory argument is the initial value on the stack. It should be the default at page start for the property, see PDF documentation. \pdfcolorstack <stack number> push {<new color>} pushes the current value on the stack and sets the <new color>. \pdfcolorstack <stack number> pop pops and sets the current stack value. \pdfcolorstack <stack number> current sets the current stack value without changing the stack. This is useful for stacks that are initialized without keyword "page". Thus the page start setting can be set manually. \pdfcolorstack <stack number> set {<new color>} The current value is set to <new color>. Example (changed pdftex.def): \chardef\GPT@colorstack=0 % \def\set@color{% \pdfcolorstack\GPT@colorstack push{\current@color}% \aftergroup\reset@color }% \def\reset@color{% \pdfcolorstack\GPT@colorstack pop\relax }% If someone wants to add color stack support for footnotes, the principle would be: \edef\stackfootnote{\pdfcolorstackinit direct{0 g 0 G}}% % Then at begin of the footnote area on the page: \pdfcolorstack\stackfoonote current\relax % During footnote processing the footnote stack is used: \let\GPT@colorstack\stackfoonote Description for matrix transformations: Currently matrix changes are done and hidden inside \pdfliteral nodes; pdfTeX doesn't parse its contents and does not know the new settings of the transform matrix. Thus the patch adds new primitives to save pdfTeX from parsing \pdfliteral contents and to notify pdfTeX about matrix changes to use them in calculating link and anchor positions. \pdfsetmatrix{<a> <b> <c> <d>} is the equivalent to \pdfliteral{<a> <b> <c> <d> 0 0 cm} \pdfsave is the equivalent to \pdfliteral{q} \pdfrestore is the equivalent to \pdfliteral{Q} Some remarks: * TeX already supports translations, thus the matrix is limited to four values for scaling and rotating. * There are some restrictions about \pdfsave and \pdfrestore: * They must be properly nested. * A pair must start and end in the same group at the same level. * A pair must start and end at the same position. Happily these restrictions are satisfied by the graphics package. Example (changed pdftex.def): \def\Grot@start{% \pdfsave \pdfsetmatrix{% \Grot@cos\space\Grot@sin\space \if-\Grot@sin\else-\Grot@sin\fi\space\Grot@cos }% \wd\z@\z@ }% \def\Grot@end{\pdfrestore} \def\Gscale@start{% \pdfsave \pdfsetmatrix{% \Gscale@x\space0 0 \Gscale@y }% }% Have fun Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-10-17 15:08 Message: Logged In: YES user_id=421 I still get the warning in utils.c :-{ Can you update the pdfTeX manual on this? ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2006-09-12 16:38 Message: Logged In: YES user_id=1276 | Two questions come to mind: | - how does this patch interact with existing documents, The design principle is that the patch does not have an effect if the new primitives are not used (modulo bugs). | i.e. | what must be changed when using this patch? Obviously the | use of \pdfliteral must be checked. Anything else? LaTeX's color/graphics: pdftex.def that support the new primitives. | - does this collide with pdftex's use of the cm? The only | use of the transformation matrix by pdftex I could find | concerns magnifications, so that's most likely not a | problem. I had played a little with magnification, but not too intensively. | Btw: gcc with -Wall -std=c99 gives this warning: | ../../../../src/texk/web2c/pdftexdir/utils.c: In function | ‘newcolorstack’: | ../../../../src/texk/web2c/pdftexdir/utils.c:1366: | warning: | operation on ‘colstacks’ may be undefined Assignments to colstacks are controlled by colstack_size, thus the warnung can be gnored. To avoid the warning replace static colstack_type *colstacks; by static colstack_type *colstacks = NULL; Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-12 16:06 Message: Logged In: YES user_id=421 Heiko, thank you very much for your patch. Two questions come to mind: - how does this patch interact with existing documents, i.e. what must be changed when using this patch? Obviously the use of \pdfliteral must be checked. Anything else? - does this collide with pdftex's use of the cm? The only use of the transformation matrix by pdftex I could find concerns magnifications, so that's most likely not a problem. Btw: gcc with -Wall -std=c99 gives this warning: ../../../../src/texk/web2c/pdftexdir/utils.c: In function ‘newcolorstack’: ../../../../src/texk/web2c/pdftexdir/utils.c:1366: warning: operation on ‘colstacks’ may be undefined ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=603&group_id=106

1 0

[ 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