June 2007 - ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-747 ] \letterspacefont and \pdffontexpand, again
by noreply＠sarovar.org 29 Jun '07

29 Jun '07

Bugs item #747, was opened at 2007-03-09 03:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106 Category: hz Group: v1.40.1 Status: Open Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: \letterspacefont and \pdffontexpand, again Initial Comment: When expanding a letterspaced font, the base font will be expanded, too, resulting in the error `font has been expanded with different parameters' when the base font is expanded again: \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand \pdffontexpand\font 20 20 5 autoexpand Z\bye ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2007-06-29 15:58 Message: Logged In: YES user_id=710 patch updated again. I have tested it with the following: \font\f=cmr10 \pdfcopyfont\fA=\f \letterspacefont\fB=\fA 100 \pdffontexpand\fB 30 30 5 autoexpand \fB \input tufte.tex and it seems to work. But the following doesn't: \letterspacefont\fC=\f 100 \pdfcopyfont\fD=\fC \pdffontexpand\fD 30 30 5 autoexpand probably it's possible with some more effort to make the latter case work too, but it doesn't seem needed. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-29 13:32 Message: Logged In: YES user_id=710 patch deleted. Needs more testing. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-29 09:56 Message: Logged In: YES user_id=710 sorry, I didn't test it carefully enough. Here is another attempt (tested with the microtype manual). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-29 08:52 Message: Logged In: YES user_id=421 Taco, the new_font_type -> real_font_type is from the fix for bug #722. We need an svn... :-( ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-29 07:22 Message: Logged In: YES user_id=1608 On my (fairly) clean sources, one hunk is rejected because of this: else begin if pdf_font_type[f] <> new_font_type then pdf_warning("font expansion", "font should be expanded before its first use", true, true); end; My pdftex.web uses pdf_font_type[f] = real_font_type in that test. I fixed the hunk, but I also get a crash on Robert's test file. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-06-28 23:17 Message: Logged In: YES user_id=2217 Now this yields a core dump with: \pdfadjustspacing2 \pdffontexpand\font 20 20 5 autoexpand \hsize10em Lorem ipsum dolor sit amet, \bye (unless I've messed up pdftex.web with all them patches) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-28 20:17 Message: Logged In: YES user_id=710 here is another patch, which introduces \pdfcopyfont. Example: \letterspacefont\lsfont\font 100 \pdfcopyfont\lsxfont\lsfont \pdffontexpand\lsxfont 20 20 5 autoexpand This patch also fixed a bug in expanding local font from virtual fonts: font shrinking didn't work. Big thanks to Robert for help with testing. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-28 18:42 Message: Logged In: YES user_id=710 expanding a letterspaced fonts always implies that the base font is expanded. In other words, it's impossible *not* to expand the base font when expanding a letterspaced font. thanks for further testing. It looks like a bug in checking font expansion spec. fwiw, font stretch limit is always fixed to [0..1000] and font shrink limit to [0..500]. Thus giving a negative value has the same effect like giving 0. I will play with \copyfont to see if it helps. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-06-28 14:01 Message: Logged In: YES user_id=2217 If we can get rid of the error message, I think it can be left at that. Mind you, the problem is not how to expand a letterspaced font but how to *not* expand the base font when expanding a letterspaced font. That expanding a letterspaced font results in expansion of the base font can be documented as a feature, IMO. Here are some more clues: The error message seems to be related to the sign of the stretch parameter. First of all, with \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand the base font will be expanded, however it will never be shrunk. Then, \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand \pdffontexpand\font 20 -20 5 autoexpand doesn't yield an error. Neither does: \pdffontexpand\lsfont 20 -20 5 autoexpand \pdffontexpand\font 20 -20 5 autoexpand However, here comes the error again: \pdffontexpand\lsfont 20 -20 5 autoexpand \pdffontexpand\font 20 20 5 autoexpand If you expand the base font first, it's OK in any case, also with different signs. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-28 07:37 Message: Logged In: YES user_id=1608 That sounds nice, I like it. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-28 06:45 Message: Logged In: YES user_id=710 I agree this is an ugly solution, which has its origin in a design mistake. However the problem here is not only how to deal with the error message, but the point is how to use font expansion with a letterspaced font. Please give it a thought so we can come up with an acceptable workaround. If we want everything to be clean, there are more things that have to be thrown away. what about this: have a primitive \copyfont which creates a copy of a font. Example: \letterspacefont\lsfont\font 100 \copyfont\lsxfont\lsfont \pdffontexpand\lsxfont 20 20 5 autoexpand ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-27 11:43 Message: Logged In: YES user_id=1608 If there is no clean way of solving the problem, I'd rather just document the error message as a feature. I find \pdfnewexpandfont very ugly (sorry Thanh). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 10:46 Message: Logged In: YES user_id=710 here is a patch that introduces a new primitive \pdfnewexpandfont. Usage: \font\f=cmr10 \pdfnewexpandfont\fx \f 20 20 5 autoexpand Note that \pdfnewexpandfont generates \fx by loading a TFM corresponding to \f first, then applies font expansion in the same way like "\pdffontexpand\fx 20 20 5". So when \f is a font that doesn't have a corresponding TFM (for example, because it was generated in pdftex memory only), the above command won't work. In particular, the following doesn't work: \font\f=cmr10 \letterspacefont\lsfont\f 100 \pdfnewexpandfont\fx \lsfont 20 20 5 autoexpand since \lsfont doesn't have a corresponding TFM but was generated by \letterspacefont. To create a letterspaced+expanded font, one can use: \font\f=cmr10 \letterspacefont\fx\f 100 \pdffontexpand\fx 20 20 5 autoexpand things are gettting messy... sorry about that. Testing/comments welcome. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-04-01 00:44 Message: Logged In: YES user_id=2217 Fine for me and microtype. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-31 09:52 Message: Logged In: YES user_id=710 either name is ok with me. We need a new pritimive to load a new font and expand it, since the current one doesn't load a new font and hence is making trouble. I would wait for a while to see how Robert sees it before making any change. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-03-19 11:07 Message: Logged In: NO Hello, I do not think that \pdfexpandfont is a good name for a new primitive, as it is too easy to confuse with \pdffontexpand. What about \pdfexpandnewfont, as -- if I understand correctly -- a new font is loaded? Jonathan P.S: Thank you for creating pdfTeX! ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-10 20:18 Message: Logged In: YES user_id=710 Phil Taylor has a suggestion that seems great to me: introduce a new primitive \pdfexpandfont instead. How do you see it? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 19:24 Message: Logged In: YES user_id=421 Forget that comment. Of course a change of \pdffontexpand has to be considered carefully. By you. :-) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 19:22 Message: Logged In: YES user_id=421 No. It's an undocumented primitive. ;-) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-09 17:28 Message: Logged In: YES user_id=710 sigh. A mistake when implementing the \pdffontexpand primitive: it should load a new font for expansion, instead of expanding a loaded font. Too late for change now? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106

