- ntg-pdftex - NTG Mailing Lists

[pdftex-Bugs][4347] "Error (202): Command token too long" output to stderr rather than stdout, without necessary info
by pdftex-bugs＠sarovar.org 03 Mar '12

03 Mar '12

Bugs item #4347, was opened at 2012-03-03 06:34 Status: Open Priority: 3 Submitted By: Ben Crowell (bcrowell) Assigned to: Nobody (None) Summary: "Error (202): Command token too long" output to stderr rather than stdout, without necessary info Category: PDF inclusion Group: v1.40.8 Resolution: None Initial Comment: Recent versions of pdftex sometimes print the error message "Error (202): Command token too long" to stderr. Since the message is not interleaved with pdtex's other output, and the message comes without any context, it becomes difficult or impossible for the user to know what is causing the error or what it means. This has been discussed on stackexchange: http://tex.stackexchange.com/questions/42348/pdflatex-command-token-too-lon… Based on this discussion, it sounds like this occurs when the poppler library is trying to parse a pdf file as input and doesn't like it. I don't know if it's poppler itself that is printing messages to stderr; if so, then this is a bug in poppler, not pdftex. (A library shouldn't be doing I/O to stderr.) I realize that this would be a more helpful bug report if I could provide an example of a pdf file that was causing the error, but this is occurring for me on a file that pulls in a large number of pdf images, and I don't have time right now to figure out which one is the problem. pdfTeX 3.1415926-1.40.10-2.2 (TeX Live 2009/Debian) kpathsea version 5.0.0 Copyright 2009 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). There is NO warranty. Redistribution of this software is covered by the terms of both the pdfTeX copyright and the Lesser GNU General Public License. For more information about these matters, see the file named COPYING and the pdfTeX source. Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Compiled with libpng 1.2.46; using libpng 1.2.46 Compiled with zlib 1.2.3.4; using zlib 1.2.3.4 Compiled with poppler version 0.16.7 ---------------------------------------------------------------------- Comment By: Ben Crowell (bcrowell) Date: 2012-03-03 11:15 Message: I can't attach the figure. Stackexchange user ryan0270 is the one who has that. In my own case, I can't tell (easily) which of the hundreds of figures in my project is the one causing this. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2012-03-03 11:04 Message: please attach figures/Jan25/svdDir_svdCompare1.pdf ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4347&group_id=106

1 0

[pdftex-Bugs][4347] "Error (202): Command token too long" output to stderr rather than stdout, without necessary info
by pdftex-bugs＠sarovar.org 03 Mar '12

03 Mar '12

Bugs item #4347, was opened at 2012-03-03 14:34 Status: Open Priority: 3 Submitted By: Ben Crowell (bcrowell) Assigned to: Nobody (None) >Summary: "Error (202): Command token too long" output to stderr rather than stdout, without necessary info Category: PDF inclusion Group: v1.40.8 Resolution: None Initial Comment: Recent versions of pdftex sometimes print the error message "Error (202): Command token too long" to stderr. Since the message is not interleaved with pdtex's other output, and the message comes without any context, it becomes difficult or impossible for the user to know what is causing the error or what it means. This has been discussed on stackexchange: http://tex.stackexchange.com/questions/42348/pdflatex-command-token-too-lon… Based on this discussion, it sounds like this occurs when the poppler library is trying to parse a pdf file as input and doesn't like it. I don't know if it's poppler itself that is printing messages to stderr; if so, then this is a bug in poppler, not pdftex. (A library shouldn't be doing I/O to stderr.) I realize that this would be a more helpful bug report if I could provide an example of a pdf file that was causing the error, but this is occurring for me on a file that pulls in a large number of pdf images, and I don't have time right now to figure out which one is the problem. pdfTeX 3.1415926-1.40.10-2.2 (TeX Live 2009/Debian) kpathsea version 5.0.0 Copyright 2009 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). There is NO warranty. Redistribution of this software is covered by the terms of both the pdfTeX copyright and the Lesser GNU General Public License. For more information about these matters, see the file named COPYING and the pdfTeX source. Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Compiled with libpng 1.2.46; using libpng 1.2.46 Compiled with zlib 1.2.3.4; using zlib 1.2.3.4 Compiled with poppler version 0.16.7 ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2012-03-03 19:04 Message: please attach figures/Jan25/svdDir_svdCompare1.pdf ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4347&group_id=106

