October 2005 - ntg-pdftex - NTG Mailing Lists

Interesting Paper
by Hartmut Henkel 21 Oct '05

21 Oct '05

just found "Two Diet Plans for Fat PDF" by Thomas A. Phelps and Robert Wilensky, University of California, Berkeley. http://multivalent.sourceforge.net/Research/TwoDietPlans.pdf Regards, Hartmut

1 0

[ pdftex-Bugs-437 ] Two \immediate cancel themselves
by noreply＠sarovar.org 17 Oct '05

17 Oct '05

Bugs item #437, was opened at 2005-10-15 23:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=437&group_id=106 Category: None Group: v1.30.0 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Hartmut Henkel (hhenkel) Summary: Two \immediate cancel themselves Initial Comment: Hello, Vladimir Volovich found the following bug, I quote his bug report from the ntg-pdftex list here: > consider the following Plain TeX file: > > \immediate\immediate\openout1=test.out > \immediate\write1 {line 1} > \immediate\write1 {line 2} > \immediate\closeout1 > > \bye > > (it was reduced from a real-life example). > > if i process it with vanilla TeX engine (i.e. not > with pdfetex, but with TeX), you get what i expect: > two lines are written to the file test.out, and > there are no pages of output (no DVI file generated). > > however, if i process this file with pdfetex, i do > not get what i would expect: instead, the lines are > written to terminal, test.out is created and is > empty, and there is also a 1-page PDF file generated. > > the bug goes away if i remove the second \immediate, > but as i said this is a simplified example converted > from a real-life usage. It is indeed a bug: this is the original code of "Implement \immediate": | begin get_x_token; | if (cur_cmd=extension)and(cur_chr<=close_node) then | begin p:=tail; do_extension;{append a whatsit node} | out_what(tail); {do the action immediately} | flush_node_list(tail); tail:=p; link(p):=null; | end | else back_input; | end A token is read. If the token hears to \immediate, it is executed with the immediate setting. Otherwise the token is just put back. Now pdfTeX has more commands that obey \immediate: | begin get_x_token; | if cur_cmd=extension then begin | if cur_chr<=close_node then | begin <<original action>> end | else case cur_chr of | pdf_obj_code: begin <<...>> end; | pdf_xform_code: begin <<...>> end; | pdf_ximage_code: begin <<...>> end; | end; | endcases; | end | else | back_input; | end Cases: a) cur_cmd != extension --> nothing is changed (back_input) b) cur_cmd == extension && cur_chr <= close_node --> nothing is changed (original action) c) cur_cmd == extension && cur_chr in (pdf_{obj,xform,ximage}_code) --> new behaviour for pdfTeX d) cur_cmd == extension && cur_chr > close_node && cur_chr not in (pdf_{obj,xform,ximage}_code) --> no action Case d) is the bug. \immediate is an extension primitive with cur_chr > close_node. Thus the second \immediate is read, but then dropped. The effect is: \immediate\immediate\openout is same as \openout Instead of "no action" there should be "back_input". Before "endcases" the following line needs to be added: ... else case cur_chr of ... othercases back_input endcases; I have attachted a diff file for pdftexdir/pdftex.ch. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-10-17 19:27 Message: Logged In: YES user_id=421 This has been fixed in 1.30.4 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=437&group_id=106

1 0

[ pdftex-Bugs-435 ] Wrong file name in error messages of image inclusion (readimage)
by noreply＠sarovar.org 17 Oct '05

17 Oct '05

