- ntg-pdftex - NTG Mailing Lists

Re: [NTG-pdftex] 1.40.4 incoming
by Akira Kakuto 09 Jul '07

09 Jul '07

> > *** tex.ch.org 2006-12-19 02:35:49.000000000 +0100 > > --- tex.ch 2007-03-07 17:08:49.000000000 +0100 > > Note that tex.ch has been changed since 2006-12-19. > Therefore you will need some manual work, sorry. It was an unnecessary fear. I've checked that the patch is still ok. Best regards, Akira

1 0

Re: [NTG-pdftex] 1.40.4 incoming
by Akira Kakuto 09 Jul '07

09 Jul '07

Hi Martin, > *** tex.ch.org 2006-12-19 02:35:49.000000000 +0100 > --- tex.ch 2007-03-07 17:08:49.000000000 +0100 Note that tex.ch has been changed since 2006-12-19. Therefore you will need some manual work, sorry. Best regards, Akira

1 0

[ pdftex-Patches-811 ] Patch to change warning mesage for conflicting font attributes (given by \pdffontattr)
by noreply＠sarovar.org 08 Jul '07

08 Jul '07

Patches item #811, was opened at 2007-06-23 19:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=811&group_id=106 Category: Fonts Group: v1.50.0 Status: Closed Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Martin Schröder (oneiros) Summary: Patch to change warning mesage for conflicting font attributes (given by \pdffontattr) Initial Comment: This is a tiny patch to change the warning message for conflicting font attributes (as given by \pdffontattr), to make it clearer what is going on. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-07-09 00:12 Message: Logged In: YES user_id=421 This was already included in the fix for #721. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-07-09 00:05 Message: Logged In: YES user_id=421 This patch will be included in the upcoming 1.50 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=811&group_id=106

1 0

[ pdftex-Patches-811 ] Patch to change warning mesage for conflicting font attributes (given by \pdffontattr)
by noreply＠sarovar.org 08 Jul '07

08 Jul '07

Patches item #811, was opened at 2007-06-23 19:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=811&group_id=106 Category: Fonts Group: v1.50.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Martin Schröder (oneiros) Summary: Patch to change warning mesage for conflicting font attributes (given by \pdffontattr) Initial Comment: This is a tiny patch to change the warning message for conflicting font attributes (as given by \pdffontattr), to make it clearer what is going on. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-07-09 00:05 Message: Logged In: YES user_id=421 This patch will be included in the upcoming 1.50 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=811&group_id=106

1 0

[ pdftex-Patches-813 ] new primitive \pdfinclusioncopyfonts
by noreply＠sarovar.org 08 Jul '07

08 Jul '07

Patches item #813, was opened at 2007-06-23 19:28 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=813&group_id=106 Category: Fonts Group: v1.50.0 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: new primitive \pdfinclusioncopyfonts Initial Comment: this is a replacement for \pdfreplacefont, with the opposite semantics. When this is set, fonts from included pdfs are always copied. This is useful to prevent pdftex from replacing fonts in included pdfs, without messing around with map files. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-07-09 00:00 Message: Logged In: YES user_id=421 This patch will be included in the upcoming 1.50 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=813&group_id=106

1 0

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

08 Jul '07

Patches item #812, was opened at 2007-06-23 19: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: Closed >Resolution: Accepted 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: Martin Schröder (oneiros) Date: 2007-07-08 23:52 Message: Logged In: YES user_id=421 This patch will be included in the upcoming 1.50 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-29 13: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 10:41 Message: Logged In: YES user_id=710 sounds good to me. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-24 10: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 10: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 19: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-747 ] \letterspacefont and \pdffontexpand, again
by noreply＠sarovar.org 08 Jul '07

08 Jul '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: Closed >Resolution: Fixed 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-07-08 23:40 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-07-08 22:08 Message: Logged In: YES user_id=710 it seems that Martin refered to stable as the stable branch in svn, not the latest stable release 1.40.3. I checked the patch again, it's good. Thanks. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-07-08 21:45 Message: Logged In: YES user_id=710 the patch bugfix747-5.diff was generated against pdftex-1.40.3 sources as it is at sarovar. I have just verified it again by downloading the tarball from sarovar, unpack it and try the patch. No complain at all, while with bug747-6.diff I got some warnings and one rejection: patching file pdftex.web Hunk #4 succeeded at 9528 (offset -1 lines). Hunk #5 succeeded at 13180 (offset -7 lines). Hunk #6 succeeded at 16751 (offset 2 lines). Hunk #7 succeeded at 17026 (offset 2 lines). Hunk #8 succeeded at 17037 (offset 2 lines). Hunk #9 succeeded at 17171 (offset 41 lines). Hunk #10 succeeded at 17193 (offset 41 lines). Hunk #11 succeeded at 17201 (offset 41 lines). Hunk #12 succeeded at 17211 (offset 41 lines). Hunk #13 FAILED at 17241. Hunk #14 succeeded at 17379 (offset 24 lines). Hunk #15 succeeded at 17644 (offset 40 lines). Hunk #16 succeeded at 19958 (offset 31 lines). Hunk #17 succeeded at 20037 (offset 31 lines). Hunk #18 succeeded at 20189 (offset 21 lines). Hunk #19 succeeded at 30880 (offset 19 lines). Hunk #20 succeeded at 31623 (offset 19 lines). 1 out of 20 hunks FAILED -- saving rejects to file pdftex.web.rej ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-07-08 19:17 Message: Logged In: YES user_id=421 The patch had one rejected hunk against stable and current. A working patch is attached; please check. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-07-04 10:13 Message: Logged In: YES user_id=710 patch updated again. Disable \pdfcopyfont for expanded and letterspaced fonts. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-07-03 23:21 Message: Logged In: YES user_id=710 I didn't consider the situation when an expanded font is copied. It seems pretty much of work is needed to get it right, so probably it is easier to disable \pdfcopyfont for expanded (and letterspaced) fonts. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-07-03 19:39 Message: Logged In: YES user_id=2217 Thanks. Letterspacing+expansion works fine now, and \pdfcopyfont is also useful. I gather an expanded font cannot be copied again, right? (Not that I would deem this necessary.) The messages from the following are a bit weird: \tracingonline1 \font\f=cmr10 \pdfcopyfont\fA\f \pdffontexpand\fA 10 10 5 autoexpand \fA ABC \pdfcopyfont\fB\fA \fB ABC \bye ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-30 18:25 Message: Logged In: YES user_id=710 ah, sorry, here it is. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-06-30 18:12 Message: Logged In: YES user_id=2217 the patch is missing... ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-29 17: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 15:32 Message: Logged In: YES user_id=710 patch deleted. Needs more testing. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-29 11: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 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] 1.40.4 incoming
by Thanh Han The 08 Jul '07

08 Jul '07

On 07.07.2007 15:14, Martin Schr�der wrote: > Please test and tell me what I've forgotten. :-) what about patch #813? It's rather straightforward and handy. Thanh

1 0

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