1 0

[pdftex-Bugs][4347] "Error (202): Command token too long" output to stderr rather than stdout, without necessary info
by pdftex-bugs＠sarovar.org 03 Mar '12

03 Mar '12

Bugs item #4347, was opened at 2012-03-03 06:34 Status: Open Priority: 3 Submitted By: Ben Crowell (bcrowell) Assigned to: Nobody (None) Summary: "Error (202): Command token too long" output to stderr rather than stdout, without necessary info Category: PDF inclusion Group: v1.40.8 Resolution: None Initial Comment: Recent versions of pdftex sometimes print the error message "Error (202): Command token too long" to stderr. Since the message is not interleaved with pdtex's other output, and the message comes without any context, it becomes difficult or impossible for the user to know what is causing the error or what it means. This has been discussed on stackexchange: http://tex.stackexchange.com/questions/42348/pdflatex-command-token-too-lon… Based on this discussion, it sounds like this occurs when the poppler library is trying to parse a pdf file as input and doesn't like it. I don't know if it's poppler itself that is printing messages to stderr; if so, then this is a bug in poppler, not pdftex. (A library shouldn't be doing I/O to stderr.) I realize that this would be a more helpful bug report if I could provide an example of a pdf file that was causing the error, but this is occurring for me on a file that pulls in a large number of pdf images, and I don't have time right now to figure out which one is the problem. pdfTeX 3.1415926-1.40.10-2.2 (TeX Live 2009/Debian) kpathsea version 5.0.0 Copyright 2009 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). There is NO warranty. Redistribution of this software is covered by the terms of both the pdfTeX copyright and the Lesser GNU General Public License. For more information about these matters, see the file named COPYING and the pdfTeX source. Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Compiled with libpng 1.2.46; using libpng 1.2.46 Compiled with zlib 1.2.3.4; using zlib 1.2.3.4 Compiled with poppler version 0.16.7 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4347&group_id=106

1 0

A naive idea about forward-inverse search (not synctex)
by Yih-Dar Shieh 10 Jan '12

10 Jan '12

I used synctex to get the forward-inverse search between tex source and pdf file. It created a .synctex file which record the coordinate correspondences between .tex and .pdf. I have the following naive idea: during compilation, each time we get some "output", we put an "extra information". This "extra information" should be contents of the output pdf, which is invisible, and do not affect the layout (using this feature or not). For example, it is similar to "hypperef", which has an "extra information" so we can go to another location on the .pdf. The "extra information" for this forward-inverse search could be "(line,column)" of the .tex source. The following example may make this clear: Tex Source: .....This is an example. And the output PDF: ...T(1,1)h(1,2)i(1,3)s(1,4) (1,5)i(1,6)s(1,7) (1,8)a(1,9)n(1,10) (1,11)e(1,12)x(1,13)a(1,14)m( 1,15)p(1,16)l(1,14)e(1,18). The (x,y) should be invisible on PDF, and the location should be at the same location of their corresponding "output letter" and the space it takes is the size of a single letter. This means that: (the above example): when we click "T", we get an information (1,1) , just similar to hyperref. Similarly, when we click "h", we get (1,2). If this is done, then it is easy to do the inverse search (from pdf to tex), since the information is on the pdf file. For forward search, it is easy also: when we click on tex source, of course the editor knows the (line,column), and it sends this information to pdf viewer and finally the viewer "go to the location of this (line, column)". (Suppose the viewer could "Find" where is (line,column), this need to be implemented.) Of course, the size of the output pdf with this sync option will be large. But we can do this by using "word" instead of "letter" for text and using "each symbol" for math formula. The advantage of this feature (to synctex) is: We get very precise locations when we do forward-inverse search. And the implemention should not be difficult, since it just do "something extra" which are easy: get the (x,y) on the source--OK ; Produce invisible output--Don't know if this is possible. Compare to synctex method, we don't have to calculate the coordinate correspondence between source and output. Also, the time needed to compile is (about) double at most. The disadvantage is that the output pdf has large size. Of course, after we finish the work of typping, and want to publish the .pdf file, we can compile it without sync option. Although I say this would be easy, I mean this would be easy for developers of pdftex. The ability to do this is far beyond my programming ability. I would like to know from you that if this naive idea is doable. If not, what are the difficulities? Do you think this is a good idea? And of course, if we agree this is a good idea, I hope the developers could implement it. Best Regards