Bugs item #435, was opened at 2005-10-15 01:21 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=435&group_id=106 Category: Image inclusion Group: v1.30.0 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Martin Schröder (oneiros) Summary: Wrong file name in error messages of image inclusion (readimage) Initial Comment: Hello, see the thread "Wrong search path for PDF/PNG/JPG files" (2005/10/14) in the pdftex mailing list. Wlodek Bzyl detected a bug regarding image inclusion: pdfTeX sometimes prints a wrong file name in image error messages: The current directory contains: pic.jpg (JPG image), pic.jpg.tex (e.g. consisting of "\relax") and test.tex: \pdfximage{pic.jpg} \pdfrefximage\pdflastximage \bye Then kpse_find_file will find "pic.jpg.tex" (the automatically adding of ".tex" is sometimes very annoying) and prints the error message: Error: pdftex (file ./pic.jpg): reading image file failed Or if the file pic.jpg.tex is longer: Error: pdftex (file ./pic.jpg): unknown type of image In both cases the file name in the error message is wrong. The error message is thrown by pdftex_fail that looks for cur_file_name and prints it (utils.c). However the real image file name can be changed by kpse_find_file (e.g. adding ".tex"): img_name(img) = kpse_find_file(cur_file_name, kpse_tex_format, true); if (img_name(img) == NULL) pdftex_fail("cannot find image file"); // Here the file name is still correct // (img_name(img) is NULL) // But after this, img_name(img) is not NULL and // contains the used file name, cur_file_name is no // longer valid. checktypebyheader(img); checktypebyextension(img); ... default: pdftex_fail("unknown type of image"); } ... cur_file_name = NULL; ... // checktypebyheader calls pdftex_fail, // and pdftex_fail is also used // later, in each case using the wrong cur_file_name. Fix is easy: cur_file_name = img_name(img); after the NULL check part before checktypebyheader. There are no memory problems. Before cur_file_name points to a static buffer, the return value of makecstring. Thus free must not be used on cur_file_name. And the memory part of img_name(img) is not changed. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-10-17 19:27 Message: Logged In: YES user_id=421 This has been fixed in 1.30.4 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=435&group_id=106

1 0

[ pdftex-Patches-438 ] \pdfsavepos in DVI mode
by noreply＠sarovar.org 17 Oct '05

17 Oct '05

Patches item #438, was opened at 2005-10-16 23:52 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=438&group_id=106 Category: Positioning Group: None Status: Open Resolution: None Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: \pdfsavepos in DVI mode Initial Comment: \pdfsavepos in DVI mode Hello, using \pdfsavepos in a package of mine (tabularht) I was wondering, why \pdfsavepos is not allowed to work in DVI mode. \pdfsavepos in PDF mode is based on cur_h and cur_v, both coming from the DVI frontend. The only difference I found is that the PDF format and pdfTeX's PDF mode know about page dimensions. Thus the directions of the axes are the same for the PDF format and the values of \pdfsavepos (\pdflastxpos, \pdflastypos). Origin: lower left corner horizontal axis: values increasing from left to right vertical axis: values increasing from bottom to top unit: sp The DVI case doesn't know about page dimensions, thus I suggest using cur_h=0 and cur_v=0 as origin. It is the left upper corner of the box that is being shipped out. Origin: left upper corner of the box horizontal axis: values increasing from left to right vertical axis: values increasing from bottom to top unit: sp Thus the absolute values differ in both modes and I don't see that this can be avoided. However, if the application uses a reference point then the relative values are exactly the same. The attachted patch enables and implements \pdfsavepos for the DVI mode. It also contains the patch for bug 437 (Two \immediate cancel themselves). Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- >Comment By: Heiko Oberdiek (oberdiek) Date: 2005-10-17 13:39 Message: Logged In: YES user_id=1276 Hello, I have now extended the patch: \pdfpagewidth/height are now used for the page dimensions. Also the funny DVI origin offset of 1in is taken into account. Thus the values in DVI and PDF mode are the same. The exception is \pdf{h,v}origin. If the value is not 1in, then the values differ in DVI and PDF mode. However, also the DVI and PDF output will differ in this case. Thus the different values are then ok, I think. If someone wants to have the same values, he just sets \pdfpage{width,height} and let \pdf{h,v}origin untouched. Hartmut Henkel wrote: > to give page dimension info for pdftex also in > DVI mode, one could implement the standard > \special{papersize=x,y} also in pdftex (parallel > to \pdfpagewidth/height), so that it would be > scanned, and also go into the DVI file. Would > this help? I think, not really: * Scanning of \specials are done in PDF mode already, but here it is not really necessary, the current drivers know about \pdfpage{width,height}. * In DVI mode, the scanning of \special's contents must then be added to set \pdfpage{width,height}. But who needs this actually? * Relative positioning with \pdfsavepos works with or without the correct page size information. * Absolute positioning is more difficult in use (If you are somewhere in a box, how do you want to apply absolute positions?) * If someone insist on absolute positioning, he will probably not rely on an accidentally issued \special{papersize=...}. He will probably make sure, that the papersize information is set and then he can also set \pdfpage{width,height}. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> PS: The name of the patch file is now "v2-pdftex.ch.diff". And I have removed the patch of fixed bug 437. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-17 00:16 Message: Logged In: YES user_id=929 to give page dimension info for pdftex also in DVI mode, one could implement the standard \special{papersize=x,y} also in pdftex (parallel to \pdfpagewidth/height), so that it would be scanned, and also go into the DVI file. Would this help? Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=438&group_id=106