1 0

[ pdftex-Bugs-824 ] Bus error caused by loading an image into a format file
by noreply＠sarovar.org 29 Jun '07

29 Jun '07

Bugs item #824, was opened at 2007-06-25 23:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=824&group_id=106 Category: Image inclusion Group: v1.40.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Robin Houston (robinhouston) Assigned to: Martin Schröder (oneiros) Summary: Bus error caused by loading an image into a format file Initial Comment: I have written a tool that speeds up repeated compilation of a source file, by generating a format from the preamble of the document, and then using it to compile the body. One user reported a crash when using this tool with a custom letterhead class; the class in question may be found at http://www.soe.ucsc.edu/~elm/LaTeX/ucletter.cls (though note that a simpler demonstration is attached to this report). The bug is triggered by the fact that this class loads an image during the processing of the preamble (i.e. during the processing of the .ini file) and saves it in a box. When this box is used, during the compilation of the body, pdftex crashes. This does work with ordinary (non-PDF) TeX, so the problem is specific to PDFTeX. The attachment contains a simple demonstration of the problem. Unpack it and run 'make'. ---------------------------------------------------------------------- >Comment By: Robin Houston (robinhouston) Date: 2007-06-29 16:24 Message: Logged In: YES user_id=4579 PS. I have just attached a new tar file, containing some simple tests that create PDF from the IniTeX run. They all appear to work, when my patch is applied. ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-29 16:19 Message: Logged In: YES user_id=4579 I don't think creating a PDF file from the IniTeX run is a real problem. The attached tiny patch (to be applied on top of Taco Hoekwater's first patch) seems to make it work. Am I missing something? ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-29 11:34 Message: Logged In: YES user_id=1608 Here is the promised extra patch. No error is generated, just a simple warning. Pdftex continues executing as if \end was given instead. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-06-28 21:33 Message: Logged In: NO Hi, the inability to _both_ dump a format _and_ produce output in the same iniTeX run is probably tolerable as long as no crashes occur. I don't know the workings of WhizzyTeX in detail: it is conceivable that their in-document dump would be affected. However, it is unlikely that WhizzyTeX will indeed require both the output as well as the dump (the dump may well contain pictures, for example from floats that are going to be placed later), so there is at least a reasonable way to tackle this from the macro level (divert \shipout in the manner of the everyshi.sty package). At least mylatex.ltx (and consequently preview-latex) should work fine: \shipout before \begin{document} would be extremely unusual and would result in strange results, anyway. David ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-28 20:09 Message: Logged In: YES user_id=1608 Small limitation that I have yet to implement: the ability to move stuff over from the initex run means that if initex actually creates a pdf file, dumping a format should be disallowed, or silently ignored. Attempting to keep track of two disjunct pdf documents is just too hard for me. Note that I do not want to prohibit pdf creation from initex. Just that you can't create a pdf document _as well as_ perform a \dump. ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-28 16:01 Message: Logged In: YES user_id=4579 Bravo! I was ready to embark on this myself, so I'm delighted to be spared the trouble. It passes all the tests I've tried so far. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-28 11:57 Message: Logged In: YES user_id=1608 Here is a patch that fixes the problem by dumping and restoring the image _meta information_ to/from any generated format. The image _data_ is not included (that would be really hard to do in a portable way), and therefore the undumping routines have to redo most of the work of \pdfximage, but this is transparent to the user except that the tests for \pdfminorversion and \pdfinclusionerrorlevel tests are re-done. The patch also saves some pdftex arrays that are needed to rediscover the object. This could eventually be extended to make sure \refxform et al work as well. As of now, that is untested due to lack of example. Comments and testing welcome, as always. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-26 22:01 Message: Logged In: YES user_id=421 Sorry, pdf things work different then dvi, so we can not make \pdfximage etc. in ini mode without a lot of work; we will probably disable a bunch of primitives. ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-26 14:49 Message: Logged In: YES user_id=4579 Simplifying the example by eliminating the graphics package: ==> foo.ini <== \documentclass{minimal} \newbox\picbox \pdfximage{pic.pdf} \setbox\picbox\hbox{\pdfrefximage\pdflastximage} \dump ==> foo.tex <== \begin{document} \box\picbox \end{document} Also, I see now that my comparison with dvi-mode is indeed a false one, because the mechanisms are quite different, and the DVI graphics driver only has to include a \special, rather than the graphic itself. A simple solution, I suppose, would be to make \pdfrefximage (and, presumably, the other \pdfrefx commands) invalid in IniTeX mode. Perhaps this is too brutal, since it forbids certain harmless activities such as finding the dimensions of an image from an .ini file; and of course I would be delighted if it were made to work instead. ---------------------------------------------------------------------- Comment By: Reinhard Kotucha (reinhard) Date: 2007-06-26 00:26 Message: Logged In: YES user_id=4195 Martin, you probably can't do everything in a format file. However, it would be nice to be able to put graphics to a format file at least. Suppose that a web server has to generate PDF files on-the-fly, each contains a company logo. The best place place for the logo is the format file if speed matters. It would be nice if there are no restrictions. Regards, Reinhard ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-25 23:42 Message: Logged In: YES user_id=4579 I'm impressed by the speed of your response! Thanks. If you replace the PDF image by an EPS file, and use -output-format dvi, then it does work. That suggests to me that the problem is not fundamentally caused by a limitation of IniTeX. But I don't know enough about the inner workings of the \includegraphics command to be sure about that. (Perhaps PDF graphics are handled in a sufficiently different way for this to be a false comparison?) In any case, as you say, it shouldn't crash! ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-25 23:30 Message: Logged In: YES user_id=421 I can reproduce it, and it obviously shouldn't crash, but I'm really not shure if it's supposed to work, as the format of course will not save the picture. You can't do everything in IniTeX... ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=824&group_id=106

1 0

[ pdftex-Bugs-824 ] Bus error caused by loading an image into a format file
by noreply＠sarovar.org 29 Jun '07

29 Jun '07