1 0

[Support Request] Cross-compilation of pdftex
by Young Kevin 25 Oct '11

25 Oct '11

Hi developers, First of all, thank you infinitely for writing and maintaining such a great piece of software, which pdftex is! I hope I can provide my share of service to the TEX community with what follows. My wish is to cross compile pdftex against the Android-ARM target (using NDK), because I can't stand the fact that for tablets there exists simply no good typesetting software. I had a look at your build system, but for a layman it's easy to get confused. Therefore I'd be thankful if some of you developers could provide me with a rundown on your build system and its complexity - for in order to compile pdftex with the Android SDK, I need to replicate the steps of your build system using the NDK build system (simplified makefiles). Or do you have better suggestions? Thanks a bunch! Kevin

1 0

[pdftex-Feature Requests][4342] Output clearer for parsing it more easily
by pdftex-featurerequests＠sarovar.org 27 Jul '11

27 Jul '11

Feature Requests item #4342, was opened at 2011-07-27 19:57 Status: Open Priority: 3 Submitted By: Sébastien Wilmet (swilmet) Assigned to: Nobody (None) Summary: Output clearer for parsing it more easily Category: None Group: None Resolution: None Initial Comment: Hello, Parsing the output of pdfTeX is not an easy task. Thus it would be nice to have a clearer output. The main issues I see currently: - Opening and closing files with parentheses: when we find a closing parenthesis, we are not sure it closes a file. - A context from the document is sometimes printed below a warning or an error, but those contexts don't have delimiters. - A line can contain several information, and one information can be split into several lines. It doesn't make the parsing easier. There was a mail on the mailing list about the same issue: http://tug.org/mailman/htdig/pdftex/2009-March/007960.html Best regards, Sébastien ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=4342&group_id=106

1 0

[pdftex-Support Requests][4337] Text inside lstlisting in generated PDF have extra spaces
by pdftex-supportrequests＠sarovar.org 23 Jul '11

23 Jul '11

Support Requests item #4337, was opened at 2011-04-04 15:06 Status: Open Priority: 3 Submitted By: MaxiM Basunov (mbasunov) Assigned to: Nobody (None) Summary: Text inside lstlisting in generated PDF have extra spaces Category: None Group: None Resolution: None Initial Comment: Hello. In our documents we use lstlisting and PDF, generated with pdflatex, contains extra spaces between characters, so it makes PDF unuseful for copy-paste. Attached files produce following text when copied from PDF: a sdf l i s t i n g /home/ t e s t / t e s t 2 l i n e 2 \\ t e s t \bbb\ t e s t 2 Sample from other document: "1. exported resources configured" when copied to clipboard produce some missed characters: "1. exported resources congured." Please help to solve these issues. Can it be solved with my local settings? PS: Ubuntu 10.10 Maverick. Acrobat Reader 9.4 lyx 1.6.7-1 texlive-latex-base 2009-10 pdfTeX 3.1415926-1.40.10-2.2 (TeX Live 2009/Debian) kpathsea version 5.0.0 Copyright 2009 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). There is NO warranty. Redistribution of this software is covered by the terms of both the pdfTeX copyright and the Lesser GNU General Public License. For more information about these matters, see the file named COPYING and the pdfTeX source. Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Compiled with libpng 1.2.44; using libpng 1.2.44 Compiled with zlib 1.2.3.4; using zlib 1.2.3.4 Compiled with poppler version 0.14.2 Thank you, ---------------------------------------------------------------------- Comment By: MaxiM Basunov (mbasunov) Date: 2011-07-22 08:49 Message: No more needs in this solution. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=4337&group_id=106