1 0

[ pdftex-Patches-438 ] \pdfsavepos in DVI mode
by noreply＠sarovar.org 17 Oct '05

17 Oct '05

Patches item #438, was opened at 2005-10-16 23:52 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=438&group_id=106 Category: Positioning Group: None Status: Open Resolution: None Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: \pdfsavepos in DVI mode Initial Comment: \pdfsavepos in DVI mode Hello, using \pdfsavepos in a package of mine (tabularht) I was wondering, why \pdfsavepos is not allowed to work in DVI mode. \pdfsavepos in PDF mode is based on cur_h and cur_v, both coming from the DVI frontend. The only difference I found is that the PDF format and pdfTeX's PDF mode know about page dimensions. Thus the directions of the axes are the same for the PDF format and the values of \pdfsavepos (\pdflastxpos, \pdflastypos). Origin: lower left corner horizontal axis: values increasing from left to right vertical axis: values increasing from bottom to top unit: sp The DVI case doesn't know about page dimensions, thus I suggest using cur_h=0 and cur_v=0 as origin. It is the left upper corner of the box that is being shipped out. Origin: left upper corner of the box horizontal axis: values increasing from left to right vertical axis: values increasing from bottom to top unit: sp Thus the absolute values differ in both modes and I don't see that this can be avoided. However, if the application uses a reference point then the relative values are exactly the same. The attachted patch enables and implements \pdfsavepos for the DVI mode. It also contains the patch for bug 437 (Two \immediate cancel themselves). Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=438&group_id=106

2 1

[ pdftex-Patches-438 ] \pdfsavepos in DVI mode
by noreply＠sarovar.org 17 Oct '05

17 Oct '05

Patches item #438, was opened at 2005-10-16 23:52 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=438&group_id=106 Category: Positioning Group: None Status: Open Resolution: None Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: \pdfsavepos in DVI mode Initial Comment: \pdfsavepos in DVI mode Hello, using \pdfsavepos in a package of mine (tabularht) I was wondering, why \pdfsavepos is not allowed to work in DVI mode. \pdfsavepos in PDF mode is based on cur_h and cur_v, both coming from the DVI frontend. The only difference I found is that the PDF format and pdfTeX's PDF mode know about page dimensions. Thus the directions of the axes are the same for the PDF format and the values of \pdfsavepos (\pdflastxpos, \pdflastypos). Origin: lower left corner horizontal axis: values increasing from left to right vertical axis: values increasing from bottom to top unit: sp The DVI case doesn't know about page dimensions, thus I suggest using cur_h=0 and cur_v=0 as origin. It is the left upper corner of the box that is being shipped out. Origin: left upper corner of the box horizontal axis: values increasing from left to right vertical axis: values increasing from bottom to top unit: sp Thus the absolute values differ in both modes and I don't see that this can be avoided. However, if the application uses a reference point then the relative values are exactly the same. The attachted patch enables and implements \pdfsavepos for the DVI mode. It also contains the patch for bug 437 (Two \immediate cancel themselves). Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-17 00:16 Message: Logged In: YES user_id=929 to give page dimension info for pdftex also in DVI mode, one could implement the standard \special{papersize=x,y} also in pdftex (parallel to \pdfpagewidth/height), so that it would be scanned, and also go into the DVI file. Would this help? Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=438&group_id=106

1 0

[ pdftex-Bugs-304 ] Names of expanded fonts not in log output
by noreply＠sarovar.org 17 Oct '05

17 Oct '05