Bugs item #824, was opened at 2007-06-25 23:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=824&group_id=106 Category: Image inclusion Group: v1.40.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Robin Houston (robinhouston) Assigned to: Martin Schröder (oneiros) Summary: Bus error caused by loading an image into a format file Initial Comment: I have written a tool that speeds up repeated compilation of a source file, by generating a format from the preamble of the document, and then using it to compile the body. One user reported a crash when using this tool with a custom letterhead class; the class in question may be found at http://www.soe.ucsc.edu/~elm/LaTeX/ucletter.cls (though note that a simpler demonstration is attached to this report). The bug is triggered by the fact that this class loads an image during the processing of the preamble (i.e. during the processing of the .ini file) and saves it in a box. When this box is used, during the compilation of the body, pdftex crashes. This does work with ordinary (non-PDF) TeX, so the problem is specific to PDFTeX. The attachment contains a simple demonstration of the problem. Unpack it and run 'make'. ---------------------------------------------------------------------- >Comment By: Robin Houston (robinhouston) Date: 2007-06-29 16:19 Message: Logged In: YES user_id=4579 I don't think creating a PDF file from the IniTeX run is a real problem. The attached tiny patch (to be applied on top of Taco Hoekwater's first patch) seems to make it work. Am I missing something? ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-29 11:34 Message: Logged In: YES user_id=1608 Here is the promised extra patch. No error is generated, just a simple warning. Pdftex continues executing as if \end was given instead. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-06-28 21:33 Message: Logged In: NO Hi, the inability to _both_ dump a format _and_ produce output in the same iniTeX run is probably tolerable as long as no crashes occur. I don't know the workings of WhizzyTeX in detail: it is conceivable that their in-document dump would be affected. However, it is unlikely that WhizzyTeX will indeed require both the output as well as the dump (the dump may well contain pictures, for example from floats that are going to be placed later), so there is at least a reasonable way to tackle this from the macro level (divert \shipout in the manner of the everyshi.sty package). At least mylatex.ltx (and consequently preview-latex) should work fine: \shipout before \begin{document} would be extremely unusual and would result in strange results, anyway. David ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-28 20:09 Message: Logged In: YES user_id=1608 Small limitation that I have yet to implement: the ability to move stuff over from the initex run means that if initex actually creates a pdf file, dumping a format should be disallowed, or silently ignored. Attempting to keep track of two disjunct pdf documents is just too hard for me. Note that I do not want to prohibit pdf creation from initex. Just that you can't create a pdf document _as well as_ perform a \dump. ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-28 16:01 Message: Logged In: YES user_id=4579 Bravo! I was ready to embark on this myself, so I'm delighted to be spared the trouble. It passes all the tests I've tried so far. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-28 11:57 Message: Logged In: YES user_id=1608 Here is a patch that fixes the problem by dumping and restoring the image _meta information_ to/from any generated format. The image _data_ is not included (that would be really hard to do in a portable way), and therefore the undumping routines have to redo most of the work of \pdfximage, but this is transparent to the user except that the tests for \pdfminorversion and \pdfinclusionerrorlevel tests are re-done. The patch also saves some pdftex arrays that are needed to rediscover the object. This could eventually be extended to make sure \refxform et al work as well. As of now, that is untested due to lack of example. Comments and testing welcome, as always. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-26 22:01 Message: Logged In: YES user_id=421 Sorry, pdf things work different then dvi, so we can not make \pdfximage etc. in ini mode without a lot of work; we will probably disable a bunch of primitives. ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-26 14:49 Message: Logged In: YES user_id=4579 Simplifying the example by eliminating the graphics package: ==> foo.ini <== \documentclass{minimal} \newbox\picbox \pdfximage{pic.pdf} \setbox\picbox\hbox{\pdfrefximage\pdflastximage} \dump ==> foo.tex <== \begin{document} \box\picbox \end{document} Also, I see now that my comparison with dvi-mode is indeed a false one, because the mechanisms are quite different, and the DVI graphics driver only has to include a \special, rather than the graphic itself. A simple solution, I suppose, would be to make \pdfrefximage (and, presumably, the other \pdfrefx commands) invalid in IniTeX mode. Perhaps this is too brutal, since it forbids certain harmless activities such as finding the dimensions of an image from an .ini file; and of course I would be delighted if it were made to work instead. ---------------------------------------------------------------------- Comment By: Reinhard Kotucha (reinhard) Date: 2007-06-26 00:26 Message: Logged In: YES user_id=4195 Martin, you probably can't do everything in a format file. However, it would be nice to be able to put graphics to a format file at least. Suppose that a web server has to generate PDF files on-the-fly, each contains a company logo. The best place place for the logo is the format file if speed matters. It would be nice if there are no restrictions. Regards, Reinhard ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-25 23:42 Message: Logged In: YES user_id=4579 I'm impressed by the speed of your response! Thanks. If you replace the PDF image by an EPS file, and use -output-format dvi, then it does work. That suggests to me that the problem is not fundamentally caused by a limitation of IniTeX. But I don't know enough about the inner workings of the \includegraphics command to be sure about that. (Perhaps PDF graphics are handled in a sufficiently different way for this to be a false comparison?) In any case, as you say, it shouldn't crash! ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-25 23:30 Message: Logged In: YES user_id=421 I can reproduce it, and it obviously shouldn't crash, but I'm really not shure if it's supposed to work, as the format of course will not save the picture. You can't do everything in IniTeX... ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=824&group_id=106

1 0

[ pdftex-Bugs-747 ] \letterspacefont and \pdffontexpand, again
by noreply＠sarovar.org 29 Jun '07

29 Jun '07