4 3

[pdftex-Bugs][4341] Stream dictionary improperly formatted
by pdftex-bugs＠sarovar.org 20 Jul '11

20 Jul '11

Bugs item #4341, was opened at 2011-07-14 00:38 Status: Open Priority: 3 Submitted By: Vincent Immler (vini) Assigned to: Nobody (None) Summary: Stream dictionary improperly formatted Category: Primitives Group: v1.40.8 Resolution: Works For Me Initial Comment: Testing with: Acrobat 9.4.5 (Mac/US-EN) and pdftex-1.40.11 (TeXLive2010): Running Acrobat's preflight using "Verify compliance with PDF/A-1b" results in several errors. It appears to me, that Adobe has changed something, as it worked worked some time ago (at least for me with an older version of both Acrobat and pdftex). Preflight complains about the following: [X] Syntax problem: Indirect object "endobj" keyword not preceded by an EOL marker [X] Syntax problem: Indirect object "obj" keyword not followed by an EOL marker [X] Syntax problem: Stream dictionary improperly formatted The appended patch applies to pdftex.web and solves the first two problems. The third one is not solved yet and only occurs when including XMP data (could be a problem with xmpincl.sty or the provided xmp data file). ---------------------------------------------------------------------- Comment By: Vincent Immler (vini) Date: 2011-07-20 20:46 Message: I'm very interested in the topic but it is quite hard to familiarize with all the stuff :-) Perhaps you want to have a look at the attached zip-File. It contains instructions, a sample file and the verified results. It is working for this simple test file and is working for rather complex examples, too. Everything works! ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2011-07-20 18:48 Message: thanks for playing with this. Yes this is a known problem and I got stuck with this; the stream seems to be ok but yet AR9 is not happy (AR8 was ok). More thorough testing needed. ---------------------------------------------------------------------- Comment By: Vincent Immler (vini) Date: 2011-07-20 10:38 Message: In the meantime, I checked out the SVN version for tagged-pdf and found out, that this problem seems to be known already. However, the tagged-pdf branch does not work for me. I was now able to solve the problem by forcing the EOL character to be 13 before each "endstream" instead of 10. pdf_seek_write_length := false; pdf_out(13); pdf_print_ln("endstream"); (I'm quite sure, this is not well-thought-out, but it works :-)) Using this modification in addition to the aforementioned two small modifications allows me to generate PDFA-1b compliant documents according to Acrobat 9.4.5. ---------------------------------------------------------------------- Comment By: Vincent Immler (vini) Date: 2011-07-14 12:14 Message: I made progress in solving the last problem and found out, that it does not seem to be related to pdftex. To my best knowledge, it is because of xmpincl.sty when generating the xmpi file for inclusion. The way how the .xmp is read needs to be improved and I'm currently working on that. ---------------------------------------------------------------------- Comment By: Vincent Immler (vini) Date: 2011-07-14 00:56 Message: Just attached a PDF that has the error, so you can check. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4341&group_id=106

1 0

[pdftex-Bugs][4341] Stream dictionary improperly formatted
by pdftex-bugs＠sarovar.org 20 Jul '11

20 Jul '11

