- ntg-pdftex - NTG Mailing Lists

[ pdftex-Patches-447 ] Don't write /Encoding for non-reencoded fonts
by noreply＠sarovar.org 06 Nov '05

06 Nov '05

Patches item #447, was opened at 2005-11-06 12:26 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=447&group_id=106 Category: Fonts Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: Don't write /Encoding for non-reencoded fonts Initial Comment: The /Encoding entry in the /Font dictionary is only needed when the font is actually reencoded, see the PDF Ref. v. 1.6, section 5.5.5. Currently also for non-reencoded Type1 fonts the /Encoding entry and its /Encoding object with the /Differences array are generated from the /Encoding in the font, duplicating it unnecessarily. This happens particularily with the many CM fonts. By the tiny patch to writefont.c this /Encoding entry and the array object will not be generated and written any more for non-reencoded Type1 fonts. The PDF reader application will then take the /Encoding from the embedded font file. Testing welcome. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=447&group_id=106

1 0

[ pdftex-Feature Requests-429 ] Make PDF documents accessible to visually imparied.
by noreply＠sarovar.org 04 Nov '05

04 Nov '05

Feature Requests item #429, was opened at 2005-09-12 04:07 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=429&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Timothy O'Brien (oberon101) Assigned to: Nobody (None) Summary: Make PDF documents accessible to visually imparied. Initial Comment: Adobe Reader has a'reflow' feature that allows visually impaired users to zoom into properly formatted documents and read them without having to move the viewable area back and forth across the page. PDFs made in MikteX eith pdfte are not properly formatted and reflow without interword spacing, redering them unreadable. I contacted the MikteX people and they referred me here. I beleive Scientific Word also uses pdftex with the same result. Any chance this could be fixed? ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2005-11-05 01:28 Message: Logged In: NO I would volonteer to test the feature. I am writing a rather long pdf produced with pdftex that is downloadable for free ( http://www.motionmountain.net ) and readers regularly ask why it cannot be read aloud. Pdftex probably would only need to be extended with a single command - something like \writetaghere{tagtype} - and all the rest could be done by extensions to the latex cls and sty files. CS ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=429&group_id=106

1 0

Re: pdftosrc man page (fwd)
by Hartmut Henkel 03 Nov '05

03 Nov '05

---------- Forwarded message ---------- Date: Thu, 03 Nov 2005 15:10:48 +0100 From: Frank Küster <frank(a)kuesterei.ch> To: Hilmar Preusse <hille42(a)web.de> Cc: Hartmut Henkel <hartmut_henkel(a)gmx.de>, ntg-pdftex(a)ntg.nl Subject: Re: pdftosrc man page Hilmar Preusse <hille42(a)web.de> wrote: > On 03.11.05 Frank Küster (frank(a)kuesterei.ch) wrote: >> Hartmut Henkel <hartmut_henkel(a)gmx.de> wrote: > > Hi, > >> > i've put a sketchy man page for Thanh's nice pdftosrc utility at >> > >> > http://www.circuitwizard.de/misc/pdftosrc.1.gz >> > >> > Please have a look whether one can live with it for now. >> >> Is this based on Hilmars work that we sent to the list earlier, or >> is it written from scratch? >> > No, it is not. It says much more about the functionality of pdftosrc, > meanwhile my one contains more about the background and how to attach > files. After pdftosrc disappeared from teTeX I assumed it to be > obsolete, closed all bugs and purged my work. > I've uploaded my one to http://www.amasol.de/~preusse/pdftosrc/ . I didn't even notice that pdftosrc has disappeared from teTeX - or did I just suppress my memory that we have removed it Debian-specifically? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer

2 1

Re: pdftosrc man page (fwd)
by Hartmut Henkel 03 Nov '05

03 Nov '05

---------- Forwarded message ---------- Date: Thu, 3 Nov 2005 15:23:16 +0100 From: Hilmar Preusse <hille42(a)web.de> To: Frank Küster <frank(a)kuesterei.ch> Cc: Hartmut Henkel <hartmut_henkel(a)gmx.de>, ntg-pdftex(a)ntg.nl Subject: Re: pdftosrc man page On 03.11.05 Frank Küster (frank(a)kuesterei.ch) wrote: > Hilmar Preusse <hille42(a)web.de> wrote: Hi, > > After pdftosrc disappeared from teTeX I assumed it to be > > obsolete, closed all bugs and purged my work. > > I've uploaded my one to http://www.amasol.de/~preusse/pdftosrc/ . > > I didn't even notice that pdftosrc has disappeared from teTeX - or > did I just suppress my memory that we have removed it > Debian-specifically? > IIRC the source code is still there, but it is not compiled and installed. Not, we don't modify the Makefiles. H. -- http://www.hilmar-preusse.de.vu/