Bugs item #304, was opened at 2005-03-02 18:25 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106 Category: Fonts Group: v1.21a >Status: Open >Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: Hartmut Henkel (hhenkel) Summary: Names of expanded fonts not in log output Initial Comment: When using font expansion, the log output will not contain the names of the expanded fonts but the null character instead (resp. ^^@). %------------------------------------- \pdfadjustspacing=2 \pdffontexpand\font 20 20 5 autoexpand \tracingoutput=1 test \parfillskip 0pt test \bye %------------------------------------- Regards, Robert. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2005-10-16 00:24 Message: Logged In: YES user_id=2217 If the font is not autoexpand'ed, its name will still not be written to the log file. (pdftex 1.30.3; same test file, without "autoexpand") Regards, Robert. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-05-12 17:05 Message: Logged In: YES user_id=421 This has been fixed in 1.30.0 ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-30 22:16 Message: Logged In: YES user_id=929 This patch is based of Thanh's change file showfont.ch, which he gave me during EuroTeX2005 (it's also included, renamed here to showfont-thanh.ch). Use showfont.ch for the patch. There is now a new integer variable \pdftracingfonts. It is zero by default, then we get a log like this (see robert050302.log): ...\tenrm t ...\tenrm (+20) e Without font expansion, this default should be compatible with TeX's original log output. If \pdftracingfonts is set to 1 (or greater), we get a more verbose log (see tst-304.log): ...\xivtt (cmtt10(a)14.0pt) t .\xivtt (cmtt10+20(a)14.0pt) e Seems to work with change file showfont.ch coming directly after after hz.ch. Patch only roughly tested with pdfetex, likely to give problems with pdfxtex, as the variable numbering might differ. Log format to be agreed upon... Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106

1 0

[ pdftex-Bugs-437 ] Two \immediate cancel themselves
by noreply＠sarovar.org 17 Oct '05

17 Oct '05

Bugs item #437, was opened at 2005-10-15 23:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=437&group_id=106 Category: None Group: v1.30.0 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Hartmut Henkel (hhenkel) Summary: Two \immediate cancel themselves Initial Comment: Hello, Vladimir Volovich found the following bug, I quote his bug report from the ntg-pdftex list here: > consider the following Plain TeX file: > > \immediate\immediate\openout1=test.out > \immediate\write1 {line 1} > \immediate\write1 {line 2} > \immediate\closeout1 > > \bye > > (it was reduced from a real-life example). > > if i process it with vanilla TeX engine (i.e. not > with pdfetex, but with TeX), you get what i expect: > two lines are written to the file test.out, and > there are no pages of output (no DVI file generated). > > however, if i process this file with pdfetex, i do > not get what i would expect: instead, the lines are > written to terminal, test.out is created and is > empty, and there is also a 1-page PDF file generated. > > the bug goes away if i remove the second \immediate, > but as i said this is a simplified example converted > from a real-life usage. It is indeed a bug: this is the original code of "Implement \immediate": | begin get_x_token; | if (cur_cmd=extension)and(cur_chr<=close_node) then | begin p:=tail; do_extension;{append a whatsit node} | out_what(tail); {do the action immediately} | flush_node_list(tail); tail:=p; link(p):=null; | end | else back_input; | end A token is read. If the token hears to \immediate, it is executed with the immediate setting. Otherwise the token is just put back. Now pdfTeX has more commands that obey \immediate: | begin get_x_token; | if cur_cmd=extension then begin | if cur_chr<=close_node then | begin <<original action>> end | else case cur_chr of | pdf_obj_code: begin <<...>> end; | pdf_xform_code: begin <<...>> end; | pdf_ximage_code: begin <<...>> end; | end; | endcases; | end | else | back_input; | end Cases: a) cur_cmd != extension --> nothing is changed (back_input) b) cur_cmd == extension && cur_chr <= close_node --> nothing is changed (original action) c) cur_cmd == extension && cur_chr in (pdf_{obj,xform,ximage}_code) --> new behaviour for pdfTeX d) cur_cmd == extension && cur_chr > close_node && cur_chr not in (pdf_{obj,xform,ximage}_code) --> no action Case d) is the bug. \immediate is an extension primitive with cur_chr > close_node. Thus the second \immediate is read, but then dropped. The effect is: \immediate\immediate\openout is same as \openout Instead of "no action" there should be "back_input". Before "endcases" the following line needs to be added: ... else case cur_chr of ... othercases back_input endcases; I have attachted a diff file for pdftexdir/pdftex.ch. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=437&group_id=106

1 0

[ pdftex-Bugs-435 ] Wrong file name in error messages of image inclusion (readimage)
by noreply＠sarovar.org 17 Oct '05

17 Oct '05