Bugs item #747, was opened at 2007-03-09 03:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106 Category: hz Group: v1.40.1 Status: Open Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: \letterspacefont and \pdffontexpand, again Initial Comment: When expanding a letterspaced font, the base font will be expanded, too, resulting in the error `font has been expanded with different parameters' when the base font is expanded again: \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand \pdffontexpand\font 20 20 5 autoexpand Z\bye ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2007-06-29 13:32 Message: Logged In: YES user_id=710 patch deleted. Needs more testing. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-29 09:56 Message: Logged In: YES user_id=710 sorry, I didn't test it carefully enough. Here is another attempt (tested with the microtype manual). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-29 08:52 Message: Logged In: YES user_id=421 Taco, the new_font_type -> real_font_type is from the fix for bug #722. We need an svn... :-( ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-29 07:22 Message: Logged In: YES user_id=1608 On my (fairly) clean sources, one hunk is rejected because of this: else begin if pdf_font_type[f] <> new_font_type then pdf_warning("font expansion", "font should be expanded before its first use", true, true); end; My pdftex.web uses pdf_font_type[f] = real_font_type in that test. I fixed the hunk, but I also get a crash on Robert's test file. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-06-28 23:17 Message: Logged In: YES user_id=2217 Now this yields a core dump with: \pdfadjustspacing2 \pdffontexpand\font 20 20 5 autoexpand \hsize10em Lorem ipsum dolor sit amet, \bye (unless I've messed up pdftex.web with all them patches) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-28 20:17 Message: Logged In: YES user_id=710 here is another patch, which introduces \pdfcopyfont. Example: \letterspacefont\lsfont\font 100 \pdfcopyfont\lsxfont\lsfont \pdffontexpand\lsxfont 20 20 5 autoexpand This patch also fixed a bug in expanding local font from virtual fonts: font shrinking didn't work. Big thanks to Robert for help with testing. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-28 18:42 Message: Logged In: YES user_id=710 expanding a letterspaced fonts always implies that the base font is expanded. In other words, it's impossible *not* to expand the base font when expanding a letterspaced font. thanks for further testing. It looks like a bug in checking font expansion spec. fwiw, font stretch limit is always fixed to [0..1000] and font shrink limit to [0..500]. Thus giving a negative value has the same effect like giving 0. I will play with \copyfont to see if it helps. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-06-28 14:01 Message: Logged In: YES user_id=2217 If we can get rid of the error message, I think it can be left at that. Mind you, the problem is not how to expand a letterspaced font but how to *not* expand the base font when expanding a letterspaced font. That expanding a letterspaced font results in expansion of the base font can be documented as a feature, IMO. Here are some more clues: The error message seems to be related to the sign of the stretch parameter. First of all, with \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand the base font will be expanded, however it will never be shrunk. Then, \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand \pdffontexpand\font 20 -20 5 autoexpand doesn't yield an error. Neither does: \pdffontexpand\lsfont 20 -20 5 autoexpand \pdffontexpand\font 20 -20 5 autoexpand However, here comes the error again: \pdffontexpand\lsfont 20 -20 5 autoexpand \pdffontexpand\font 20 20 5 autoexpand If you expand the base font first, it's OK in any case, also with different signs. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-28 07:37 Message: Logged In: YES user_id=1608 That sounds nice, I like it. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-28 06:45 Message: Logged In: YES user_id=710 I agree this is an ugly solution, which has its origin in a design mistake. However the problem here is not only how to deal with the error message, but the point is how to use font expansion with a letterspaced font. Please give it a thought so we can come up with an acceptable workaround. If we want everything to be clean, there are more things that have to be thrown away. what about this: have a primitive \copyfont which creates a copy of a font. Example: \letterspacefont\lsfont\font 100 \copyfont\lsxfont\lsfont \pdffontexpand\lsxfont 20 20 5 autoexpand ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-27 11:43 Message: Logged In: YES user_id=1608 If there is no clean way of solving the problem, I'd rather just document the error message as a feature. I find \pdfnewexpandfont very ugly (sorry Thanh). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 10:46 Message: Logged In: YES user_id=710 here is a patch that introduces a new primitive \pdfnewexpandfont. Usage: \font\f=cmr10 \pdfnewexpandfont\fx \f 20 20 5 autoexpand Note that \pdfnewexpandfont generates \fx by loading a TFM corresponding to \f first, then applies font expansion in the same way like "\pdffontexpand\fx 20 20 5". So when \f is a font that doesn't have a corresponding TFM (for example, because it was generated in pdftex memory only), the above command won't work. In particular, the following doesn't work: \font\f=cmr10 \letterspacefont\lsfont\f 100 \pdfnewexpandfont\fx \lsfont 20 20 5 autoexpand since \lsfont doesn't have a corresponding TFM but was generated by \letterspacefont. To create a letterspaced+expanded font, one can use: \font\f=cmr10 \letterspacefont\fx\f 100 \pdffontexpand\fx 20 20 5 autoexpand things are gettting messy... sorry about that. Testing/comments welcome. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-04-01 00:44 Message: Logged In: YES user_id=2217 Fine for me and microtype. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-31 09:52 Message: Logged In: YES user_id=710 either name is ok with me. We need a new pritimive to load a new font and expand it, since the current one doesn't load a new font and hence is making trouble. I would wait for a while to see how Robert sees it before making any change. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-03-19 11:07 Message: Logged In: NO Hello, I do not think that \pdfexpandfont is a good name for a new primitive, as it is too easy to confuse with \pdffontexpand. What about \pdfexpandnewfont, as -- if I understand correctly -- a new font is loaded? Jonathan P.S: Thank you for creating pdfTeX! ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-10 20:18 Message: Logged In: YES user_id=710 Phil Taylor has a suggestion that seems great to me: introduce a new primitive \pdfexpandfont instead. How do you see it? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 19:24 Message: Logged In: YES user_id=421 Forget that comment. Of course a change of \pdffontexpand has to be considered carefully. By you. :-) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 19:22 Message: Logged In: YES user_id=421 No. It's an undocumented primitive. ;-) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-09 17:28 Message: Logged In: YES user_id=710 sigh. A mistake when implementing the \pdffontexpand primitive: it should load a new font for expansion, instead of expanding a loaded font. Too late for change now? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106

1 0

[ pdftex-Patches-812 ] added \pdfkeeplinedimen primitive
by noreply＠sarovar.org 29 Jun '07

29 Jun '07

Patches item #812, was opened at 2007-06-23 17:23 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106 Category: Primitives Group: v1.50.0 Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: added \pdfkeeplinedimen primitive Initial Comment: This patch introduces a new primitive \pdfkeepdimenline, which is an addon to bring some more flexibity to the existing \pdflastlinedepth, \pdffirstlineheight, \pdfeachlinedepth and \pdfeachlineheight primitives. Those primitives are set to 0 by default, and they take effect only if the user sets them to a non-zero value (as one can guess from their names, they fix line dimensions of a paragraph). The issue with those primitives is that it's impossible to use them with 0, as this value means "don't change line dimens". So this patch introduces \pdfkeepdimenline, a dimen register keeping the value for "don't change line dimens". By default all are set to 0, so the default behaviour is unchanged. For example, to set depth of each line after line breaking to zero, one can say: \pdfkeeplinedimen=\maxdimen \pdfeachlineheight=\pdfkeeplinedimen \pdffirstlineheight=\pdfkeeplinedimen \pdflastlinedepth=\pdfkeeplinedimen \pdfeachlinedepth=0pt Testing/comments welcome. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2007-06-29 11:02 Message: Logged In: YES user_id=710 here is another patch that introduces \pdfignoreddimen as Taco suggested. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 08:41 Message: Logged In: YES user_id=710 sounds good to me. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-24 08:28 Message: Logged In: YES user_id=1608 I see an advantage in having a configurable parameter over the arbitrary constant that \prevdepth currently uses. But if that is the case, it makes sense to apply it to \prevdepth as well. So how about \pdfignoreddimen instead, that defaults to -1000pt, and is also used by \prevdepth ? ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 08:26 Message: Logged In: YES user_id=710 another patch uploaded, so the pdftex team can choose between them. Hope to make Nobody (None) happy. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-06-23 17:29 Message: Logged In: NO This is completely clunky and awkward. Instead of having some magic variable which changes the meaning of _all_ addresses here, how about just using \prevdepth's default for "no change", namely -1000pt? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106

