- ntg-pdftex - NTG Mailing Lists

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

16 Oct '05

Bugs item #304, was opened at 2005-03-02 17: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: Closed Resolution: Fixed 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-15 22: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 15: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 20: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

bug in pdfetex (re \immediate)?
by Vladimir Volovich 16 Oct '05

16 Oct '05

Hi! 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. Best, v.

2 1

[ pdftex-Bugs-437 ] two \immediate cancel itself
by noreply＠sarovar.org 15 Oct '05

15 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: None Status: Open Resolution: None Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: two \immediate cancel itself 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 15 Oct '05

15 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: None Status: Open Resolution: None 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-Patches-434 ] Remove queued map item handling
by noreply＠sarovar.org 13 Oct '05

13 Oct '05

Patches item #434, was opened at 2005-10-13 01:08 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=434&group_id=106 Category: Fonts Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: Remove queued map item handling Initial Comment: Remove queued map item handling from mapfile.c ============================================== Formerly all items from \pdfmapfile{+-=mapfile} or \pdfmapline{+-=mapline} were queued up in a list until the next font was selected; then the whole list was processed, e. g. all queued mapfiles or maplines read in. When one gave \pdfmapfile{mapfile} or \pdfmapline{mapline} without +-=, the pending list was cleared. The only practical use for this was to prevent reading in the default mapfile. But this can be done simpler, without queuing. With this patch all \pdfmapfile{+-=mapfile} or \pdfmapline{+-=mapline} requests are processed completely and immediately without queuing, which means that if e. g. a \pdfmapfile{+-=mapfile} primitive is scanned, the mapfile will be read in right away. This happens independently from selecting a font. When \pdfmapfile{+-=mapfile} or \pdfmapline{+-=mapline} is scanned, and there is a default mapfile, it is read first and then the mapfile. Reading of the default mapfile can be disabled by \pdfmapfile{} or \pdfmapline{} or \pdfmapfile{mapfile} or \pdfmapline{mapline} without +-= as long as the default mapfile hasn't already been read in. Latest when the first font is requested, the default mapfile will be read, if this hasn't already been disabled by the mentioned primitives. Apart from possibly reading the default mapfile, there is no other action when a font is requested, since the \pdfmapfile{+-=mapfile} or \pdfmapline{+-=mapline} primitives have already acted right away when they were called. The effects of this patch are the following: * Initial mapfile reading still can be blocked in the usual way. * The difficult to describe queuing mechanism has gone, code gets simpler. * Mapfile reading happens directly by the primitives. * Therefore it's possible to use \pdfretval with the primitives, to check success of the mapfile/line reading (not yet implemented). * As the return value is connected to the \pdfmapfile or \pdfmapline call, one can easier implement other map setting primitives and give them return values. This was not possible before, as the queuing was inbetween. * For any standard use, the patch should be compatible to the former queuing method. The mapfile.c is a patched version of the mapfile.c from Thanh's subfont patch pdftex-20050924.patch.gz for pdftex-1.30.3. Hope it doesn't sound too messy :-) For discussion. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=434&group_id=106

1 0

Re: [tex-live] Whitespace in file name with all but plain TeX fails
by Martin Schröder 12 Oct '05

12 Oct '05

On 2005-10-11 07:01:53 +0900, Akira Kakuto wrote: > > Indeed, I confirm that > > pdfetex 'v er.tex' > > works in TL 2004 and fails with the current TL pdfetex (both > > i386-linux). The error message is: > > > > ! I can't find file `"v er.tex"'. > > On Windows, pdfetex "v er.tex" is OK. > Please check > char *makecfilename(strnumber s) in utils.c, > where I find #ifdef WIN32. Is this by chance bug #377 again? :-( Best Martin PS: Followup -> ntg-pdftex -- http://www.tm.oneiros.de

4 6

pdftex documentation
by Reinhard Kotucha 10 Oct '05

10 Oct '05

Hi, is there newer documentation for pdftex available than that in the TeXLive repository? The manual in the TL repository seems to be out-of-date and I'm sure that Pawel already has something better. For this documentation (or documentation in general), a smaller value of \pdfminorversion would make more sense. Not everyone has the latest version of Acroread and some people avoid AR7 because it is so slow. Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------

4 8

Re: [tex-live] pdftex documentation
by karl＠freefriends.org 10 Oct '05

10 Oct '05

we have on p4 some (perhaps) obsolete files: pdftex-t.txt, As I wrote. Also pdftex-i.tex pdftex-w.pdf pdftex-w.tex moreover texmf/doc/pdftex/examples/ can be also removed, as pdftex has something better (I believe) in manual/samplepdf/ Indeed, I wasn't sure if samplepdf/ was really supposed to replace examples/. Overall, texmf/doc/pdftex in TL is a frustrating mix of files from a variety of places. Advice (or, ideally, a canonical location we can just copy from) would be appreciated. http://tug.org/texlive/devsrc/Master/texmf/doc/pdftex/ Thanks, Karl

2 2

[ pdftex-Patches-432 ] Rules in a PDF qQ group
by noreply＠sarovar.org 09 Oct '05

09 Oct '05

Patches item #432, was opened at 2005-10-06 21:01 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=432&group_id=106 Category: Positioning Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: Rules in a PDF qQ group Initial Comment: Put rules with their positioning on the page inside a qQ group. Should make \pdfliteral page {...} behave consistently after text or rules or images, as then any positioning starts from the PDF origin; no delta-positioning anymore. It's already being tested in pdfluatex. Just to have it at sarovar... Testing welcome, particularily with text and graphics transforms by graphicx package, to spot backward incompatibilities, if any... Regards, Hartmut ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-09 15:07 Message: Logged In: YES user_id=929 Update pdf_set_origin_temp: Now has (h, v) parameters. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=432&group_id=106

1 0

[ pdftex-Patches-427 ] Character positioning patch
by noreply＠sarovar.org 09 Oct '05

09 Oct '05

Patches item #427, was opened at 2005-09-11 12:39 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=427&group_id=106 >Category: Positioning Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: Character positioning patch Initial Comment: Experimental patch increases resolution of /Widths array by 1 fractional digit, makes corrections of type ")-1(" and ")1(" in the TJ array happen much less often, particularily for CM fonts. Gives e. g. 1 % PDF file size shrink for pdfetex web sources compiled into PDF. Rough patch only, not for production. Testing welcome. Regards, Hartmut ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-09 15:06 Message: Logged In: YES user_id=929 Patch extended: Now pdf_set_origin has (h, v) parameters, simplifies pdf_begin_text procedure. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-09 00:25 Message: Logged In: YES user_id=929 Removed pdf_first_space_corr variable, as it seems that it was defunct anyway: There was no pdf_end_string procedure call (only place where something is done with pdf_first_space_corr), where afterwards the pdf_h variable (then modified by pdf_first_space_corr) would actually be used. E. g. pdf_moveto uses pdf_last_h instead, and after pdf_end_text there is anyway a pdf_set_origin call. And pdf_begin_string gets simpler. Testing welcome! Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-03 01:16 Message: Logged In: YES user_id=929 patch updated: now the TJ array building in procedure pdf_begin_string is simplified/tidied up. Testing welcome! Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=427&group_id=106

1 0