Bugs item #435, was opened at 2005-10-15 01:21 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=435&group_id=106 Category: Image inclusion >Group: v1.30.0 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Martin Schröder (oneiros) Summary: Wrong file name in error messages of image inclusion (readimage) Initial Comment: Hello, see the thread "Wrong search path for PDF/PNG/JPG files" (2005/10/14) in the pdftex mailing list. Wlodek Bzyl detected a bug regarding image inclusion: pdfTeX sometimes prints a wrong file name in image error messages: The current directory contains: pic.jpg (JPG image), pic.jpg.tex (e.g. consisting of "\relax") and test.tex: \pdfximage{pic.jpg} \pdfrefximage\pdflastximage \bye Then kpse_find_file will find "pic.jpg.tex" (the automatically adding of ".tex" is sometimes very annoying) and prints the error message: Error: pdftex (file ./pic.jpg): reading image file failed Or if the file pic.jpg.tex is longer: Error: pdftex (file ./pic.jpg): unknown type of image In both cases the file name in the error message is wrong. The error message is thrown by pdftex_fail that looks for cur_file_name and prints it (utils.c). However the real image file name can be changed by kpse_find_file (e.g. adding ".tex"): img_name(img) = kpse_find_file(cur_file_name, kpse_tex_format, true); if (img_name(img) == NULL) pdftex_fail("cannot find image file"); // Here the file name is still correct // (img_name(img) is NULL) // But after this, img_name(img) is not NULL and // contains the used file name, cur_file_name is no // longer valid. checktypebyheader(img); checktypebyextension(img); ... default: pdftex_fail("unknown type of image"); } ... cur_file_name = NULL; ... // checktypebyheader calls pdftex_fail, // and pdftex_fail is also used // later, in each case using the wrong cur_file_name. Fix is easy: cur_file_name = img_name(img); after the NULL check part before checktypebyheader. There are no memory problems. Before cur_file_name points to a static buffer, the return value of makecstring. Thus free must not be used on cur_file_name. And the memory part of img_name(img) is not changed. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=435&group_id=106

1 0

[ pdftex-Bugs-437 ] Two \immediate cancel themselves
by noreply＠sarovar.org 17 Oct '05

17 Oct '05

Bugs item #437, was opened at 2005-10-15 23:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=437&group_id=106 Category: None >Group: v1.30.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) >Assigned to: Hartmut Henkel (hhenkel) Summary: Two \immediate cancel themselves Initial Comment: Hello, Vladimir Volovich found the following bug, I quote his bug report from the ntg-pdftex list here: > consider the following Plain TeX file: > > \immediate\immediate\openout1=test.out > \immediate\write1 {line 1} > \immediate\write1 {line 2} > \immediate\closeout1 > > \bye > > (it was reduced from a real-life example). > > if i process it with vanilla TeX engine (i.e. not > with pdfetex, but with TeX), you get what i expect: > two lines are written to the file test.out, and > there are no pages of output (no DVI file generated). > > however, if i process this file with pdfetex, i do > not get what i would expect: instead, the lines are > written to terminal, test.out is created and is > empty, and there is also a 1-page PDF file generated. > > the bug goes away if i remove the second \immediate, > but as i said this is a simplified example converted > from a real-life usage. It is indeed a bug: this is the original code of "Implement \immediate": | begin get_x_token; | if (cur_cmd=extension)and(cur_chr<=close_node) then | begin p:=tail; do_extension;{append a whatsit node} | out_what(tail); {do the action immediately} | flush_node_list(tail); tail:=p; link(p):=null; | end | else back_input; | end A token is read. If the token hears to \immediate, it is executed with the immediate setting. Otherwise the token is just put back. Now pdfTeX has more commands that obey \immediate: | begin get_x_token; | if cur_cmd=extension then begin | if cur_chr<=close_node then | begin <<original action>> end | else case cur_chr of | pdf_obj_code: begin <<...>> end; | pdf_xform_code: begin <<...>> end; | pdf_ximage_code: begin <<...>> end; | end; | endcases; | end | else | back_input; | end Cases: a) cur_cmd != extension --> nothing is changed (back_input) b) cur_cmd == extension && cur_chr <= close_node --> nothing is changed (original action) c) cur_cmd == extension && cur_chr in (pdf_{obj,xform,ximage}_code) --> new behaviour for pdfTeX d) cur_cmd == extension && cur_chr > close_node && cur_chr not in (pdf_{obj,xform,ximage}_code) --> no action Case d) is the bug. \immediate is an extension primitive with cur_chr > close_node. Thus the second \immediate is read, but then dropped. The effect is: \immediate\immediate\openout is same as \openout Instead of "no action" there should be "back_input". Before "endcases" the following line needs to be added: ... else case cur_chr of ... othercases back_input endcases; I have attachted a diff file for pdftexdir/pdftex.ch. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=437&group_id=106

1 0