1 0

[ pdftex-Bugs-824 ] Bus error caused by loading an image into a format file
by noreply＠sarovar.org 29 Jun '07

29 Jun '07

Bugs item #824, was opened at 2007-06-26 00:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=824&group_id=106 Category: Image inclusion Group: v1.40.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Robin Houston (robinhouston) Assigned to: Martin Schröder (oneiros) Summary: Bus error caused by loading an image into a format file Initial Comment: I have written a tool that speeds up repeated compilation of a source file, by generating a format from the preamble of the document, and then using it to compile the body. One user reported a crash when using this tool with a custom letterhead class; the class in question may be found at http://www.soe.ucsc.edu/~elm/LaTeX/ucletter.cls (though note that a simpler demonstration is attached to this report). The bug is triggered by the fact that this class loads an image during the processing of the preamble (i.e. during the processing of the .ini file) and saves it in a box. When this box is used, during the compilation of the body, pdftex crashes. This does work with ordinary (non-PDF) TeX, so the problem is specific to PDFTeX. The attachment contains a simple demonstration of the problem. Unpack it and run 'make'. ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2007-06-29 12:34 Message: Logged In: YES user_id=1608 Here is the promised extra patch. No error is generated, just a simple warning. Pdftex continues executing as if \end was given instead. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-06-28 22:33 Message: Logged In: NO Hi, the inability to _both_ dump a format _and_ produce output in the same iniTeX run is probably tolerable as long as no crashes occur. I don't know the workings of WhizzyTeX in detail: it is conceivable that their in-document dump would be affected. However, it is unlikely that WhizzyTeX will indeed require both the output as well as the dump (the dump may well contain pictures, for example from floats that are going to be placed later), so there is at least a reasonable way to tackle this from the macro level (divert \shipout in the manner of the everyshi.sty package). At least mylatex.ltx (and consequently preview-latex) should work fine: \shipout before \begin{document} would be extremely unusual and would result in strange results, anyway. David ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-28 21:09 Message: Logged In: YES user_id=1608 Small limitation that I have yet to implement: the ability to move stuff over from the initex run means that if initex actually creates a pdf file, dumping a format should be disallowed, or silently ignored. Attempting to keep track of two disjunct pdf documents is just too hard for me. Note that I do not want to prohibit pdf creation from initex. Just that you can't create a pdf document _as well as_ perform a \dump. ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-28 17:01 Message: Logged In: YES user_id=4579 Bravo! I was ready to embark on this myself, so I'm delighted to be spared the trouble. It passes all the tests I've tried so far. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-28 12:57 Message: Logged In: YES user_id=1608 Here is a patch that fixes the problem by dumping and restoring the image _meta information_ to/from any generated format. The image _data_ is not included (that would be really hard to do in a portable way), and therefore the undumping routines have to redo most of the work of \pdfximage, but this is transparent to the user except that the tests for \pdfminorversion and \pdfinclusionerrorlevel tests are re-done. The patch also saves some pdftex arrays that are needed to rediscover the object. This could eventually be extended to make sure \refxform et al work as well. As of now, that is untested due to lack of example. Comments and testing welcome, as always. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-26 23:01 Message: Logged In: YES user_id=421 Sorry, pdf things work different then dvi, so we can not make \pdfximage etc. in ini mode without a lot of work; we will probably disable a bunch of primitives. ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-26 15:49 Message: Logged In: YES user_id=4579 Simplifying the example by eliminating the graphics package: ==> foo.ini <== \documentclass{minimal} \newbox\picbox \pdfximage{pic.pdf} \setbox\picbox\hbox{\pdfrefximage\pdflastximage} \dump ==> foo.tex <== \begin{document} \box\picbox \end{document} Also, I see now that my comparison with dvi-mode is indeed a false one, because the mechanisms are quite different, and the DVI graphics driver only has to include a \special, rather than the graphic itself. A simple solution, I suppose, would be to make \pdfrefximage (and, presumably, the other \pdfrefx commands) invalid in IniTeX mode. Perhaps this is too brutal, since it forbids certain harmless activities such as finding the dimensions of an image from an .ini file; and of course I would be delighted if it were made to work instead. ---------------------------------------------------------------------- Comment By: Reinhard Kotucha (reinhard) Date: 2007-06-26 01:26 Message: Logged In: YES user_id=4195 Martin, you probably can't do everything in a format file. However, it would be nice to be able to put graphics to a format file at least. Suppose that a web server has to generate PDF files on-the-fly, each contains a company logo. The best place place for the logo is the format file if speed matters. It would be nice if there are no restrictions. Regards, Reinhard ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-26 00:42 Message: Logged In: YES user_id=4579 I'm impressed by the speed of your response! Thanks. If you replace the PDF image by an EPS file, and use -output-format dvi, then it does work. That suggests to me that the problem is not fundamentally caused by a limitation of IniTeX. But I don't know enough about the inner workings of the \includegraphics command to be sure about that. (Perhaps PDF graphics are handled in a sufficiently different way for this to be a false comparison?) In any case, as you say, it shouldn't crash! ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-26 00:30 Message: Logged In: YES user_id=421 I can reproduce it, and it obviously shouldn't crash, but I'm really not shure if it's supposed to work, as the format of course will not save the picture. You can't do everything in IniTeX... ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=824&group_id=106

1 0

[ pdftex-Bugs-747 ] \letterspacefont and \pdffontexpand, again
by noreply＠sarovar.org 29 Jun '07

29 Jun '07