1 0

Re: pdftosrc man page (fwd)
by Hartmut Henkel 03 Nov '05

03 Nov '05

---------- Forwarded message ---------- Date: Thu, 3 Nov 2005 14:34:01 +0100 From: Hilmar Preusse <hille42(a)web.de> To: Frank Küster <frank(a)kuesterei.ch> Cc: Hartmut Henkel <hartmut_henkel(a)gmx.de>, ntg-pdftex(a)ntg.nl Subject: Re: pdftosrc man page On 03.11.05 Frank Küster (frank(a)kuesterei.ch) wrote: > Hartmut Henkel <hartmut_henkel(a)gmx.de> wrote: Hi, > > i've put a sketchy man page for Thanh's nice pdftosrc utility at > > > > http://www.circuitwizard.de/misc/pdftosrc.1.gz > > > > Please have a look whether one can live with it for now. > > Is this based on Hilmars work that we sent to the list earlier, or > is it written from scratch? > No, it is not. It says much more about the functionality of pdftosrc, meanwhile my one contains more about the background and how to attach files. After pdftosrc disappeared from teTeX I assumed it to be obsolete, closed all bugs and purged my work. I've uploaded my one to http://www.amasol.de/~preusse/pdftosrc/ . H. -- http://www.hilmar-preusse.de.vu/

1 0

Re: pdftosrc man page (fwd)
by Hartmut Henkel 03 Nov '05

03 Nov '05

...seems one has to subscribe to the list to post there ---------- Forwarded message ---------- Date: Thu, 03 Nov 2005 13:51:31 +0100 From: Frank Küster <frank(a)kuesterei.ch> To: Hartmut Henkel <hartmut_henkel(a)gmx.de> Cc: ntg-pdftex(a)ntg.nl, Hilmar Preusse <hille42(a)web.de> Subject: Re: pdftosrc man page Hartmut Henkel <hartmut_henkel(a)gmx.de> wrote: > i've put a sketchy man page for Thanh's nice pdftosrc utility at > > http://www.circuitwizard.de/misc/pdftosrc.1.gz > > Please have a look whether one can live with it for now. Is this based on Hilmars work that we sent to the list earlier, or is it written from scratch? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer

1 0

pdftosrc man page
by Hartmut Henkel 03 Nov '05

03 Nov '05

i've put a sketchy man page for Thanh's nice pdftosrc utility at http://www.circuitwizard.de/misc/pdftosrc.1.gz Please have a look whether one can live with it for now. Hope this helps to close the complaints from debian. Thanks a lot. Regards, Hartmut

1 0

[ pdftex-Bugs-444 ] buffer overflow with \pdfmatch
by noreply＠sarovar.org 29 Oct '05

29 Oct '05

Bugs item #444, was opened at 2005-10-29 19:24 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=444&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: Nobody (None) Summary: buffer overflow with \pdfmatch Initial Comment: % The new \pdfmatch primitive will run into a buffer overflow with strings % longer than 1023 characters: % % (I am using 1.30.3 with Thanh's patches from pdftex.sarovar.org/src, % compiled under cygwin.) \def\x{1,2,3,4,5,6,7,8,9,0,} \def\testlist{% ,\x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x00,}% 1024 \ifcase\pdfmatch{,1,}{\testlist}\relax \fi % Also, if the pattern is too long: %\ifcase\pdfmatch{\testlist}{1}\relax \fi \bye, Robert. PS: Is there a simple way to escape all regex special characters in a string? ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-29 21:08 Message: Logged In: YES user_id=929 see patch to utils.c. This makes makecstring() memory grow on demand. Also increase MAX_CSTRING_LEN in ptexmac.h to e. g. 10000000. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=444&group_id=106

1 0

[ pdftex-Bugs-444 ] buffer overflow with \pdfmatch
by noreply＠sarovar.org 29 Oct '05

29 Oct '05