Bugs item #4341, was opened at 2011-07-14 00:38 Status: Open Priority: 3 Submitted By: Vincent Immler (vini) Assigned to: Nobody (None) Summary: Stream dictionary improperly formatted Category: Primitives Group: v1.40.8 Resolution: Works For Me Initial Comment: Testing with: Acrobat 9.4.5 (Mac/US-EN) and pdftex-1.40.11 (TeXLive2010): Running Acrobat's preflight using "Verify compliance with PDF/A-1b" results in several errors. It appears to me, that Adobe has changed something, as it worked worked some time ago (at least for me with an older version of both Acrobat and pdftex). Preflight complains about the following: [X] Syntax problem: Indirect object "endobj" keyword not preceded by an EOL marker [X] Syntax problem: Indirect object "obj" keyword not followed by an EOL marker [X] Syntax problem: Stream dictionary improperly formatted The appended patch applies to pdftex.web and solves the first two problems. The third one is not solved yet and only occurs when including XMP data (could be a problem with xmpincl.sty or the provided xmp data file). ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2011-07-20 18:48 Message: thanks for playing with this. Yes this is a known problem and I got stuck with this; the stream seems to be ok but yet AR9 is not happy (AR8 was ok). More thorough testing needed. ---------------------------------------------------------------------- Comment By: Vincent Immler (vini) Date: 2011-07-20 10:38 Message: In the meantime, I checked out the SVN version for tagged-pdf and found out, that this problem seems to be known already. However, the tagged-pdf branch does not work for me. I was now able to solve the problem by forcing the EOL character to be 13 before each "endstream" instead of 10. pdf_seek_write_length := false; pdf_out(13); pdf_print_ln("endstream"); (I'm quite sure, this is not well-thought-out, but it works :-)) Using this modification in addition to the aforementioned two small modifications allows me to generate PDFA-1b compliant documents according to Acrobat 9.4.5. ---------------------------------------------------------------------- Comment By: Vincent Immler (vini) Date: 2011-07-14 12:14 Message: I made progress in solving the last problem and found out, that it does not seem to be related to pdftex. To my best knowledge, it is because of xmpincl.sty when generating the xmpi file for inclusion. The way how the .xmp is read needs to be improved and I'm currently working on that. ---------------------------------------------------------------------- Comment By: Vincent Immler (vini) Date: 2011-07-14 00:56 Message: Just attached a PDF that has the error, so you can check. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4341&group_id=106

1 0

[pdftex-Bugs][4341] Stream dictionary improperly formatted
by pdftex-bugs＠sarovar.org 20 Jul '11

20 Jul '11

Bugs item #4341, was opened at 2011-07-14 00:38 Status: Open Priority: 3 Submitted By: Vincent Immler (vini) Assigned to: Nobody (None) Summary: Stream dictionary improperly formatted Category: Primitives Group: v1.40.8 Resolution: Works For Me Initial Comment: Testing with: Acrobat 9.4.5 (Mac/US-EN) and pdftex-1.40.11 (TeXLive2010): Running Acrobat's preflight using "Verify compliance with PDF/A-1b" results in several errors. It appears to me, that Adobe has changed something, as it worked worked some time ago (at least for me with an older version of both Acrobat and pdftex). Preflight complains about the following: [X] Syntax problem: Indirect object "endobj" keyword not preceded by an EOL marker [X] Syntax problem: Indirect object "obj" keyword not followed by an EOL marker [X] Syntax problem: Stream dictionary improperly formatted The appended patch applies to pdftex.web and solves the first two problems. The third one is not solved yet and only occurs when including XMP data (could be a problem with xmpincl.sty or the provided xmp data file). ---------------------------------------------------------------------- Comment By: Vincent Immler (vini) Date: 2011-07-20 10:38 Message: In the meantime, I checked out the SVN version for tagged-pdf and found out, that this problem seems to be known already. However, the tagged-pdf branch does not work for me. I was now able to solve the problem by forcing the EOL character to be 13 before each "endstream" instead of 10. pdf_seek_write_length := false; pdf_out(13); pdf_print_ln("endstream"); (I'm quite sure, this is not well-thought-out, but it works :-)) Using this modification in addition to the aforementioned two small modifications allows me to generate PDFA-1b compliant documents according to Acrobat 9.4.5. ---------------------------------------------------------------------- Comment By: Vincent Immler (vini) Date: 2011-07-14 12:14 Message: I made progress in solving the last problem and found out, that it does not seem to be related to pdftex. To my best knowledge, it is because of xmpincl.sty when generating the xmpi file for inclusion. The way how the .xmp is read needs to be improved and I'm currently working on that. ---------------------------------------------------------------------- Comment By: Vincent Immler (vini) Date: 2011-07-14 00:56 Message: Just attached a PDF that has the error, so you can check. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4341&group_id=106

1 0