Bugs item #747, was opened at 2007-03-09 03:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106 Category: hz Group: v1.40.1 Status: Open Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: \letterspacefont and \pdffontexpand, again Initial Comment: When expanding a letterspaced font, the base font will be expanded, too, resulting in the error `font has been expanded with different parameters' when the base font is expanded again: \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand \pdffontexpand\font 20 20 5 autoexpand Z\bye ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2007-06-29 09:56 Message: Logged In: YES user_id=710 sorry, I didn't test it carefully enough. Here is another attempt (tested with the microtype manual). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-29 08:52 Message: Logged In: YES user_id=421 Taco, the new_font_type -> real_font_type is from the fix for bug #722. We need an svn... :-( ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-29 07:22 Message: Logged In: YES user_id=1608 On my (fairly) clean sources, one hunk is rejected because of this: else begin if pdf_font_type[f] <> new_font_type then pdf_warning("font expansion", "font should be expanded before its first use", true, true); end; My pdftex.web uses pdf_font_type[f] = real_font_type in that test. I fixed the hunk, but I also get a crash on Robert's test file. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-06-28 23:17 Message: Logged In: YES user_id=2217 Now this yields a core dump with: \pdfadjustspacing2 \pdffontexpand\font 20 20 5 autoexpand \hsize10em Lorem ipsum dolor sit amet, \bye (unless I've messed up pdftex.web with all them patches) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-28 20:17 Message: Logged In: YES user_id=710 here is another patch, which introduces \pdfcopyfont. Example: \letterspacefont\lsfont\font 100 \pdfcopyfont\lsxfont\lsfont \pdffontexpand\lsxfont 20 20 5 autoexpand This patch also fixed a bug in expanding local font from virtual fonts: font shrinking didn't work. Big thanks to Robert for help with testing. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-28 18:42 Message: Logged In: YES user_id=710 expanding a letterspaced fonts always implies that the base font is expanded. In other words, it's impossible *not* to expand the base font when expanding a letterspaced font. thanks for further testing. It looks like a bug in checking font expansion spec. fwiw, font stretch limit is always fixed to [0..1000] and font shrink limit to [0..500]. Thus giving a negative value has the same effect like giving 0. I will play with \copyfont to see if it helps. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-06-28 14:01 Message: Logged In: YES user_id=2217 If we can get rid of the error message, I think it can be left at that. Mind you, the problem is not how to expand a letterspaced font but how to *not* expand the base font when expanding a letterspaced font. That expanding a letterspaced font results in expansion of the base font can be documented as a feature, IMO. Here are some more clues: The error message seems to be related to the sign of the stretch parameter. First of all, with \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand the base font will be expanded, however it will never be shrunk. Then, \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand \pdffontexpand\font 20 -20 5 autoexpand doesn't yield an error. Neither does: \pdffontexpand\lsfont 20 -20 5 autoexpand \pdffontexpand\font 20 -20 5 autoexpand However, here comes the error again: \pdffontexpand\lsfont 20 -20 5 autoexpand \pdffontexpand\font 20 20 5 autoexpand If you expand the base font first, it's OK in any case, also with different signs. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-28 07:37 Message: Logged In: YES user_id=1608 That sounds nice, I like it. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-28 06:45 Message: Logged In: YES user_id=710 I agree this is an ugly solution, which has its origin in a design mistake. However the problem here is not only how to deal with the error message, but the point is how to use font expansion with a letterspaced font. Please give it a thought so we can come up with an acceptable workaround. If we want everything to be clean, there are more things that have to be thrown away. what about this: have a primitive \copyfont which creates a copy of a font. Example: \letterspacefont\lsfont\font 100 \copyfont\lsxfont\lsfont \pdffontexpand\lsxfont 20 20 5 autoexpand ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-27 11:43 Message: Logged In: YES user_id=1608 If there is no clean way of solving the problem, I'd rather just document the error message as a feature. I find \pdfnewexpandfont very ugly (sorry Thanh). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 10:46 Message: Logged In: YES user_id=710 here is a patch that introduces a new primitive \pdfnewexpandfont. Usage: \font\f=cmr10 \pdfnewexpandfont\fx \f 20 20 5 autoexpand Note that \pdfnewexpandfont generates \fx by loading a TFM corresponding to \f first, then applies font expansion in the same way like "\pdffontexpand\fx 20 20 5". So when \f is a font that doesn't have a corresponding TFM (for example, because it was generated in pdftex memory only), the above command won't work. In particular, the following doesn't work: \font\f=cmr10 \letterspacefont\lsfont\f 100 \pdfnewexpandfont\fx \lsfont 20 20 5 autoexpand since \lsfont doesn't have a corresponding TFM but was generated by \letterspacefont. To create a letterspaced+expanded font, one can use: \font\f=cmr10 \letterspacefont\fx\f 100 \pdffontexpand\fx 20 20 5 autoexpand things are gettting messy... sorry about that. Testing/comments welcome. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-04-01 00:44 Message: Logged In: YES user_id=2217 Fine for me and microtype. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-31 09:52 Message: Logged In: YES user_id=710 either name is ok with me. We need a new pritimive to load a new font and expand it, since the current one doesn't load a new font and hence is making trouble. I would wait for a while to see how Robert sees it before making any change. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-03-19 11:07 Message: Logged In: NO Hello, I do not think that \pdfexpandfont is a good name for a new primitive, as it is too easy to confuse with \pdffontexpand. What about \pdfexpandnewfont, as -- if I understand correctly -- a new font is loaded? Jonathan P.S: Thank you for creating pdfTeX! ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-10 20:18 Message: Logged In: YES user_id=710 Phil Taylor has a suggestion that seems great to me: introduce a new primitive \pdfexpandfont instead. How do you see it? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 19:24 Message: Logged In: YES user_id=421 Forget that comment. Of course a change of \pdffontexpand has to be considered carefully. By you. :-) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 19:22 Message: Logged In: YES user_id=421 No. It's an undocumented primitive. ;-) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-09 17:28 Message: Logged In: YES user_id=710 sigh. A mistake when implementing the \pdffontexpand primitive: it should load a new font for expansion, instead of expanding a loaded font. Too late for change now? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106

1 0

[ pdftex-Bugs-747 ] \letterspacefont and \pdffontexpand, again
by noreply＠sarovar.org 29 Jun '07

29 Jun '07