Bugs item #444, was opened at 2005-10-29 17:24 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=444&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: Nobody (None) Summary: buffer overflow with \pdfmatch Initial Comment: % The new \pdfmatch primitive will run into a buffer overflow with strings % longer than 1023 characters: % % (I am using 1.30.3 with Thanh's patches from pdftex.sarovar.org/src, % compiled under cygwin.) \def\x{1,2,3,4,5,6,7,8,9,0,} \def\testlist{% ,\x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x00,}% 1024 \ifcase\pdfmatch{,1,}{\testlist}\relax \fi % Also, if the pattern is too long: %\ifcase\pdfmatch{\testlist}{1}\relax \fi \bye, Robert. PS: Is there a simple way to escape all regex special characters in a string? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=444&group_id=106

1 0

documentation
by Reinhard Kotucha 28 Oct '05

28 Oct '05

Hi, is it possible to make documentation for pdftex and hyperref accessible to texdoc(1)? While the pdftex manual can be accessed if people know that it is called "pdftex-a" (it sounds like a joke if people say "Read the documentation" on a mailing list), the hyperref manual is inaccessible. On my system I get: $ locate manual.pdf | wc -l 164 Is it possible to solve it before TL is released? I would expect that "texdoc <packagename>" or "texdoc <progname>" provides something useful. 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. ----------------------------------------------------------------------------

7 11

Re: [tex-live] documentation
by Heiko Oberdiek 27 Oct '05

27 Oct '05

