October 2006 - ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-483 ] extra kerning inhibits extra spacing
by noreply＠sarovar.org 21 Oct '06

21 Oct '06

Bugs item #483, was opened at 2006-02-13 19:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=483&group_id=106 Category: hz Group: v1.40.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: extra kerning inhibits extra spacing Initial Comment: The new extension don't work together: \pdfadjustinterwordglue=1 \knbscode\font`\e=1000 The test \pdfappendkern=1 \knaccode\font`\e=1 The test \bye ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-10-21 15:52 Message: Logged In: YES user_id=421 Fixed; see patch 663. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=483&group_id=106

1 0

[ pdftex-Bugs-482 ] extra kerning does not work with ligatures
by noreply＠sarovar.org 21 Oct '06

21 Oct '06

Bugs item #482, was opened at 2006-02-13 19:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=482&group_id=106 Category: hz Group: v1.40.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: extra kerning does not work with ligatures Initial Comment: Appending or prepending kerns with the new primitives does not work with ligatures. It works, though, when the ligatures are accessed via \char: \pdfprependkern=1 \pdfappendkern=1 \def\setkn#1{% \knbccode\font #1 = 200\relax \knaccode\font #1 = 200\relax } \setkn{`a} \setkn{11} % ff \setkn{12} % fi \setkn{`z} afffiz\par a\char11 \char12 z \bye ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-10-21 15:52 Message: Logged In: YES user_id=421 Fixed; see patch 663. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=482&group_id=106

1 0

[ pdftex-Bugs-481 ] "This can't happen (flushing)" with extra kerning+expansion+ligatures
by noreply＠sarovar.org 21 Oct '06

21 Oct '06

Bugs item #481, was opened at 2006-02-13 19:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=481&group_id=106 Category: hz Group: v1.40.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) >Summary: "This can't happen (flushing)" with extra kerning+expansion+ligatures Initial Comment: With the following test file, pdftex will abort with "This can't happen (flushing)": \pdfadjustspacing=1 \pdffontexpand\font 20 20 4 autoexpand \pdfappendkern=1 \knaccode\font`i=100 \hsize10em foo fii foo foo foo foo % but this works: %foo f{}ii foo foo foo foo \bye Hartmut's analysis was: ----------------------------------- FWIW, this happens in function do_subst_font(). But it starts with auto_expand_kern(), where the given kern indeed is appended to the i of "fi" and also to the 2nd "i". It seems as if at this time "fi" is not yet seen as a ligature. Then in do_subst_font() the "fi" is somehow already a ligature, and now the kern is part of the lig_ptr list (which is wrong). Then font(r) is recursively changed to 51, the expanded font number, and so the kern, which should not be in this list, gets the 51 as its type. But it must be 11 for a kern. Maybe a change should be that the kern does not end up in the lig_ptr list, but should come after the "fi" ligature. No idea, how. ----------------------------------- ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-10-21 15:51 Message: Logged In: YES user_id=421 Fixed, see patch 663. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-01 12:43 Message: Logged In: YES user_id=421 Is anybody working on this? ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-02-13 21:25 Message: Logged In: YES user_id=929 My text above had a typo, sorry. Before you start searching... it's auto_append_kern(), not auto_expand_kern(). Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=481&group_id=106

1 0

[ pdftex-Patches-663 ] fix for bugs #481--483
by noreply＠sarovar.org 21 Oct '06

21 Oct '06

Patches item #663, was opened at 2006-10-21 12:29 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=663&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: fix for bugs #481--483 Initial Comment: This is an attempt to fix bug #481--483 - This patch applies to the pristine pdftex-1.40.0-beta-20061017 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-20061017/src | cat /path/to/the/patch | patch -p1 | ./configure | cd texk/web2c | make pdftex `-------- ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=663&group_id=106

1 0

[ pdftex-Feature Requests-662 ] avoid creating "fixed destination"
by noreply＠sarovar.org 20 Oct '06

20 Oct '06

Feature Requests item #662, was opened at 2006-10-20 13:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=662&group_id=106 Category: None >Group: v1.50 Status: Open Resolution: None Priority: 5 Submitted By: Ulrich Diez (ulrichdiez) >Assigned to: The Thanh Han (hanthethanh) >Summary: avoid creating "fixed destination" Initial Comment: When referencing a non-existing destination, you get this warning: ! pdfTeX warning (dest): name{<something>} has been referenced but does not exist, replaced by a fixed one I always like the warning about non-existing destinations, but sometimes I'd prefer pdfTeX not to take action besides issuing a warning-message/I'd prefer pdfTeX not to create a "fixed" destination. E.g., when creating several separate pdf-files with pdfTeX (for later merging them together by means of external software like "pdftk" or "pdfcat") whereby the named destination is not known/available when compiling file A but is available/provided in file B so that in the result from merging these files, everything will be fine. Does it make sense/is it possible to implement some mechanism for forking if creation of fixed destination shall be avoided or not? (Either a new token/primitive similar to \globaldefs which can be used within TeX source or some command- line-option which can be specified at the command-line when running pdfTeX ?) Sincerely Ulrich ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=662&group_id=106

1 0

[ pdftex-Feature Requests-662 ] avoid creating "fixed destination"
by noreply＠sarovar.org 20 Oct '06

20 Oct '06

Feature Requests item #662, was opened at 2006-10-20 11:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=662&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ulrich Diez (ulrichdiez) Assigned to: Nobody (None) Summary: avoid creating "fixed destination" Initial Comment: When referencing a non-existing destination, you get this warning: ! pdfTeX warning (dest): name{<something>} has been referenced but does not exist, replaced by a fixed one I always like the warning about non-existing destinations, but sometimes I'd prefer pdfTeX not to take action besides issuing a warning-message/I'd prefer pdfTeX not to create a "fixed" destination. E.g., when creating several separate pdf-files with pdfTeX (for later merging them together by means of external software like "pdftk" or "pdfcat") whereby the named destination is not known/available when compiling file A but is available/provided in file B so that in the result from merging these files, everything will be fine. Does it make sense/is it possible to implement some mechanism for forking if creation of fixed destination shall be avoided or not? (Either a new token/primitive similar to \globaldefs which can be used within TeX source or some command- line-option which can be specified at the command-line when running pdfTeX ?) Sincerely Ulrich ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=662&group_id=106

1 0

Re: [NTG-pdftex] why is TeX breaking the line?
by Taco Hoekwater 18 Oct '06

18 Oct '06

Hi Péter, Szabo Peter wrote: > Dear Taco, > > Do you have an idea why TeX is breaking the line at the \discretionary > in the source file below, thus producing an Overfull \hbox -- but if it > hadn't broken the line there, there would be no overfull boxes? > > If you don't know the answer, could you please recommend a forum or > mailing list? CC the pdftex mailing list, perhaps Thanh or Bernd knows, even though it is not really a pdfTeX question. To me, it looks like it may even be a bug. Greetings, Taco

5 5

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

17 Oct '06

Patches item #580, was opened at 2006-07-14 22:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=580&group_id=106 Category: None >Group: v1.40.0 Status: Open >Resolution: Accepted 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: Martin Schröder (oneiros) Date: 2006-10-17 15:39 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-07 11: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 13: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 08: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 13: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-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