Bugs item #747, was opened at 2007-03-09 04:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106 Category: hz Group: v1.40.1 Status: Open Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: \letterspacefont and \pdffontexpand, again Initial Comment: When expanding a letterspaced font, the base font will be expanded, too, resulting in the error `font has been expanded with different parameters' when the base font is expanded again: \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand \pdffontexpand\font 20 20 5 autoexpand Z\bye ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-06-29 10:52 Message: Logged In: YES user_id=421 Taco, the new_font_type -> real_font_type is from the fix for bug #722. We need an svn... :-( ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-29 09:22 Message: Logged In: YES user_id=1608 On my (fairly) clean sources, one hunk is rejected because of this: else begin if pdf_font_type[f] <> new_font_type then pdf_warning("font expansion", "font should be expanded before its first use", true, true); end; My pdftex.web uses pdf_font_type[f] = real_font_type in that test. I fixed the hunk, but I also get a crash on Robert's test file. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-06-29 01:17 Message: Logged In: YES user_id=2217 Now this yields a core dump with: \pdfadjustspacing2 \pdffontexpand\font 20 20 5 autoexpand \hsize10em Lorem ipsum dolor sit amet, \bye (unless I've messed up pdftex.web with all them patches) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-28 22:17 Message: Logged In: YES user_id=710 here is another patch, which introduces \pdfcopyfont. Example: \letterspacefont\lsfont\font 100 \pdfcopyfont\lsxfont\lsfont \pdffontexpand\lsxfont 20 20 5 autoexpand This patch also fixed a bug in expanding local font from virtual fonts: font shrinking didn't work. Big thanks to Robert for help with testing. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-28 20:42 Message: Logged In: YES user_id=710 expanding a letterspaced fonts always implies that the base font is expanded. In other words, it's impossible *not* to expand the base font when expanding a letterspaced font. thanks for further testing. It looks like a bug in checking font expansion spec. fwiw, font stretch limit is always fixed to [0..1000] and font shrink limit to [0..500]. Thus giving a negative value has the same effect like giving 0. I will play with \copyfont to see if it helps. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-06-28 16:01 Message: Logged In: YES user_id=2217 If we can get rid of the error message, I think it can be left at that. Mind you, the problem is not how to expand a letterspaced font but how to *not* expand the base font when expanding a letterspaced font. That expanding a letterspaced font results in expansion of the base font can be documented as a feature, IMO. Here are some more clues: The error message seems to be related to the sign of the stretch parameter. First of all, with \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand the base font will be expanded, however it will never be shrunk. Then, \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand \pdffontexpand\font 20 -20 5 autoexpand doesn't yield an error. Neither does: \pdffontexpand\lsfont 20 -20 5 autoexpand \pdffontexpand\font 20 -20 5 autoexpand However, here comes the error again: \pdffontexpand\lsfont 20 -20 5 autoexpand \pdffontexpand\font 20 20 5 autoexpand If you expand the base font first, it's OK in any case, also with different signs. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-28 09:37 Message: Logged In: YES user_id=1608 That sounds nice, I like it. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-28 08:45 Message: Logged In: YES user_id=710 I agree this is an ugly solution, which has its origin in a design mistake. However the problem here is not only how to deal with the error message, but the point is how to use font expansion with a letterspaced font. Please give it a thought so we can come up with an acceptable workaround. If we want everything to be clean, there are more things that have to be thrown away. what about this: have a primitive \copyfont which creates a copy of a font. Example: \letterspacefont\lsfont\font 100 \copyfont\lsxfont\lsfont \pdffontexpand\lsxfont 20 20 5 autoexpand ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-27 13:43 Message: Logged In: YES user_id=1608 If there is no clean way of solving the problem, I'd rather just document the error message as a feature. I find \pdfnewexpandfont very ugly (sorry Thanh). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 12:46 Message: Logged In: YES user_id=710 here is a patch that introduces a new primitive \pdfnewexpandfont. Usage: \font\f=cmr10 \pdfnewexpandfont\fx \f 20 20 5 autoexpand Note that \pdfnewexpandfont generates \fx by loading a TFM corresponding to \f first, then applies font expansion in the same way like "\pdffontexpand\fx 20 20 5". So when \f is a font that doesn't have a corresponding TFM (for example, because it was generated in pdftex memory only), the above command won't work. In particular, the following doesn't work: \font\f=cmr10 \letterspacefont\lsfont\f 100 \pdfnewexpandfont\fx \lsfont 20 20 5 autoexpand since \lsfont doesn't have a corresponding TFM but was generated by \letterspacefont. To create a letterspaced+expanded font, one can use: \font\f=cmr10 \letterspacefont\fx\f 100 \pdffontexpand\fx 20 20 5 autoexpand things are gettting messy... sorry about that. Testing/comments welcome. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-04-01 02:44 Message: Logged In: YES user_id=2217 Fine for me and microtype. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-31 11:52 Message: Logged In: YES user_id=710 either name is ok with me. We need a new pritimive to load a new font and expand it, since the current one doesn't load a new font and hence is making trouble. I would wait for a while to see how Robert sees it before making any change. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-03-19 12:07 Message: Logged In: NO Hello, I do not think that \pdfexpandfont is a good name for a new primitive, as it is too easy to confuse with \pdffontexpand. What about \pdfexpandnewfont, as -- if I understand correctly -- a new font is loaded? Jonathan P.S: Thank you for creating pdfTeX! ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-10 21:18 Message: Logged In: YES user_id=710 Phil Taylor has a suggestion that seems great to me: introduce a new primitive \pdfexpandfont instead. How do you see it? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 20:24 Message: Logged In: YES user_id=421 Forget that comment. Of course a change of \pdffontexpand has to be considered carefully. By you. :-) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 20:22 Message: Logged In: YES user_id=421 No. It's an undocumented primitive. ;-) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-09 18:28 Message: Logged In: YES user_id=710 sigh. A mistake when implementing the \pdffontexpand primitive: it should load a new font for expansion, instead of expanding a loaded font. Too late for change now? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106

1 0

Re: [NTG-pdftex] images in formats
by Thanh Han The 29 Jun '07

29 Jun '07

dumping an image in pdf mode is rather difficult to get right. If in dvi mode an image is "stored" by a reference to an external file, then I am afraid the speed gain is not that much. There is for sure some comfort by having a dumped file reference in the format, but again that can be also achieved for pdf mode using some macros IMHO. My vote is also to disable \pdfrefximage and the likes in init mode. Thanh On Wed, Jun 27, 2007 at 03:24:28PM +0200, David Kastrup wrote: > > This is the first user complaining in years (it has always been > > broken). I don't forsee many people complaining if we disable it. How > > many people do you know that do \includegraphics in the ini? > > > > Disabling \pdfximage is easy, enabling it is probably much harder > > (Taco is investigating that), and only very few users need it (the > > ones raising the bug don't really unless pdfTeX dumps the complete > > image in the format; meta-infos won't be enough). > > In DVI mode, the dumped meta-info in the special _is_ enough. It is > not expected that the actual contents of included files make it into > hlists/vlists or even the DVI file. If external references break when > moving a format around in the tree or changing the referenced files, > nobody will be very much surprised. PDFTeX should likely try to avoid > crashing or acting all too unpredictable, but that's more or less all. > It would seem reasonable to not change the reserved space at all in > the hlist/vlist, and align the image at the upper left corner of it, > regardless of what size it has now. > > There is the question of just when to complain when an image source > has disappeared. Probably format read time would be correct.