On Thu, Oct 27, 2005 at 03:00:15PM -0300, George White wrote: > Quoting Heiko Oberdiek <oberdiek(a)uni-freiburg.de>: > > > On Thu, Oct 27, 2005 at 07:00:54AM -0300, George White wrote: > > > > > Quoting Reinhard Kotucha <reinhard.kotucha(a)web.de>: > > > > > > > >>>>> "Karl" == Karl Berry <karl(a)freefriends.org> writes: > > > > > > > > > Well, if you can make a patch for the texdoc .dat file, I can > > > > > install it :). > > > > > > > > I fear that, unlike texdoctk, texdoc simply uses ls-R as a database. > > > > > > > > Thomas recently mentioned that one can define aliases, but I think > > > > that it is best if the authors provide fixes. > > > > > > It may be best, but is it practical? Will aliases help when you have > > > dozens of manual.pdf files? > > > > > > I suspect it is much easier to make changes in texdoc to support > > > "package/manual". On systems that support symlinks one could process > > > the doc tree to make package/manual.pdf -> package/package.pdf. > > > > And how you want to solve the problem of several documentation > > files? One symlink can point to just *one* file. > > Hopefully the others will at least be be mentioned in manual.pdf, Perhaps somewhere, in many cases not: * Different language versions: manual-en.pdf, manual-de.pdf, ... The normal expectation is then, that the users that open manual-en.pdf see the English version, readers of manual-de.pdf the German version, ... It would be a surprise, if theses manual versions start with a list of links to the different language versions. And which language should be choosen for this part? * Separate source code documentation and user manual, articles, slides, ... > but > this emphasizes the point that, for many packages, the directory in the > doc tree is the real connection to the package and may contain multiple files > with generic names like manual.pdf that may indicated the type of content but > tell you nothing about the package. But you still have the directory! The current texdoc behaviour is not appropriate for documentation that consist of several files: TDS:doc/.../package/package.pdf % for manual TDS:doc/.../package/package.pdf % for source code doc -> you are running out of names -> it is not clear, what the type of content is -> redundant naming, you could strip the directory "package" level A more naturally naming convention is: TDS:doc/.../package/manual.pdf TDS:doc/.../package/source.pdf Possible ways to solve the texdoc problem: * The package author offers a document for texdoc with standardized name (e.g. texdoc-index.[pdf,html,...] that contains explanations and links to the package's documentation. TDS:doc/.../packageA/texdoc-index.pdf TDS:doc/.../packageA/manual.pdf TDS:doc/.../packageA/source.pdf TDS:doc/.../packageB/texdoc-index.html TDS:doc/.../packageB/manual.html TDS:doc/.../packageB/README Then texdoc also looks for this document (texdoc-index.*). * Or a separate data base is maintained with package overviews. (e.g. source in XML. PDF and HTML are automatically generated.) source/packageA.xml source/packageB.xml pdf/packageA.pdf pdf/pacakgeB.pdf html/packageA.html html/packageB.html Then texdoc also looks for this database. * Or texdoc shows the directory and let the user decide, which file\ he wants. * ... Yours sincerely Heiko <oberdiek(a)uni-freiburg.de>

1 0

[Fwd: Producing Tagged PDF or PDF/A from LaTeX (ISO 19005-1)]
by Rolf Niepraschk 25 Oct '05

25 Oct '05

-------- Original-Nachricht -------- Betreff: Producing Tagged PDF or PDF/A from LaTeX (ISO 19005-1) Datum: 25 Oct 2005 13:36:19 GMT Von: n05W43+mgk25(a)cl.cam.ac.uk (Markus Kuhn) Organisation: University of Cambridge, England Newsgruppen: comp.text.tex Is there any solution on the horizon for turning a LaTeX document into a "Tagged PDF" file, that is a PDF 1.4 file written in such a way that the underlying Unicode plaintext in it can be recovered smoothly (for easier searching, cut&paste, NLP parsing, Braille, speech synthesis, etc.). Background: The new international standard ISO 19005-1:2005 defines an "electronic document file format for long-term preservation" called PDF/A-1. This is basically a subset of PDF 1.4, with lots of nasty and dangerous stuff (JavaScript, external references, missing fonts, encryption, etc.) removed and various historic ambiguities in the PDF spec clarified. It was mainly developed to make PDF useful for legal-deposit purposes, All very good and commendable for anyone using PDF in electronic publishing and archival applications. However: Full compliance with the PDF/A-1 format requires that "Tagged PDF" is used, such that the underlying plaintext remains accessible for further processing. How could I do that from LaTeX? Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain

1 0

[ pdftex-Patches-443 ] 512 zeros in Type1 fonts not copied anymore
by noreply＠sarovar.org 24 Oct '05

24 Oct '05

Patches item #443, was opened at 2005-10-24 22:41 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=443&group_id=106 Category: Fonts Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: 512 zeros in Type1 fonts not copied anymore Initial Comment: When embedding Type1 fonts in PDF files, it is not needed to copy the trailing 512 zeros; they are redundant. This has been suggested in the paper "Two Diet Plans for Fat PDF" by Thomas A. Phelps and Robert Wilensky. Reduces file size a little. Then /Length3 = 0, see Table 5.24 in the PDF Ref. v. 1.6. The tiny patch to writet1.c does this for pdfTeX. No change in the dvips portion. In the patch also the font matrix transform is streamlined by use of generic transform macros. Testing welcome. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=443&group_id=106

1 0

[ pdftex-Bugs-441 ] Debug output of makecfilename
by noreply＠sarovar.org 22 Oct '05

22 Oct '05

Bugs item #441, was opened at 2005-10-22 09:28 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=441&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: Debug output of makecfilename Initial Comment: Hello, since pdfTeX 1.30.4, e.g. \pdfximage prints the file name twice, the first time stderr is used and messes up the output, e.g.: <screen_output lines="8"> This is pdfTeX, Version 3.141592-1.30.4 (Web2C 7.5.5) (./test.tex (./dir.tex antrschl.jpg [1 <./antrschl.jpg>] console.jpg [1 <./console.jpg>] img002.jpg [1 <./img002.jp g>]) ) Output written on test.pdf (3 pages, 451963 bytes). Transcript written on test.log. </screen_output> The line break in "<.\img002.jpg>" looks funny. The reason is some debug output in function makecfilename of utils.c: fprintf(stderr, " %s\n", name); Patch attached that removes that line. (With comment that at least marks the incompatibiliy introduced in 1.30.4 regarding file names, but that is another topic). Output after the patch is applied: <screen_output lines="5"> This is pdfTeX, Version 3.141592-1.30.4 (Web2C 7.5.5) (./test.tex (./dir.tex [1 <./antrschl.jpg>] [1 <./console.jpg>] [1 <./img002.jp g>]) ) Output written on test.pdf (3 pages, 451963 bytes). Transcript written on test.log. </screen_output> Perhaps the output is messed up by the web interface of the bug report system. There should be five lines. The funny line break in "<.img002.jpg>" is now the normal TeX line break because of screen line. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=441&group_id=106

1 0

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 16 Oct '05

16 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 16 Oct '05

16 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 16 Oct '05

16 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 16 Oct '05

16 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 16 Oct '05

16 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

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

16 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 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