08 Jul '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-07-08 20:08 Message: Logged In: YES user_id=710 it seems that Martin refered to stable as the stable branch in svn, not the latest stable release 1.40.3. I checked the patch again, it's good. Thanks. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-07-08 19:45 Message: Logged In: YES user_id=710 the patch bugfix747-5.diff was generated against pdftex-1.40.3 sources as it is at sarovar. I have just verified it again by downloading the tarball from sarovar, unpack it and try the patch. No complain at all, while with bug747-6.diff I got some warnings and one rejection: patching file pdftex.web Hunk #4 succeeded at 9528 (offset -1 lines). Hunk #5 succeeded at 13180 (offset -7 lines). Hunk #6 succeeded at 16751 (offset 2 lines). Hunk #7 succeeded at 17026 (offset 2 lines). Hunk #8 succeeded at 17037 (offset 2 lines). Hunk #9 succeeded at 17171 (offset 41 lines). Hunk #10 succeeded at 17193 (offset 41 lines). Hunk #11 succeeded at 17201 (offset 41 lines). Hunk #12 succeeded at 17211 (offset 41 lines). Hunk #13 FAILED at 17241. Hunk #14 succeeded at 17379 (offset 24 lines). Hunk #15 succeeded at 17644 (offset 40 lines). Hunk #16 succeeded at 19958 (offset 31 lines). Hunk #17 succeeded at 20037 (offset 31 lines). Hunk #18 succeeded at 20189 (offset 21 lines). Hunk #19 succeeded at 30880 (offset 19 lines). Hunk #20 succeeded at 31623 (offset 19 lines). 1 out of 20 hunks FAILED -- saving rejects to file pdftex.web.rej ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-07-08 17:17 Message: Logged In: YES user_id=421 The patch had one rejected hunk against stable and current. A working patch is attached; please check. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-07-04 08:13 Message: Logged In: YES user_id=710 patch updated again. Disable \pdfcopyfont for expanded and letterspaced fonts. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-07-03 21:21 Message: Logged In: YES user_id=710 I didn't consider the situation when an expanded font is copied. It seems pretty much of work is needed to get it right, so probably it is easier to disable \pdfcopyfont for expanded (and letterspaced) fonts. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-07-03 17:39 Message: Logged In: YES user_id=2217 Thanks. Letterspacing+expansion works fine now, and \pdfcopyfont is also useful. I gather an expanded font cannot be copied again, right? (Not that I would deem this necessary.) The messages from the following are a bit weird: \tracingonline1 \font\f=cmr10 \pdfcopyfont\fA\f \pdffontexpand\fA 10 10 5 autoexpand \fA ABC \pdfcopyfont\fB\fA \fB ABC \bye ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-30 16:25 Message: Logged In: YES user_id=710 ah, sorry, here it is. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-06-30 16:12 Message: Logged In: YES user_id=2217 the patch is missing... ---------------------------------------------------------------------- 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-747 ] \letterspacefont and \pdffontexpand, again
by noreply＠sarovar.org 08 Jul '07

08 Jul '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-07-08 19:45 Message: Logged In: YES user_id=710 the patch bugfix747-5.diff was generated against pdftex-1.40.3 sources as it is at sarovar. I have just verified it again by downloading the tarball from sarovar, unpack it and try the patch. No complain at all, while with bug747-6.diff I got some warnings and one rejection: patching file pdftex.web Hunk #4 succeeded at 9528 (offset -1 lines). Hunk #5 succeeded at 13180 (offset -7 lines). Hunk #6 succeeded at 16751 (offset 2 lines). Hunk #7 succeeded at 17026 (offset 2 lines). Hunk #8 succeeded at 17037 (offset 2 lines). Hunk #9 succeeded at 17171 (offset 41 lines). Hunk #10 succeeded at 17193 (offset 41 lines). Hunk #11 succeeded at 17201 (offset 41 lines). Hunk #12 succeeded at 17211 (offset 41 lines). Hunk #13 FAILED at 17241. Hunk #14 succeeded at 17379 (offset 24 lines). Hunk #15 succeeded at 17644 (offset 40 lines). Hunk #16 succeeded at 19958 (offset 31 lines). Hunk #17 succeeded at 20037 (offset 31 lines). Hunk #18 succeeded at 20189 (offset 21 lines). Hunk #19 succeeded at 30880 (offset 19 lines). Hunk #20 succeeded at 31623 (offset 19 lines). 1 out of 20 hunks FAILED -- saving rejects to file pdftex.web.rej ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-07-08 17:17 Message: Logged In: YES user_id=421 The patch had one rejected hunk against stable and current. A working patch is attached; please check. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-07-04 08:13 Message: Logged In: YES user_id=710 patch updated again. Disable \pdfcopyfont for expanded and letterspaced fonts. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-07-03 21:21 Message: Logged In: YES user_id=710 I didn't consider the situation when an expanded font is copied. It seems pretty much of work is needed to get it right, so probably it is easier to disable \pdfcopyfont for expanded (and letterspaced) fonts. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-07-03 17:39 Message: Logged In: YES user_id=2217 Thanks. Letterspacing+expansion works fine now, and \pdfcopyfont is also useful. I gather an expanded font cannot be copied again, right? (Not that I would deem this necessary.) The messages from the following are a bit weird: \tracingonline1 \font\f=cmr10 \pdfcopyfont\fA\f \pdffontexpand\fA 10 10 5 autoexpand \fA ABC \pdfcopyfont\fB\fA \fB ABC \bye ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-30 16:25 Message: Logged In: YES user_id=710 ah, sorry, here it is. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-06-30 16:12 Message: Logged In: YES user_id=2217 the patch is missing... ---------------------------------------------------------------------- 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-747 ] \letterspacefont and \pdffontexpand, again
by noreply＠sarovar.org 08 Jul '07

08 Jul '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-07-08 19:17 Message: Logged In: YES user_id=421 The patch had one rejected hunk against stable and current. A working patch is attached; please check. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-07-04 10:13 Message: Logged In: YES user_id=710 patch updated again. Disable \pdfcopyfont for expanded and letterspaced fonts. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-07-03 23:21 Message: Logged In: YES user_id=710 I didn't consider the situation when an expanded font is copied. It seems pretty much of work is needed to get it right, so probably it is easier to disable \pdfcopyfont for expanded (and letterspaced) fonts. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-07-03 19:39 Message: Logged In: YES user_id=2217 Thanks. Letterspacing+expansion works fine now, and \pdfcopyfont is also useful. I gather an expanded font cannot be copied again, right? (Not that I would deem this necessary.) The messages from the following are a bit weird: \tracingonline1 \font\f=cmr10 \pdfcopyfont\fA\f \pdffontexpand\fA 10 10 5 autoexpand \fA ABC \pdfcopyfont\fB\fA \fB ABC \bye ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-30 18:25 Message: Logged In: YES user_id=710 ah, sorry, here it is. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-06-30 18:12 Message: Logged In: YES user_id=2217 the patch is missing... ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-29 17: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 15:32 Message: Logged In: YES user_id=710 patch deleted. Needs more testing. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-29 11: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 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

[ pdftex-Bugs-712 ] problems with \letterspacefont
by noreply＠sarovar.org 08 Jul '07

08 Jul '07