6 14

[ pdftex-Bugs-747 ] \letterspacefont and \pdffontexpand, again
by noreply＠sarovar.org 29 Jun '07

29 Jun '07

Bugs item #747, was opened at 2007-03-09 04:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106 Category: hz Group: v1.40.1 Status: Open Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: \letterspacefont and \pdffontexpand, again Initial Comment: When expanding a letterspaced font, the base font will be expanded, too, resulting in the error `font has been expanded with different parameters' when the base font is expanded again: \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand \pdffontexpand\font 20 20 5 autoexpand Z\bye ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2007-06-29 09:22 Message: Logged In: YES user_id=1608 On my (fairly) clean sources, one hunk is rejected because of this: else begin if pdf_font_type[f] <> new_font_type then pdf_warning("font expansion", "font should be expanded before its first use", true, true); end; My pdftex.web uses pdf_font_type[f] = real_font_type in that test. I fixed the hunk, but I also get a crash on Robert's test file. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-06-29 01:17 Message: Logged In: YES user_id=2217 Now this yields a core dump with: \pdfadjustspacing2 \pdffontexpand\font 20 20 5 autoexpand \hsize10em Lorem ipsum dolor sit amet, \bye (unless I've messed up pdftex.web with all them patches) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-28 22:17 Message: Logged In: YES user_id=710 here is another patch, which introduces \pdfcopyfont. Example: \letterspacefont\lsfont\font 100 \pdfcopyfont\lsxfont\lsfont \pdffontexpand\lsxfont 20 20 5 autoexpand This patch also fixed a bug in expanding local font from virtual fonts: font shrinking didn't work. Big thanks to Robert for help with testing. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-28 20:42 Message: Logged In: YES user_id=710 expanding a letterspaced fonts always implies that the base font is expanded. In other words, it's impossible *not* to expand the base font when expanding a letterspaced font. thanks for further testing. It looks like a bug in checking font expansion spec. fwiw, font stretch limit is always fixed to [0..1000] and font shrink limit to [0..500]. Thus giving a negative value has the same effect like giving 0. I will play with \copyfont to see if it helps. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-06-28 16:01 Message: Logged In: YES user_id=2217 If we can get rid of the error message, I think it can be left at that. Mind you, the problem is not how to expand a letterspaced font but how to *not* expand the base font when expanding a letterspaced font. That expanding a letterspaced font results in expansion of the base font can be documented as a feature, IMO. Here are some more clues: The error message seems to be related to the sign of the stretch parameter. First of all, with \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand the base font will be expanded, however it will never be shrunk. Then, \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand \pdffontexpand\font 20 -20 5 autoexpand doesn't yield an error. Neither does: \pdffontexpand\lsfont 20 -20 5 autoexpand \pdffontexpand\font 20 -20 5 autoexpand However, here comes the error again: \pdffontexpand\lsfont 20 -20 5 autoexpand \pdffontexpand\font 20 20 5 autoexpand If you expand the base font first, it's OK in any case, also with different signs. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-28 09:37 Message: Logged In: YES user_id=1608 That sounds nice, I like it. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-28 08:45 Message: Logged In: YES user_id=710 I agree this is an ugly solution, which has its origin in a design mistake. However the problem here is not only how to deal with the error message, but the point is how to use font expansion with a letterspaced font. Please give it a thought so we can come up with an acceptable workaround. If we want everything to be clean, there are more things that have to be thrown away. what about this: have a primitive \copyfont which creates a copy of a font. Example: \letterspacefont\lsfont\font 100 \copyfont\lsxfont\lsfont \pdffontexpand\lsxfont 20 20 5 autoexpand ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-27 13:43 Message: Logged In: YES user_id=1608 If there is no clean way of solving the problem, I'd rather just document the error message as a feature. I find \pdfnewexpandfont very ugly (sorry Thanh). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 12:46 Message: Logged In: YES user_id=710 here is a patch that introduces a new primitive \pdfnewexpandfont. Usage: \font\f=cmr10 \pdfnewexpandfont\fx \f 20 20 5 autoexpand Note that \pdfnewexpandfont generates \fx by loading a TFM corresponding to \f first, then applies font expansion in the same way like "\pdffontexpand\fx 20 20 5". So when \f is a font that doesn't have a corresponding TFM (for example, because it was generated in pdftex memory only), the above command won't work. In particular, the following doesn't work: \font\f=cmr10 \letterspacefont\lsfont\f 100 \pdfnewexpandfont\fx \lsfont 20 20 5 autoexpand since \lsfont doesn't have a corresponding TFM but was generated by \letterspacefont. To create a letterspaced+expanded font, one can use: \font\f=cmr10 \letterspacefont\fx\f 100 \pdffontexpand\fx 20 20 5 autoexpand things are gettting messy... sorry about that. Testing/comments welcome. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-04-01 02:44 Message: Logged In: YES user_id=2217 Fine for me and microtype. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-31 11:52 Message: Logged In: YES user_id=710 either name is ok with me. We need a new pritimive to load a new font and expand it, since the current one doesn't load a new font and hence is making trouble. I would wait for a while to see how Robert sees it before making any change. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-03-19 12:07 Message: Logged In: NO Hello, I do not think that \pdfexpandfont is a good name for a new primitive, as it is too easy to confuse with \pdffontexpand. What about \pdfexpandnewfont, as -- if I understand correctly -- a new font is loaded? Jonathan P.S: Thank you for creating pdfTeX! ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-10 21:18 Message: Logged In: YES user_id=710 Phil Taylor has a suggestion that seems great to me: introduce a new primitive \pdfexpandfont instead. How do you see it? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 20:24 Message: Logged In: YES user_id=421 Forget that comment. Of course a change of \pdffontexpand has to be considered carefully. By you. :-) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 20:22 Message: Logged In: YES user_id=421 No. It's an undocumented primitive. ;-) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-09 18:28 Message: Logged In: YES user_id=710 sigh. A mistake when implementing the \pdffontexpand primitive: it should load a new font for expansion, instead of expanding a loaded font. Too late for change now? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106

1 0