Bugs item #712, was opened at 2006-12-12 03:53 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=712&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: problems with \letterspacefont Initial Comment: % Testing the new \letterspacefont, I found: % % (1) it's certainly not correct to have the spacing % relative to character widths (look at `minimal'!) % (2) everything's shifted to the right % (3) when trying to expand the letter-spaced font, I % get the warning `font should be expanded before % its first use' (even before its first use), and % then pdftex segfaults. \pdfadjustspacing2 \hsize13cm This is normal text This is normal text This is normal text This is normal text This is normal text This is normal text {\letterspacefont\lspfont=\font 1000 %\pdffontexpand\lspfont 20 20 5 autoexpand % segfault \lspfont This isn't normal text This isn't normal text This isn't normal text This is minimal text} This is normal text This is normal text This is normal text \bye ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-07-08 18:20 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-01 22:07 Message: Logged In: YES user_id=710 here is a patch that makes disabling ligature optional -- a keyword "nolig" would do that: \letterspacefont\y=\x 100 nolig ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-02-22 10:31 Message: Logged In: YES user_id=710 yes it sounds reasonable. Or we can extend the syntax of \letterspacefont so that if an optional keyword like 'nolig' is found then ligatures will be disabled. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-02-22 03:54 Message: Logged In: YES user_id=2217 The current situation with regards to the lack of kerning of letterspaced fonts is not really satisfying. After some consideration, I therefore think it is actually better *not* to disable ligatures, and hence kerning, for letterspaced fonts. So I would propose to remove the line: set_no_ligatures(k); {disable ligatures for letter-spaced fonts} It is easy enough for the high-level interfaces (microtype, context) to (automatically) disable selected ligatures only, so that kerning for the rest of the characters is still available. What do you think? \letterspacefont\lsfont\font 100 \lsfont \tagcode\lsfont`f -1 VALID off -- \bye ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-02-02 14:54 Message: Logged In: YES user_id=710 the warning message can be removed. I left it there since I don't know what happens if a virtual font is loaded, used and then expanded and used again with font expansion. It should be alright to do so, but I am not very sure. Anyway, I will change the warning to be issued for non-virtual fonts only. It turned to be a design mistake that the \pdffontexpand primitive takes a base font and turns it to an expanded font. It would be better it was more like \letterspacefont, ie it should create a new font and leave the original font intact. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-02-02 08:30 Message: Logged In: YES user_id=1608 > I hope luatex will abolish with this nonsensical connexion of ligatures and kerns? Yes. ligatures and kerns are totally separate in luatex. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-02-01 20:02 Message: Logged In: YES user_id=2217 If the warning is misleading, should it not be removed? On a different matter: Since \letterspacefont issues set_no_ligatures, there won't be any kerning, either. There's no way around that, I guess? (I hope luatex will abolish with this nonsensical connexion of ligatures and kerns?) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-01-04 16:59 Message: Logged In: YES user_id=710 The warning is misleading but harmless. The reason of the warning is that pdftex checks whether a font has not been used before expansion (its type has not been examined and is new/unknown yet). \letterspacefont sets the type of \y as a virtual font, thus pdftex thinks the font might have been used before. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-01-04 01:40 Message: Logged In: YES user_id=2217 I'm a bit confused about the status of (3): letterspacing and expansion: When expanding a letterspaced font, pdftex issues the warning: ``font should be expanded before its first use'', but apart from that, I cannot see any problems -- the font is both letterspaced and expanded. Or is there a reason for the warning? \pdfadjustspacing2 \font\x=cmr10 \x \letterspacefont\y=\x 100 \y \pdffontexpand\y 20 20 5 autoexpand ... \bye ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-21 17:09 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-12 18:47 Message: Logged In: YES user_id=710 oops, I disabled ligature for letter-spaced font, but this should not affect the base font. Will have to rethink. Most likely the syntax will change like follows: \letterspacefont\f=cmr10 at 11pt 100 \f text ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-12-12 16:50 Message: Logged In: YES user_id=2217 % and here's % (4) ligatures will be broken up, not only in the % letter-spaced font (which is probably acceptable), % but in all subsequent uses of the base font, too fi\par {\letterspacefont\lspfont=\font 100 \lspfont fi}\par fi \bye ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-12 14:31 Message: Logged In: YES user_id=710 I fixed (1) and (2); (3) is disabled now, ie you cannot expand a letter-spaced font. Please wait for another release from Martin. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=712&group_id=106

1 0

[ pdftex-Bugs-712 ] problems with \letterspacefont
by noreply＠sarovar.org 08 Jul '07

08 Jul '07

Bugs item #712, was opened at 2006-12-12 03:53 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=712&group_id=106 Category: hz Group: v1.40.0 >Status: Open >Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: problems with \letterspacefont Initial Comment: % Testing the new \letterspacefont, I found: % % (1) it's certainly not correct to have the spacing % relative to character widths (look at `minimal'!) % (2) everything's shifted to the right % (3) when trying to expand the letter-spaced font, I % get the warning `font should be expanded before % its first use' (even before its first use), and % then pdftex segfaults. \pdfadjustspacing2 \hsize13cm This is normal text This is normal text This is normal text This is normal text This is normal text This is normal text {\letterspacefont\lspfont=\font 1000 %\pdffontexpand\lspfont 20 20 5 autoexpand % segfault \lspfont This isn't normal text This isn't normal text This isn't normal text This is minimal text} This is normal text This is normal text This is normal text \bye ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-01 22:07 Message: Logged In: YES user_id=710 here is a patch that makes disabling ligature optional -- a keyword "nolig" would do that: \letterspacefont\y=\x 100 nolig ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-02-22 10:31 Message: Logged In: YES user_id=710 yes it sounds reasonable. Or we can extend the syntax of \letterspacefont so that if an optional keyword like 'nolig' is found then ligatures will be disabled. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-02-22 03:54 Message: Logged In: YES user_id=2217 The current situation with regards to the lack of kerning of letterspaced fonts is not really satisfying. After some consideration, I therefore think it is actually better *not* to disable ligatures, and hence kerning, for letterspaced fonts. So I would propose to remove the line: set_no_ligatures(k); {disable ligatures for letter-spaced fonts} It is easy enough for the high-level interfaces (microtype, context) to (automatically) disable selected ligatures only, so that kerning for the rest of the characters is still available. What do you think? \letterspacefont\lsfont\font 100 \lsfont \tagcode\lsfont`f -1 VALID off -- \bye ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-02-02 14:54 Message: Logged In: YES user_id=710 the warning message can be removed. I left it there since I don't know what happens if a virtual font is loaded, used and then expanded and used again with font expansion. It should be alright to do so, but I am not very sure. Anyway, I will change the warning to be issued for non-virtual fonts only. It turned to be a design mistake that the \pdffontexpand primitive takes a base font and turns it to an expanded font. It would be better it was more like \letterspacefont, ie it should create a new font and leave the original font intact. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-02-02 08:30 Message: Logged In: YES user_id=1608 > I hope luatex will abolish with this nonsensical connexion of ligatures and kerns? Yes. ligatures and kerns are totally separate in luatex. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-02-01 20:02 Message: Logged In: YES user_id=2217 If the warning is misleading, should it not be removed? On a different matter: Since \letterspacefont issues set_no_ligatures, there won't be any kerning, either. There's no way around that, I guess? (I hope luatex will abolish with this nonsensical connexion of ligatures and kerns?) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-01-04 16:59 Message: Logged In: YES user_id=710 The warning is misleading but harmless. The reason of the warning is that pdftex checks whether a font has not been used before expansion (its type has not been examined and is new/unknown yet). \letterspacefont sets the type of \y as a virtual font, thus pdftex thinks the font might have been used before. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-01-04 01:40 Message: Logged In: YES user_id=2217 I'm a bit confused about the status of (3): letterspacing and expansion: When expanding a letterspaced font, pdftex issues the warning: ``font should be expanded before its first use'', but apart from that, I cannot see any problems -- the font is both letterspaced and expanded. Or is there a reason for the warning? \pdfadjustspacing2 \font\x=cmr10 \x \letterspacefont\y=\x 100 \y \pdffontexpand\y 20 20 5 autoexpand ... \bye ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-21 17:09 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-12 18:47 Message: Logged In: YES user_id=710 oops, I disabled ligature for letter-spaced font, but this should not affect the base font. Will have to rethink. Most likely the syntax will change like follows: \letterspacefont\f=cmr10 at 11pt 100 \f text ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-12-12 16:50 Message: Logged In: YES user_id=2217 % and here's % (4) ligatures will be broken up, not only in the % letter-spaced font (which is probably acceptable), % but in all subsequent uses of the base font, too fi\par {\letterspacefont\lspfont=\font 100 \lspfont fi}\par fi \bye ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-12 14:31 Message: Logged In: YES user_id=710 I fixed (1) and (2); (3) is disabled now, ie you cannot expand a letter-spaced font. Please wait for another release from Martin. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=712&group_id=106

1 0

svn
by Martin Schröder 07 Jul '07

07 Jul '07

Hi, with the help of Fabrice Popineau we now have a public svn repository for pdfTeX. Read all about it at http://foundry.supelec.fr/scm/?group_id=23 Be warned that a full repository checkout explodes to ca. 750MB on your harddisc. All developers who might want to submit to that are requested to sign up with foundry and join the project. Also our cvs at sarovar is not used anymore; all files are also at foundry. The rest of the project (trackers etc.) is still at sarovar. Best Martin

1 0

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

06 Jul '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: Closed >Resolution: Fixed 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: Martin Schröder (oneiros) Date: 2007-07-06 22:45 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-04 12:59 Message: Logged In: YES user_id=1608 Yes, I think that does it. (I resubmitted an earlier reply as well, sorry about that) ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-04 12:55 Message: Logged In: YES user_id=1608 You forgot to actually attach the new, final, patch. ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-07-04 12:27 Message: Logged In: YES user_id=4579 I could have sworn I did attach it. Perhaps I forgot to tick the box? Sorry! It's there now. Thank you so much for all the work you've put into this. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-04 12:22 Message: Logged In: YES user_id=1608 You forgot to actually attach the new, final, patch. ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-07-03 15:33 Message: Logged In: YES user_id=4579 Yes, it's essentially fine (once I apply the patch for 799). A couple of minor things: 1. I forgot to include pdftex.defines in the diff, 2. One of the comments had become inconsistent with the code; so I attach a new (final?) patch. (I have also reinstated an unrelated typo correction -- though perhaps this is already fixed in your tree, which is why you removed it?) ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-02 18:58 Message: Logged In: YES user_id=1608 Robin, I have merged those extra variables and heads with your previous patch. Can you verify that all is still well? ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-07-02 13:59 Message: Logged In: YES user_id=4579 A small additional improvement: dump_int(pdf_last_xform); dump_int(pdf_last_ximage); dump_int(pdf_last_obj); ... undump_int(pdf_last_xform); undump_int(pdf_last_ximage); undump_int(pdf_last_obj); (so that \lastximage and friends will work correctly after loading the format file). ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-07-02 13:33 Message: Logged In: YES user_id=929 > That's odd. The source I'm working from has > @d is_obj_written(#) == (obj_offset(#) <> 0) > Has this been changed recently? this has been changed by the patch to bug 799, where also 'scheduled' has been introduced. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-02 13:21 Message: Logged In: YES user_id=1608 > Has this been changed recently? In my (development version) of the source there is a state 'scheduled', that I assume comes from a fix to something else. In any case, we just have ask Martin to be extra careful about that line while creating 1.40.4 :-) It is probably wise do dump the three heads you mentioned, just in case: I really need the ximage one in my tree, and dumping the others seems a logical extension. Well done to you on finding a way around the regression. ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-07-02 13:08 Message: Logged In: YES user_id=4579 That's odd. The source I'm working from has @d is_obj_written(#) == (obj_offset(#) <> 0) Has this been changed recently? (Am I right in thinking that the development version of the source tree is not publicly available?) With regard to which linked list headers to dump, we seem to be reaching the point of making subtle improvements. The original problem (whatsit nodes in dumped boxes referencing non-existent objects) is solved without dumping any of the headers. One might conceivably want to load images/forms/raw objects in the .ini, and then reference them from the .tex: this is addressed by dumping head_tab[obj_type_ximage], head_tab[obj_type_xform] and head_tab[obj_type_obj]. (Neither forms nor raw objects have any additional associated metadata, as far as I can tell.) I can't see any benefit from dumping the other entries, whether or not doing so would cause potential crashes. At any rate, what we have now seems a definite improvement over the status quo, and avoids the undesirable feature-regression of forbidding \dump after \shipout. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-02 12:53 Message: Logged In: YES user_id=1608 WRT type image object: over here, it is only included twice after I do a small fix to your patch: obj_tab[k].int2 := -1; this could just be a simple difference between my and your pdftex source trees, but please re-check. I definately have *no* runtime image with obj_tab[k].int2 := 0, and that is correct/expected, because I can see in the source that the is_obj_written() test checks for >-1. The thing with head_tab[obj_type_xform] is why I initially dumped all of them. The xforms should be safe, but fonts are definately not ok (not unless whole lot more stuff is dumped to the format). I don't know about the others heads. It depends on whether or not the objects need additional data structures besides obj_tab and pdf_mem, and I am not very much at home in that section of the pdftex code. ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-07-02 10:58 Message: Logged In: YES user_id=4579 Taco, do you have an example of the "another problem" that you mention? I thought I had dealt with that, by not dumping obj_tab[k].int2 and resetting it to 0, and indeed it seems to work when I try it. To be precise about what I tried, I added the lines % \pdfrefximage\pdflastximage \par\vfil\penalty-10000 % before the \dump command in test-fmt2.tex. Both the generated PDFs (test-fmt2.pdf and test2.pdf) seem okay. Incidentally, it's easy to make a test, along the lines of test2, that requires head_tab[obj_type_xform]. So I guess that should be dumped too. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-02 10:34 Message: Logged In: YES user_id=1608 The objects (and their numbers) are saved in the formats as well ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-07-02 10:30 Message: Logged In: YES user_id=929 how can test2 work anyway? the pdfximage reserves an absolute object number (not something like an image number), and \pdflastximage gives this object number. But later in the real document objects are numbered in the natural way in ascending order, so how can an image object number fixed already in the format fit into this sequence? Regards, Hartmut ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-02 09:11 Message: Logged In: YES user_id=1608 I got an example from Hartmut Henkel that needs head_tab[pdf_obj_ximage], it is test2 in attached tar. I tried a quick test and it indeed seems to work ok if I dump *only* that head_tab entry. But, you have to solve another problem as well. If you use the image in the initex-dumped pdf, then the image wil not be included in the runtime pdf (its state is 'written'). Somehow this state needs to be reset. Taco ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-02 09:10 Message: Logged In: YES user_id=1608 I got an example from Hartmut Henkel that needs head_tab[pdf_obj_ximage], it is test2 in attached tar. I tried a quick test and it indeed seems to work ok if I dump *only* that head_tab entry. But, you have to solve another problem as well. If you use the image in the initex-dumped pdf, then the image wil not be included in the runtime pdf (its state is 'written'). Somehow this state needs to be reset. Taco ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-30 18:56 Message: Logged In: YES user_id=4579 The attached patch (initex-objects.patch) implements the suggestions made below, together with a few other improvements. It incorporates Taco Hoekwater's code, so should be applied to a clean source tree. In particular, it reinstates the ability to produce both a PDF document and a memory dump in the same run. I've tested it with \pdfxform as well as \pdfximage. Comments? Counterexamples? Robin ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-30 14:38 Message: Logged In: YES user_id=4579 Fortunately the "two picture" problem (demonstrated in the attachment twopic.tar.gz) is trivial to solve: simply dump and undump the variable pdf_ximage_count. Presumably the same should be done for pdf_obj_count and pdf_xform_count. Whether this is sufficient, I have no idea: none of us have tested forms or raw objects, have we? ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-30 12:08 Message: Logged In: YES user_id=4579 A minor bug in the initex-refximage-dump.patch: the test for fixed_pdfoutput=1 ought to be fixed_pdfoutput>0, otherwise it will fail with \pdfoutput=2, say. Another unrelated problem is that, if you load an image from the .ini file, and then load and display another image from the .tex file, the first image will appear where the second one ought to be. I'll try and find out why this is happening. (Incidentally, I haven't (yet?) discovered any problems stemming from not (un)dumping the linked list headers.) ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-29 20:08 Message: Logged In: YES user_id=4579 Argh! Interesting, thanks. Clearly my understanding of the pdftex code is patchy at best. That said, what is gained by dumping and restoring the head_tab? If I remove the parts of your code that dump and undump the head_tab, then your example works (and mine continue to work). Robin ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-29 18:32 Message: Logged In: YES user_id=1608 Try a document that contains items besides a single image. Many of the auxiliary tables are not dumped, resulting in assertion failures in the non-ini run. You don't even need to save or reuse boxes for those crashes, just make a pair of: % test.ini \input plain \pdfoutput=1 hello \dump % test.tex world! \end ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-29 17: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 17: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 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-Patches-726 ] in writezip.c replace deflateEnd() - deflateInit() by deflateReset()
by noreply＠sarovar.org 06 Jul '07

06 Jul '07

Patches item #726, was opened at 2007-01-28 14:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=726&group_id=106 Category: Memory allocation Group: v1.50.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Martin Schröder (oneiros) Summary: in writezip.c replace deflateEnd() - deflateInit() by deflateReset() Initial Comment: This patch removes unnecessary free()/alloc() calls of zlib internal structures, reduces sys time. As before, \pdfcompresslevel change is still possible in mid document. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-07-06 22:25 Message: Logged In: YES user_id=421 This patch will be included in the upcoming 1.50 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=726&group_id=106

1 0

[ pdftex-Bugs-810 ] Mixed up font descriptor from pdf inclusion
by noreply＠sarovar.org 06 Jul '07

06 Jul '07

Bugs item #810, was opened at 2007-06-22 13:49 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=810&group_id=106 Category: Fonts Group: v1.40.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: The Thanh Han (hanthethanh) Summary: Mixed up font descriptor from pdf inclusion Initial Comment: Ulrich Dirr reported a bug with pdf inclusion where font information is not copied correctly (see http://tug.org/pipermail/pdftex/2007-June/007197.html) Thanh analysed thus: the issue with "Strange problems with graphics inclusion" has the following reason : - CMSS10 is used in a pdf figure (let's call it f1.pdf) - that f1.pdf is included in another pdf (eg f2.pdf) - when f2.pdf includes f1.pdf and a map entry for CMSS10 is avail., a font descriptor for CMSS10 is created by epdf_create_fontdescriptor() - the preset_fontmetrics() function is not called for CMSS10 (it's there in epdf_create_fontdescriptor(), but commented out -- no f to use with preset_fontmetrics() there) - when pdftex writes out the font descriptor for CMSS10, some font metrics are not set, since CMSS10.pfb doesn't have them - so f2.pdf ends up with a font descriptor for CMSS10 where some font metrics are missing (Ascent, CapHeight, XHeight etc.) - f2.pdf seems to be ok with most pdf browser, but not with Preflight in Acrobat7 (and perhaps with PitStop -- I don't have PitStop to test) A patch by Thanh is attached. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-07-06 20:39 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=810&group_id=106

1 0

[ pdftex-Bugs-772 ] Option -recorder does not work for Type1 or PK files
by noreply＠sarovar.org 06 Jul '07

06 Jul '07

Bugs item #772, was opened at 2007-04-13 04:54 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=772&group_id=106 Category: web2c Group: v1.40.0 >Status: Closed Resolution: Fixed Priority: 4 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Martin Schröder (oneiros) Summary: Option -recorder does not work for Type1 or PK files Initial Comment: Hello, pdfTeX 1.40.3 supports the Web2C feature, enabled by option -recorder. However, it does not record all files, .pfb (Type1) or .pk files are missing. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> PS: texmf.cnf isn't recorded either. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-07-06 20:20 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-07-04 21:38 Message: Logged In: YES user_id=421 Next try at a patch; this does \pdffilemoddate and \pdffilesize and also catches texmf.cnf ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2007-07-04 14:06 Message: Logged In: YES user_id=1276 Hello, \pdffilemoddate and \pdffilesize are still missing. But a fix seems easy, just adding a call of recorder_record_input in util.c's functions getfilemoddate and getfilesize should help. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-25 12:41 Message: Logged In: YES user_id=421 A much simpler patch is attached; it also catches the new pipe feature. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-25 01:33 Message: Logged In: YES user_id=421 Attached is a patch that should fix this. Please test. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2007-04-17 13:19 Message: Logged In: YES user_id=1276 Hello, to prevent that it gets lost, a followup of mine in ntg-pdftex mailing list: After further testing (sorry) I found other gaps in file name recording: \pdfximage{<file>} \pdffilesize{<file>} \pdffilemoddate{<file>} \pdffiledump{<file>} \pdfmdfivesum file{<file>} Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=772&group_id=106

1 0

[ pdftex-Bugs-772 ] Option -recorder does not work for Type1 or PK files
by noreply＠sarovar.org 06 Jul '07

06 Jul '07

Bugs item #772, was opened at 2007-04-13 04:54 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=772&group_id=106 Category: web2c Group: v1.40.0 Status: Open >Resolution: Fixed Priority: 4 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Martin Schröder (oneiros) Summary: Option -recorder does not work for Type1 or PK files Initial Comment: Hello, pdfTeX 1.40.3 supports the Web2C feature, enabled by option -recorder. However, it does not record all files, .pfb (Type1) or .pk files are missing. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> PS: texmf.cnf isn't recorded either. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-07-06 20:20 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-07-04 21:38 Message: Logged In: YES user_id=421 Next try at a patch; this does \pdffilemoddate and \pdffilesize and also catches texmf.cnf ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2007-07-04 14:06 Message: Logged In: YES user_id=1276 Hello, \pdffilemoddate and \pdffilesize are still missing. But a fix seems easy, just adding a call of recorder_record_input in util.c's functions getfilemoddate and getfilesize should help. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-25 12:41 Message: Logged In: YES user_id=421 A much simpler patch is attached; it also catches the new pipe feature. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-25 01:33 Message: Logged In: YES user_id=421 Attached is a patch that should fix this. Please test. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2007-04-17 13:19 Message: Logged In: YES user_id=1276 Hello, to prevent that it gets lost, a followup of mine in ntg-pdftex mailing list: After further testing (sorry) I found other gaps in file name recording: \pdfximage{<file>} \pdffilesize{<file>} \pdffilemoddate{<file>} \pdffiledump{<file>} \pdfmdfivesum file{<file>} Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=772&group_id=106

1 0

[ pdftex-Bugs-772 ] Option -recorder does not work for Type1 or PK files
by noreply＠sarovar.org 04 Jul '07

04 Jul '07

Bugs item #772, was opened at 2007-04-13 04:54 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=772&group_id=106 Category: web2c Group: v1.40.0 Status: Open Resolution: Accepted Priority: 4 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Martin Schröder (oneiros) Summary: Option -recorder does not work for Type1 or PK files Initial Comment: Hello, pdfTeX 1.40.3 supports the Web2C feature, enabled by option -recorder. However, it does not record all files, .pfb (Type1) or .pk files are missing. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> PS: texmf.cnf isn't recorded either. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-07-04 21:38 Message: Logged In: YES user_id=421 Next try at a patch; this does \pdffilemoddate and \pdffilesize and also catches texmf.cnf ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2007-07-04 14:06 Message: Logged In: YES user_id=1276 Hello, \pdffilemoddate and \pdffilesize are still missing. But a fix seems easy, just adding a call of recorder_record_input in util.c's functions getfilemoddate and getfilesize should help. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-25 12:41 Message: Logged In: YES user_id=421 A much simpler patch is attached; it also catches the new pipe feature. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-25 01:33 Message: Logged In: YES user_id=421 Attached is a patch that should fix this. Please test. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2007-04-17 13:19 Message: Logged In: YES user_id=1276 Hello, to prevent that it gets lost, a followup of mine in ntg-pdftex mailing list: After further testing (sorry) I found other gaps in file name recording: \pdfximage{<file>} \pdffilesize{<file>} \pdffilemoddate{<file>} \pdffiledump{<file>} \pdfmdfivesum file{<file>} Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=772&group_id=106

1 0

[ pdftex-Bugs-772 ] Option -recorder does not work for Type1 or PK files
by noreply＠sarovar.org 04 Jul '07

04 Jul '07

Bugs item #772, was opened at 2007-04-13 04:54 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=772&group_id=106 Category: web2c Group: v1.40.0 Status: Open Resolution: Accepted Priority: 4 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Martin Schröder (oneiros) Summary: Option -recorder does not work for Type1 or PK files Initial Comment: Hello, pdfTeX 1.40.3 supports the Web2C feature, enabled by option -recorder. However, it does not record all files, .pfb (Type1) or .pk files are missing. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> PS: texmf.cnf isn't recorded either. ---------------------------------------------------------------------- >Comment By: Heiko Oberdiek (oberdiek) Date: 2007-07-04 14:06 Message: Logged In: YES user_id=1276 Hello, \pdffilemoddate and \pdffilesize are still missing. But a fix seems easy, just adding a call of recorder_record_input in util.c's functions getfilemoddate and getfilesize should help. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-25 12:41 Message: Logged In: YES user_id=421 A much simpler patch is attached; it also catches the new pipe feature. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-25 01:33 Message: Logged In: YES user_id=421 Attached is a patch that should fix this. Please test. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2007-04-17 13:19 Message: Logged In: YES user_id=1276 Hello, to prevent that it gets lost, a followup of mine in ntg-pdftex mailing list: After further testing (sorry) I found other gaps in file name recording: \pdfximage{<file>} \pdffilesize{<file>} \pdffilemoddate{<file>} \pdffiledump{<file>} \pdfmdfivesum file{<file>} Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=772&group_id=106

1 0

[ pdftex-Bugs-829 ] TEX_HUSH not handled correctly
by noreply＠sarovar.org 04 Jul '07

04 Jul '07

Bugs item #829, was opened at 2007-07-04 12:49 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=829&group_id=106 Category: web2c Group: v1.40.3 Status: Open Resolution: None Priority: 1 Submitted By: Martin Schröder (oneiros) Assigned to: Martin Schröder (oneiros) Summary: TEX_HUSH not handled correctly Initial Comment: This is from kpathsea.info: --------------------------- 4.4 Suppressing warnings ======================== Kpathsea provides a way to suppress selected usually-harmless warnings; this is useful at large sites where most users are not administrators, and thus the warnings are merely a source of confusion, not a help. To do this, you set the environment variable or configuration file value `TEX_HUSH' to a colon-separated list of values. Here are the possibilities: `all' Suppress everything possible. `checksum' Suppress mismatched font checksum warnings. `lostchar' Suppress warnings when a character is missing from a font that a DVI or VF file tries to typeset. `none' Don't suppress any warnings. `readable' Suppress warnings about attempts to access a file whose permissions render it unreadable. `special' Suppresses warnings about an unimplemented or unparsable `\special' command. `tex-hush.c' defines the function that checks the variable value. Each driver implements its own checks where appropriate. --------------------------- This is currently not handled by pdftex. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-07-04 13:01 Message: Logged In: YES user_id=421 Not Knuth's warnings. But pdfTeX in PDF mode is also a driver... The only one that IMHO matters is "special". OTOH nobody has complained about this yet... ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-04 12:56 Message: Logged In: YES user_id=1608 This only affects the backend driver, right? But not Knuth's warnings in the web source. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=829&group_id=106

1 0

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

04 Jul '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-07-04 12:59 Message: Logged In: YES user_id=1608 Yes, I think that does it. (I resubmitted an earlier reply as well, sorry about that) ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-04 12:55 Message: Logged In: YES user_id=1608 You forgot to actually attach the new, final, patch. ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-07-04 12:27 Message: Logged In: YES user_id=4579 I could have sworn I did attach it. Perhaps I forgot to tick the box? Sorry! It's there now. Thank you so much for all the work you've put into this. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-04 12:22 Message: Logged In: YES user_id=1608 You forgot to actually attach the new, final, patch. ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-07-03 15:33 Message: Logged In: YES user_id=4579 Yes, it's essentially fine (once I apply the patch for 799). A couple of minor things: 1. I forgot to include pdftex.defines in the diff, 2. One of the comments had become inconsistent with the code; so I attach a new (final?) patch. (I have also reinstated an unrelated typo correction -- though perhaps this is already fixed in your tree, which is why you removed it?) ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-02 18:58 Message: Logged In: YES user_id=1608 Robin, I have merged those extra variables and heads with your previous patch. Can you verify that all is still well? ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-07-02 13:59 Message: Logged In: YES user_id=4579 A small additional improvement: dump_int(pdf_last_xform); dump_int(pdf_last_ximage); dump_int(pdf_last_obj); ... undump_int(pdf_last_xform); undump_int(pdf_last_ximage); undump_int(pdf_last_obj); (so that \lastximage and friends will work correctly after loading the format file). ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-07-02 13:33 Message: Logged In: YES user_id=929 > That's odd. The source I'm working from has > @d is_obj_written(#) == (obj_offset(#) <> 0) > Has this been changed recently? this has been changed by the patch to bug 799, where also 'scheduled' has been introduced. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-02 13:21 Message: Logged In: YES user_id=1608 > Has this been changed recently? In my (development version) of the source there is a state 'scheduled', that I assume comes from a fix to something else. In any case, we just have ask Martin to be extra careful about that line while creating 1.40.4 :-) It is probably wise do dump the three heads you mentioned, just in case: I really need the ximage one in my tree, and dumping the others seems a logical extension. Well done to you on finding a way around the regression. ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-07-02 13:08 Message: Logged In: YES user_id=4579 That's odd. The source I'm working from has @d is_obj_written(#) == (obj_offset(#) <> 0) Has this been changed recently? (Am I right in thinking that the development version of the source tree is not publicly available?) With regard to which linked list headers to dump, we seem to be reaching the point of making subtle improvements. The original problem (whatsit nodes in dumped boxes referencing non-existent objects) is solved without dumping any of the headers. One might conceivably want to load images/forms/raw objects in the .ini, and then reference them from the .tex: this is addressed by dumping head_tab[obj_type_ximage], head_tab[obj_type_xform] and head_tab[obj_type_obj]. (Neither forms nor raw objects have any additional associated metadata, as far as I can tell.) I can't see any benefit from dumping the other entries, whether or not doing so would cause potential crashes. At any rate, what we have now seems a definite improvement over the status quo, and avoids the undesirable feature-regression of forbidding \dump after \shipout. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-02 12:53 Message: Logged In: YES user_id=1608 WRT type image object: over here, it is only included twice after I do a small fix to your patch: obj_tab[k].int2 := -1; this could just be a simple difference between my and your pdftex source trees, but please re-check. I definately have *no* runtime image with obj_tab[k].int2 := 0, and that is correct/expected, because I can see in the source that the is_obj_written() test checks for >-1. The thing with head_tab[obj_type_xform] is why I initially dumped all of them. The xforms should be safe, but fonts are definately not ok (not unless whole lot more stuff is dumped to the format). I don't know about the others heads. It depends on whether or not the objects need additional data structures besides obj_tab and pdf_mem, and I am not very much at home in that section of the pdftex code. ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-07-02 10:58 Message: Logged In: YES user_id=4579 Taco, do you have an example of the "another problem" that you mention? I thought I had dealt with that, by not dumping obj_tab[k].int2 and resetting it to 0, and indeed it seems to work when I try it. To be precise about what I tried, I added the lines % \pdfrefximage\pdflastximage \par\vfil\penalty-10000 % before the \dump command in test-fmt2.tex. Both the generated PDFs (test-fmt2.pdf and test2.pdf) seem okay. Incidentally, it's easy to make a test, along the lines of test2, that requires head_tab[obj_type_xform]. So I guess that should be dumped too. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-02 10:34 Message: Logged In: YES user_id=1608 The objects (and their numbers) are saved in the formats as well ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-07-02 10:30 Message: Logged In: YES user_id=929 how can test2 work anyway? the pdfximage reserves an absolute object number (not something like an image number), and \pdflastximage gives this object number. But later in the real document objects are numbered in the natural way in ascending order, so how can an image object number fixed already in the format fit into this sequence? Regards, Hartmut ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-02 09:11 Message: Logged In: YES user_id=1608 I got an example from Hartmut Henkel that needs head_tab[pdf_obj_ximage], it is test2 in attached tar. I tried a quick test and it indeed seems to work ok if I dump *only* that head_tab entry. But, you have to solve another problem as well. If you use the image in the initex-dumped pdf, then the image wil not be included in the runtime pdf (its state is 'written'). Somehow this state needs to be reset. Taco ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-02 09:10 Message: Logged In: YES user_id=1608 I got an example from Hartmut Henkel that needs head_tab[pdf_obj_ximage], it is test2 in attached tar. I tried a quick test and it indeed seems to work ok if I dump *only* that head_tab entry. But, you have to solve another problem as well. If you use the image in the initex-dumped pdf, then the image wil not be included in the runtime pdf (its state is 'written'). Somehow this state needs to be reset. Taco ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-30 18:56 Message: Logged In: YES user_id=4579 The attached patch (initex-objects.patch) implements the suggestions made below, together with a few other improvements. It incorporates Taco Hoekwater's code, so should be applied to a clean source tree. In particular, it reinstates the ability to produce both a PDF document and a memory dump in the same run. I've tested it with \pdfxform as well as \pdfximage. Comments? Counterexamples? Robin ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-30 14:38 Message: Logged In: YES user_id=4579 Fortunately the "two picture" problem (demonstrated in the attachment twopic.tar.gz) is trivial to solve: simply dump and undump the variable pdf_ximage_count. Presumably the same should be done for pdf_obj_count and pdf_xform_count. Whether this is sufficient, I have no idea: none of us have tested forms or raw objects, have we? ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-30 12:08 Message: Logged In: YES user_id=4579 A minor bug in the initex-refximage-dump.patch: the test for fixed_pdfoutput=1 ought to be fixed_pdfoutput>0, otherwise it will fail with \pdfoutput=2, say. Another unrelated problem is that, if you load an image from the .ini file, and then load and display another image from the .tex file, the first image will appear where the second one ought to be. I'll try and find out why this is happening. (Incidentally, I haven't (yet?) discovered any problems stemming from not (un)dumping the linked list headers.) ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-29 20:08 Message: Logged In: YES user_id=4579 Argh! Interesting, thanks. Clearly my understanding of the pdftex code is patchy at best. That said, what is gained by dumping and restoring the head_tab? If I remove the parts of your code that dump and undump the head_tab, then your example works (and mine continue to work). Robin ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-29 18:32 Message: Logged In: YES user_id=1608 Try a document that contains items besides a single image. Many of the auxiliary tables are not dumped, resulting in assertion failures in the non-ini run. You don't even need to save or reuse boxes for those crashes, just make a pair of: % test.ini \input plain \pdfoutput=1 hello \dump % test.tex world! \end ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-29 17: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 17: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 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-829 ] TEX_HUSH not handled correctly
by noreply＠sarovar.org 04 Jul '07

04 Jul '07

Bugs item #829, was opened at 2007-07-04 12:49 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=829&group_id=106 Category: web2c Group: v1.40.3 Status: Open Resolution: None Priority: 1 Submitted By: Martin Schröder (oneiros) Assigned to: Martin Schröder (oneiros) Summary: TEX_HUSH not handled correctly Initial Comment: This is from kpathsea.info: --------------------------- 4.4 Suppressing warnings ======================== Kpathsea provides a way to suppress selected usually-harmless warnings; this is useful at large sites where most users are not administrators, and thus the warnings are merely a source of confusion, not a help. To do this, you set the environment variable or configuration file value `TEX_HUSH' to a colon-separated list of values. Here are the possibilities: `all' Suppress everything possible. `checksum' Suppress mismatched font checksum warnings. `lostchar' Suppress warnings when a character is missing from a font that a DVI or VF file tries to typeset. `none' Don't suppress any warnings. `readable' Suppress warnings about attempts to access a file whose permissions render it unreadable. `special' Suppresses warnings about an unimplemented or unparsable `\special' command. `tex-hush.c' defines the function that checks the variable value. Each driver implements its own checks where appropriate. --------------------------- This is currently not handled by pdftex. ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2007-07-04 12:56 Message: Logged In: YES user_id=1608 This only affects the backend driver, right? But not Knuth's warnings in the web source. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=829&group_id=106

1 0

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

04 Jul '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-07-04 12:55 Message: Logged In: YES user_id=1608 You forgot to actually attach the new, final, patch. ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-07-04 12:27 Message: Logged In: YES user_id=4579 I could have sworn I did attach it. Perhaps I forgot to tick the box? Sorry! It's there now. Thank you so much for all the work you've put into this. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-04 12:22 Message: Logged In: YES user_id=1608 You forgot to actually attach the new, final, patch. ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-07-03 15:33 Message: Logged In: YES user_id=4579 Yes, it's essentially fine (once I apply the patch for 799). A couple of minor things: 1. I forgot to include pdftex.defines in the diff, 2. One of the comments had become inconsistent with the code; so I attach a new (final?) patch. (I have also reinstated an unrelated typo correction -- though perhaps this is already fixed in your tree, which is why you removed it?) ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-02 18:58 Message: Logged In: YES user_id=1608 Robin, I have merged those extra variables and heads with your previous patch. Can you verify that all is still well? ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-07-02 13:59 Message: Logged In: YES user_id=4579 A small additional improvement: dump_int(pdf_last_xform); dump_int(pdf_last_ximage); dump_int(pdf_last_obj); ... undump_int(pdf_last_xform); undump_int(pdf_last_ximage); undump_int(pdf_last_obj); (so that \lastximage and friends will work correctly after loading the format file). ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-07-02 13:33 Message: Logged In: YES user_id=929 > That's odd. The source I'm working from has > @d is_obj_written(#) == (obj_offset(#) <> 0) > Has this been changed recently? this has been changed by the patch to bug 799, where also 'scheduled' has been introduced. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-02 13:21 Message: Logged In: YES user_id=1608 > Has this been changed recently? In my (development version) of the source there is a state 'scheduled', that I assume comes from a fix to something else. In any case, we just have ask Martin to be extra careful about that line while creating 1.40.4 :-) It is probably wise do dump the three heads you mentioned, just in case: I really need the ximage one in my tree, and dumping the others seems a logical extension. Well done to you on finding a way around the regression. ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-07-02 13:08 Message: Logged In: YES user_id=4579 That's odd. The source I'm working from has @d is_obj_written(#) == (obj_offset(#) <> 0) Has this been changed recently? (Am I right in thinking that the development version of the source tree is not publicly available?) With regard to which linked list headers to dump, we seem to be reaching the point of making subtle improvements. The original problem (whatsit nodes in dumped boxes referencing non-existent objects) is solved without dumping any of the headers. One might conceivably want to load images/forms/raw objects in the .ini, and then reference them from the .tex: this is addressed by dumping head_tab[obj_type_ximage], head_tab[obj_type_xform] and head_tab[obj_type_obj]. (Neither forms nor raw objects have any additional associated metadata, as far as I can tell.) I can't see any benefit from dumping the other entries, whether or not doing so would cause potential crashes. At any rate, what we have now seems a definite improvement over the status quo, and avoids the undesirable feature-regression of forbidding \dump after \shipout. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-02 12:53 Message: Logged In: YES user_id=1608 WRT type image object: over here, it is only included twice after I do a small fix to your patch: obj_tab[k].int2 := -1; this could just be a simple difference between my and your pdftex source trees, but please re-check. I definately have *no* runtime image with obj_tab[k].int2 := 0, and that is correct/expected, because I can see in the source that the is_obj_written() test checks for >-1. The thing with head_tab[obj_type_xform] is why I initially dumped all of them. The xforms should be safe, but fonts are definately not ok (not unless whole lot more stuff is dumped to the format). I don't know about the others heads. It depends on whether or not the objects need additional data structures besides obj_tab and pdf_mem, and I am not very much at home in that section of the pdftex code. ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-07-02 10:58 Message: Logged In: YES user_id=4579 Taco, do you have an example of the "another problem" that you mention? I thought I had dealt with that, by not dumping obj_tab[k].int2 and resetting it to 0, and indeed it seems to work when I try it. To be precise about what I tried, I added the lines % \pdfrefximage\pdflastximage \par\vfil\penalty-10000 % before the \dump command in test-fmt2.tex. Both the generated PDFs (test-fmt2.pdf and test2.pdf) seem okay. Incidentally, it's easy to make a test, along the lines of test2, that requires head_tab[obj_type_xform]. So I guess that should be dumped too. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-02 10:34 Message: Logged In: YES user_id=1608 The objects (and their numbers) are saved in the formats as well ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2007-07-02 10:30 Message: Logged In: YES user_id=929 how can test2 work anyway? the pdfximage reserves an absolute object number (not something like an image number), and \pdflastximage gives this object number. But later in the real document objects are numbered in the natural way in ascending order, so how can an image object number fixed already in the format fit into this sequence? Regards, Hartmut ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-02 09:11 Message: Logged In: YES user_id=1608 I got an example from Hartmut Henkel that needs head_tab[pdf_obj_ximage], it is test2 in attached tar. I tried a quick test and it indeed seems to work ok if I dump *only* that head_tab entry. But, you have to solve another problem as well. If you use the image in the initex-dumped pdf, then the image wil not be included in the runtime pdf (its state is 'written'). Somehow this state needs to be reset. Taco ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-07-02 09:10 Message: Logged In: YES user_id=1608 I got an example from Hartmut Henkel that needs head_tab[pdf_obj_ximage], it is test2 in attached tar. I tried a quick test and it indeed seems to work ok if I dump *only* that head_tab entry. But, you have to solve another problem as well. If you use the image in the initex-dumped pdf, then the image wil not be included in the runtime pdf (its state is 'written'). Somehow this state needs to be reset. Taco ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-30 18:56 Message: Logged In: YES user_id=4579 The attached patch (initex-objects.patch) implements the suggestions made below, together with a few other improvements. It incorporates Taco Hoekwater's code, so should be applied to a clean source tree. In particular, it reinstates the ability to produce both a PDF document and a memory dump in the same run. I've tested it with \pdfxform as well as \pdfximage. Comments? Counterexamples? Robin ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-30 14:38 Message: Logged In: YES user_id=4579 Fortunately the "two picture" problem (demonstrated in the attachment twopic.tar.gz) is trivial to solve: simply dump and undump the variable pdf_ximage_count. Presumably the same should be done for pdf_obj_count and pdf_xform_count. Whether this is sufficient, I have no idea: none of us have tested forms or raw objects, have we? ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-30 12:08 Message: Logged In: YES user_id=4579 A minor bug in the initex-refximage-dump.patch: the test for fixed_pdfoutput=1 ought to be fixed_pdfoutput>0, otherwise it will fail with \pdfoutput=2, say. Another unrelated problem is that, if you load an image from the .ini file, and then load and display another image from the .tex file, the first image will appear where the second one ought to be. I'll try and find out why this is happening. (Incidentally, I haven't (yet?) discovered any problems stemming from not (un)dumping the linked list headers.) ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-29 20:08 Message: Logged In: YES user_id=4579 Argh! Interesting, thanks. Clearly my understanding of the pdftex code is patchy at best. That said, what is gained by dumping and restoring the head_tab? If I remove the parts of your code that dump and undump the head_tab, then your example works (and mine continue to work). Robin ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-29 18:32 Message: Logged In: YES user_id=1608 Try a document that contains items besides a single image. Many of the auxiliary tables are not dumped, resulting in assertion failures in the non-ini run. You don't even need to save or reuse boxes for those crashes, just make a pair of: % test.ini \input plain \pdfoutput=1 hello \dump % test.tex world! \end ---------------------------------------------------------------------- Comment By: Robin Houston (robinhouston) Date: 2007-06-29 17: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 17: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 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