- ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-564 ] cannot compile pdftex under cygwin anymore
by noreply＠sarovar.org 26 May '06

26 May '06

Bugs item #564, was opened at 2006-05-26 06:01 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=564&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: Nobody (None) Summary: cannot compile pdftex under cygwin anymore Initial Comment: I've recently updated my cygwin system, and since then am not able to compile pdftex anymore. gcc -v gives: | gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) The last lines of build.sh's output are: | srcdir=../../../src/texk/web2c /bin/sh ../../../src/texk/web2c/web2c/convert tangleboot | gcc -DHAVE_CONFIG_H -I. -I../../../src/texk/web2c -I.. -I../../../src/texk/web2c/.. -g -O2 -c tangleboot.c -o tangleboot.o | In file included from tangleboot.c:94: | tangleboot.h:34: error: conflicting types for 'getline' | /usr/include/sys/stdio.h:31: error: previous declaration of 'getline' was here | tangleboot.h:34: error: conflicting types for 'getline' | /usr/include/sys/stdio.h:31: error: previous declaration of 'getline' was here | make: *** [tangleboot.o] Error 1 What to do? ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-05-26 06:35 Message: Logged In: NO It's a bug in Cygwin. See the following links: http://www.mail-archive.com/tetex@dbs.uni-hannover.de/msg00961.html http://ftp.tug.org/mail/archives/pdftex/2006-February/006370.html Best, v. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=564&group_id=106

1 0

[ pdftex-Bugs-564 ] cannot compile pdftex under cygwin anymore
by noreply＠sarovar.org 26 May '06

26 May '06

Bugs item #564, was opened at 2006-05-26 00:31 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=564&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: Nobody (None) Summary: cannot compile pdftex under cygwin anymore Initial Comment: I've recently updated my cygwin system, and since then am not able to compile pdftex anymore. gcc -v gives: | gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) The last lines of build.sh's output are: | srcdir=../../../src/texk/web2c /bin/sh ../../../src/texk/web2c/web2c/convert tangleboot | gcc -DHAVE_CONFIG_H -I. -I../../../src/texk/web2c -I.. -I../../../src/texk/web2c/.. -g -O2 -c tangleboot.c -o tangleboot.o | In file included from tangleboot.c:94: | tangleboot.h:34: error: conflicting types for 'getline' | /usr/include/sys/stdio.h:31: error: previous declaration of 'getline' was here | tangleboot.h:34: error: conflicting types for 'getline' | /usr/include/sys/stdio.h:31: error: previous declaration of 'getline' was here | make: *** [tangleboot.o] Error 1 What to do? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=564&group_id=106

1 0

[ pdftex-Bugs-555 ] pdfLaTeX coredumps on OpenBSD
by noreply＠sarovar.org 20 May '06

20 May '06

Bugs item #555, was opened at 2006-05-20 14:16 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=555&group_id=106 Category: None Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: Dag Leine (dag) Assigned to: Nobody (None) Summary: pdfLaTeX coredumps on OpenBSD Initial Comment: I've found, that pdfLaTeX coredumps on OpenBSD if I use amsmath and microtype in some math environments. Here is a minimal latex document for showing the bug: > cat minidump.tex \documentclass{article} \usepackage{amsmath} \usepackage{microtype} \setlength{\parindent}{0pt} \begin{document} \begin{align} x \end{align} \end{document} % end of minidump.tex > pdflatex minidump This is pdfeTeX, Version 3.141592-1.30.6-2.2 (Web2C 7.5.5) entering extended mode (./minidump.tex LaTeX2e <2003/12/01> Babel <v3.8d> and hyphenation patterns for american, french, german, ngerman, b ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur kish, ukrainian, nohyphenation, loaded. (/usr/local/share/texmf-dist/tex/latex/base/article.cls Document Class: article 2004/02/16 v1.4f Standard LaTeX document class (/usr/local/share/texmf-dist/tex/latex/base/size10.clo)) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsmath.sty For additional information on amsmath, use the `?' option. (/usr/local/share/texmf-dist/tex/latex/amsmath/amstext.sty (/usr/local/share/texmf-dist/tex/latex/amsmath/amsgen.sty)) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsbsy.sty) (/usr/local/share/texmf-dist/tex/latex/amsmath/amsopn.sty)) (/usr/local/share/texmf-dist/tex/latex/microtype/microtype.sty (/usr/local/share/texmf-dist/tex/latex/graphics/keyval.sty) (/usr/local/share/texmf-dist/tex/latex/microtype/microtype.cfg)) (./minidump.aux) (/usr/local/share/texmf-dist/tex/latex/microtype/mt-cmr.cfg)Segmentation fault (core dumped) A quick look with gdb shows, that it hangs in line 4396 of pdfetex2.c: c = getrpcode ( f , mem [p ].hh.b1 ) ; Here p=999996 and f=-4096 Since f seems to be a table index to pdffontrbase a negative value does not make sense to my mind. I've tryed the same on a LINUX machine. There pdfLaTeX does not crash, but p and f have the same values as under OpenBSD. As the most bad work around after taking *Word I've added a line of code which leaves the routine if f becomes negative. This seems to work in the sense, that there isn't any more a core dump. regards Dag ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=555&group_id=106

1 0

[ pdftex-Feature Requests-429 ] Generate Tagged PDF
by noreply＠sarovar.org 16 May '06

16 May '06

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: 4 Submitted By: Timothy O'Brien (oberon101) Assigned to: Martin Schröder (oneiros) Summary: Generate Tagged PDF 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: 2006-05-16 17:19 Message: Logged In: NO " The main problem with reflowing is not the missing tags but that pdftex writes interword spaces as a kern (since there is no "space" in TeX, of course). " No, the main problem is that Adobe Reader dropped recognition of "words" based on *spacing* and resorted to the the simplistic approach to use *spaces* instead. This is simply ignorance of Adobe about TeX. Instead of whining about this one can do something for a practical cure: add dummy spaces at the end of every word of zero width which consist of a *space* and a kern -\wd(space). space could come from any font producing explicit spaces in the output (e.g. cmtt). It is most easily done with VF's. As far as I remember a real implementation is already there in Vtex (with some option). " non-trivial: - first pdfTeX would have to be extended with primites for a structure tree (and classes and packages would have to use these primitives) - then primitives for tagging the content are needed and must be used " i) when generating PS-code and distilling via Adobe Distiller there should be no problem to take care of pdfmarks created by classes & packages... ii) I consider the major problem is page building and page dependency of marked contents. It is just like the difficulty to get consistent color in TeX: one can consider color as sort of a "tag". E.g. a marked TeX paragraph is broken accross pages with (tagged) headers and the structure should in general kept linked also under the condition of reordered pages. I suggest first to define what functionality is required at the side of the PDF-Reader (text extraction, save as XML or audio output via screen reader). The packages should then be able to save Latex macro structure as pdfmarks for pdf tags as a prerequisite. Support of pagebreaking of tagged objects will require some assistance from pdftex like linebreaking of weblinks. HS ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-05-06 20:50 Message: Logged In: YES user_id=2217 The main problem with reflowing is not the missing tags but that pdftex writes interword spaces as a kern (since there is no "space" in TeX, of course). A rather simple but effective way would be to write the interword spaces in a different font (e.g. non-embedded Times-Roman), and then compensate for the difference between Times's width of space and the width of the glue calculated by TeX. (At least, this is what Distiller does, if you select "Advanced -> Accessibility -> Add Tags to Document".) So that (This)-419(is)-420(an)-419(example) will be turned into: /T1_0 1 Tf (This)Tj /T1_1 1 Tf ( )Tj /T1_0 1 Tf 2.369 0 Td (is)Tj /T1_1 1 Tf ( )Tj /T1_0 1 Tf 1.092 0 Td (an)Tj /T1_1 1 Tf ( )Tj /T1_0 1 Tf 1.475 0 Td (example)Tj where T1_0 is cmr10 and T1_1 is Times-Roman. This would be already a major enhancement with respect to accessibility without any packages being required. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-04-14 17:03 Message: Logged In: NO Maybe a first version can use a very low-level solution, just with a single tagging primitive; there is such a command already (I think it is called pdfliteral) . And the tree can come later. So one could start with little work, assuming one knows tagging. CS ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-04-14 16:42 Message: Logged In: YES user_id=421 I'm changing the summary. Yes, we are aware that tagged pdf is an often requested feature, but implementing it would be non-trivial: - first pdfTeX would have to be extended with primites for a structure tree (and classes and packages would have to use these primitives) - then primitives for tagging the content are needed and must be used ---------------------------------------------------------------------- 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

[ pdftex-Bugs-548 ] Forwarded problem with Test.jpg
by noreply＠sarovar.org 10 May '06

10 May '06

Bugs item #548, was opened at 2006-05-10 18:00 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=548&group_id=106 Category: Image inclusion Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Martin Schröder (oneiros) Summary: Forwarded problem with Test.jpg Initial Comment: Hello, in de.comp.text.tex Simon Eugster has problems with a jpg file: http://livingshadow.uttx.net/uploads/Test.jpg (Message-ID: <1147112925.079314.323190(a)v46g2000cwv.googlegroups.com>) I don't have a JPEG validator, but mozilla/firefox/ImageMagick/xzgv/file don't show any sign of problems with the JPEG file. Also I could reproduce his problems with pdfTeX 1.40.0-beta-20060213: \pdfximage{Test.jpg} | Error: pdftex (file ./Test.jpg): reading JPEG image failed | ==> Fatal error occurred, no output PDF file produced! Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2006-05-10 21:50 Message: Logged In: YES user_id=929 The test for JFIF file format was not adequate. Please test the patch. Bear in mind that currently only JFIF files allow to extract the image resolution values. For all others either explicitly give the wished dimensions (usual way), or set \pdfimageresolution. Else you get some default resolution. The problem went away also after treating Test.jpg (which is an EXIF file) by jhead -de, as this removed all EXIF headers. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=548&group_id=106

1 0

[ pdftex-Bugs-548 ] Forwarded problem with Test.jpg
by noreply＠sarovar.org 10 May '06

10 May '06

Bugs item #548, was opened at 2006-05-10 18:00 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=548&group_id=106 Category: Image inclusion Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Martin Schröder (oneiros) Summary: Forwarded problem with Test.jpg Initial Comment: Hello, in de.comp.text.tex Simon Eugster has problems with a jpg file: http://livingshadow.uttx.net/uploads/Test.jpg (Message-ID: <1147112925.079314.323190(a)v46g2000cwv.googlegroups.com>) I don't have a JPEG validator, but mozilla/firefox/ImageMagick/xzgv/file don't show any sign of problems with the JPEG file. Also I could reproduce his problems with pdfTeX 1.40.0-beta-20060213: \pdfximage{Test.jpg} | Error: pdftex (file ./Test.jpg): reading JPEG image failed | ==> Fatal error occurred, no output PDF file produced! Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=548&group_id=106

1 0

[ pdftex-Feature Requests-429 ] Generate Tagged PDF
by noreply＠sarovar.org 06 May '06

06 May '06

Feature Requests item #429, was opened at 2005-09-11 22:37 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: 4 Submitted By: Timothy O'Brien (oberon101) Assigned to: Martin Schröder (oneiros) Summary: Generate Tagged PDF 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: Robert (schlcht) Date: 2006-05-06 15:20 Message: Logged In: YES user_id=2217 The main problem with reflowing is not the missing tags but that pdftex writes interword spaces as a kern (since there is no "space" in TeX, of course). A rather simple but effective way would be to write the interword spaces in a different font (e.g. non-embedded Times-Roman), and then compensate for the difference between Times's width of space and the width of the glue calculated by TeX. (At least, this is what Distiller does, if you select "Advanced -> Accessibility -> Add Tags to Document".) So that (This)-419(is)-420(an)-419(example) will be turned into: /T1_0 1 Tf (This)Tj /T1_1 1 Tf ( )Tj /T1_0 1 Tf 2.369 0 Td (is)Tj /T1_1 1 Tf ( )Tj /T1_0 1 Tf 1.092 0 Td (an)Tj /T1_1 1 Tf ( )Tj /T1_0 1 Tf 1.475 0 Td (example)Tj where T1_0 is cmr10 and T1_1 is Times-Roman. This would be already a major enhancement with respect to accessibility without any packages being required. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-04-14 11:33 Message: Logged In: NO Maybe a first version can use a very low-level solution, just with a single tagging primitive; there is such a command already (I think it is called pdfliteral) . And the tree can come later. So one could start with little work, assuming one knows tagging. CS ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-04-14 11:12 Message: Logged In: YES user_id=421 I'm changing the summary. Yes, we are aware that tagged pdf is an often requested feature, but implementing it would be non-trivial: - first pdfTeX would have to be extended with primites for a structure tree (and classes and packages would have to use these primitives) - then primitives for tagging the content are needed and must be used ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2005-11-04 19:58 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

bug in utils.c of pdftex-1.40-beta-20060213
by Hartmut Henkel 01 May '06

01 May '06

there is a silly but mostly harmless buffer overrun while reading array p, sorry. Below is a patch. Regards, Hartmut --- utils.c.orig 2006-01-21 02:56:17.000000000 +0100 +++ utils.c 2006-05-01 20:48:35.000000000 +0200 @@ -1237,7 +1262,7 @@ { enum { NONUM, DOTNONUM, INT, DOT, LEADDOT, FRAC } s = NONUM, t = NONUM; char *p, *q, *r; - for (p = q = r = a; *q != '\0';) { + for (p = q = r = a; *p != '\0';) { switch (s) { case NONUM: if (*p >= '0' && *p <= '9') @@ -1296,5 +1321,6 @@ *q++ = *p++; t = s; } + *q = '\0'; return a; }

1 0

/Type/FontDescriptor missing
by Hartmut Henkel 01 May '06

01 May '06

it seems that since quite some time and still in 1.40-beta-20060213 font descriptors are not marked by /Type/FontDescriptor which is "required" by PDF Ref. version 1.6, section 5.7, table 5.19. But it seems to be ok also without :-) I'll try to add this. Regards, Hartmut

1 0

possible bug with non-closing files
by Vladimir Volovich 21 Apr '06

21 Apr '06

Hi! i'm reporting a bug discovered by Tigran Aivazian: He got this message: pdflatex: ./1016.pdf: Too many open files by running pdflatex on this simple source: \documentclass[pdftex,a5paper]{book} \usepackage[papersize={8.5in,11in}]{geometry} \usepackage{pdfpages} \begin{document} \newcount\i \i=2 \loop \ifnum\i<1725 \includepdf[pages={-}]{\number\i.pdf}% \advance\i by1 \repeat \end{document} It appears that this is due to the "ulimit" on the number of simultaneously opened files which was 1024 by default. Increasing "ulimit" allowed to process the file. But it looks like a bug in pdftex: it seems that it keeps all the files which were \includepdf'ed opened, thus causing this limit to be reached. Instead, it seems, it should close the included files. WDYT? Best, v.

3 2

epdfview
by Rolf Niepraschk 21 Apr '06

21 Apr '06

Simple PDF viewer using poppler without Gnome dependency. ==> http://www.emma-soft.com/projects/epdfview/ ...Rolf

3 2

[ pdftex-Feature Requests-429 ] Generate Tagged PDF
by noreply＠sarovar.org 14 Apr '06

14 Apr '06

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: 4 Submitted By: Timothy O'Brien (oberon101) Assigned to: Martin Schröder (oneiros) Summary: Generate Tagged PDF 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: 2006-04-14 17:03 Message: Logged In: NO Maybe a first version can use a very low-level solution, just with a single tagging primitive; there is such a command already (I think it is called pdfliteral) . And the tree can come later. So one could start with little work, assuming one knows tagging. CS ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-04-14 16:42 Message: Logged In: YES user_id=421 I'm changing the summary. Yes, we are aware that tagged pdf is an often requested feature, but implementing it would be non-trivial: - first pdfTeX would have to be extended with primites for a structure tree (and classes and packages would have to use these primitives) - then primitives for tagging the content are needed and must be used ---------------------------------------------------------------------- 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

[ pdftex-Feature Requests-429 ] Generate Tagged PDF
by noreply＠sarovar.org 14 Apr '06

14 Apr '06

Feature Requests item #429, was opened at 2005-09-12 00:37 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: 4 Submitted By: Timothy O'Brien (oberon101) >Assigned to: Martin Schröder (oneiros) >Summary: Generate Tagged PDF 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: Martin Schröder (oneiros) Date: 2006-04-14 13:12 Message: Logged In: YES user_id=421 I'm changing the summary. Yes, we are aware that tagged pdf is an often requested feature, but implementing it would be non-trivial: - first pdfTeX would have to be extended with primites for a structure tree (and classes and packages would have to use these primitives) - then primitives for tagging the content are needed and must be used ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2005-11-04 20:58 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

[ pdftex-Bugs-509 ] invalid pdf created if font name contains space
by noreply＠sarovar.org 13 Apr '06

13 Apr '06

Bugs item #509, was opened at 2006-04-13 20:37 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=509&group_id=106 Category: Fonts Group: v1.40.0 Status: Open Resolution: None Priority: 3 Submitted By: Tom Bishop (tbishop) Assigned to: Hartmut Henkel (hhenkel) Summary: invalid pdf created if font name contains space Initial Comment: pdftex 3.141592-1.30.4-2.2 runs the following code without complaining: \pdfmapline{+mssong4e <mssong.ttf <mssong4e.enc} \font\testfont=mssong4e at 20pt \testfont\char"00 \bye -- but the resulting pdf file can't be opened by Adobe Reader or GhostScript. GhostScript reports "Unknown operator: Song". The pdf file includes "/BaseFont /FEVAQU+MS Song". Evidently, the problem is the space in "MS Song", because if I use a hex editor to replace the space with an underscore, then the pdf becomes OK. The same font worked fine with earlier pdftex versions. It's a Chinese Unicode TrueType font, from Microsoft. I haven't tried installing pdftex 1.30.6; is it possible that would fix the problem? I just re-installed TeX using i-Installer for Mac OS X; it still uses pdftex 1.30.4. Here is the output of pdftex when running the test file: This is pdfeTeX, Version 3.141592-1.30.4-2.2 (Web2C 7.5.5) entering extended mode (./test3.tex [1{/Users/tbishop/Library/texmf/fonts/map/pdftex/ updmap/pdftex.map }] )</usr/local/teTeX/share/texmf.tetex/fonts/type1/bluesky/cm/ cmr10.pfb>{/usr/ local/teTeX/share/texmf.local/fonts/enc/pdftex/enc/mssong4e.enc} </usr/local/teT eX/share/texmf.local/fonts/truetype/mssong.ttf> Output written on test3.pdf (1 page, 5067 bytes). Transcript written on test3.log. Thanks in advance for any help! Best wishes, Tom Bishop (wenlin(a)wenlin.com) ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2006-04-14 00:16 Message: Logged In: YES user_id=929 well, the PDF ref. says to strip the spaces, and i don't know what consequences such underscores would have. So it seems that just stripping spaces might be a little bit closer to the right thing (in the view that this is only with buggy fonts anyway). ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2006-04-13 23:58 Message: Logged In: YES user_id=927 why not replace spaces by underscore (just as a precaution) ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-04-13 23:25 Message: Logged In: YES user_id=929 patch makes pdftex lenient with (buggy) TTF fonts that have spaces in PostScript name, strips spaces in /BaseFont and /FontName, e. g.: "MS Song" ---> "MSSong" ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-04-13 22:54 Message: Logged In: YES user_id=929 ah, after the PDF reference 5. ed. page 388 in case there would be no PostScript name entry we could be cruesome and strip the blank. But there is a wrong PostScript name in the font. So maybe one could flag a warning (or not?) and just strip the blank? (which would be easy) Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-04-13 22:39 Message: Logged In: YES user_id=929 This mssong.ttf version seems to be buggy. Here is a diagnostic printout from function ttf_read_name() in writettf.c; these are all available entries from the "Naming Table": i=0 platform_id=1 encoding_id=0 name_id=0 name <(c) Copyright ZHUHAI Stone Computerized typesetting system R&D LTD., 1995-1996> i=1 platform_id=1 encoding_id=0 name_id=1 name <MS Song> i=2 platform_id=1 encoding_id=0 name_id=2 name <Regular> i=3 platform_id=1 encoding_id=0 name_id=3 name <Microsoft:MS Song:1996> i=4 platform_id=1 encoding_id=0 name_id=4 name <MS Song> i=5 platform_id=1 encoding_id=0 name_id=5 name <Version 1.00> i=6 platform_id=1 encoding_id=0 name_id=6 name <MS Song> ---> ttf_read_name <MS Song> There is no usable PostScript name in: The TTF standard tells that under name_id=6 there should be the Postscript font, but here it is "MS Song" with a blank. As long as the font does not contain a valid PostScript name, i have no idea how to tweak this correctly... Other clues anybody? Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=509&group_id=106

1 0

[ pdftex-Bugs-509 ] invalid pdf created if font name contains space
by noreply＠sarovar.org 13 Apr '06

13 Apr '06

Bugs item #509, was opened at 2006-04-13 18:37 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=509&group_id=106 Category: Fonts Group: v1.40.0 Status: Open Resolution: None Priority: 3 Submitted By: Tom Bishop (tbishop) Assigned to: Hartmut Henkel (hhenkel) Summary: invalid pdf created if font name contains space Initial Comment: pdftex 3.141592-1.30.4-2.2 runs the following code without complaining: \pdfmapline{+mssong4e <mssong.ttf <mssong4e.enc} \font\testfont=mssong4e at 20pt \testfont\char"00 \bye -- but the resulting pdf file can't be opened by Adobe Reader or GhostScript. GhostScript reports "Unknown operator: Song". The pdf file includes "/BaseFont /FEVAQU+MS Song". Evidently, the problem is the space in "MS Song", because if I use a hex editor to replace the space with an underscore, then the pdf becomes OK. The same font worked fine with earlier pdftex versions. It's a Chinese Unicode TrueType font, from Microsoft. I haven't tried installing pdftex 1.30.6; is it possible that would fix the problem? I just re-installed TeX using i-Installer for Mac OS X; it still uses pdftex 1.30.4. Here is the output of pdftex when running the test file: This is pdfeTeX, Version 3.141592-1.30.4-2.2 (Web2C 7.5.5) entering extended mode (./test3.tex [1{/Users/tbishop/Library/texmf/fonts/map/pdftex/ updmap/pdftex.map }] )</usr/local/teTeX/share/texmf.tetex/fonts/type1/bluesky/cm/ cmr10.pfb>{/usr/ local/teTeX/share/texmf.local/fonts/enc/pdftex/enc/mssong4e.enc} </usr/local/teT eX/share/texmf.local/fonts/truetype/mssong.ttf> Output written on test3.pdf (1 page, 5067 bytes). Transcript written on test3.log. Thanks in advance for any help! Best wishes, Tom Bishop (wenlin(a)wenlin.com) ---------------------------------------------------------------------- >Comment By: Hans Hagen (hagen) Date: 2006-04-13 21:58 Message: Logged In: YES user_id=927 why not replace spaces by underscore (just as a precaution) ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-04-13 21:25 Message: Logged In: YES user_id=929 patch makes pdftex lenient with (buggy) TTF fonts that have spaces in PostScript name, strips spaces in /BaseFont and /FontName, e. g.: "MS Song" ---> "MSSong" ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-04-13 20:54 Message: Logged In: YES user_id=929 ah, after the PDF reference 5. ed. page 388 in case there would be no PostScript name entry we could be cruesome and strip the blank. But there is a wrong PostScript name in the font. So maybe one could flag a warning (or not?) and just strip the blank? (which would be easy) Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-04-13 20:39 Message: Logged In: YES user_id=929 This mssong.ttf version seems to be buggy. Here is a diagnostic printout from function ttf_read_name() in writettf.c; these are all available entries from the "Naming Table": i=0 platform_id=1 encoding_id=0 name_id=0 name <(c) Copyright ZHUHAI Stone Computerized typesetting system R&D LTD., 1995-1996> i=1 platform_id=1 encoding_id=0 name_id=1 name <MS Song> i=2 platform_id=1 encoding_id=0 name_id=2 name <Regular> i=3 platform_id=1 encoding_id=0 name_id=3 name <Microsoft:MS Song:1996> i=4 platform_id=1 encoding_id=0 name_id=4 name <MS Song> i=5 platform_id=1 encoding_id=0 name_id=5 name <Version 1.00> i=6 platform_id=1 encoding_id=0 name_id=6 name <MS Song> ---> ttf_read_name <MS Song> There is no usable PostScript name in: The TTF standard tells that under name_id=6 there should be the Postscript font, but here it is "MS Song" with a blank. As long as the font does not contain a valid PostScript name, i have no idea how to tweak this correctly... Other clues anybody? Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=509&group_id=106

1 0

[ pdftex-Bugs-509 ] invalid pdf created if font name contains space
by noreply＠sarovar.org 13 Apr '06

13 Apr '06

Bugs item #509, was opened at 2006-04-13 20:37 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=509&group_id=106 Category: Fonts >Group: v1.40.0 Status: Open Resolution: None >Priority: 3 Submitted By: Tom Bishop (tbishop) Assigned to: Hartmut Henkel (hhenkel) Summary: invalid pdf created if font name contains space Initial Comment: pdftex 3.141592-1.30.4-2.2 runs the following code without complaining: \pdfmapline{+mssong4e <mssong.ttf <mssong4e.enc} \font\testfont=mssong4e at 20pt \testfont\char"00 \bye -- but the resulting pdf file can't be opened by Adobe Reader or GhostScript. GhostScript reports "Unknown operator: Song". The pdf file includes "/BaseFont /FEVAQU+MS Song". Evidently, the problem is the space in "MS Song", because if I use a hex editor to replace the space with an underscore, then the pdf becomes OK. The same font worked fine with earlier pdftex versions. It's a Chinese Unicode TrueType font, from Microsoft. I haven't tried installing pdftex 1.30.6; is it possible that would fix the problem? I just re-installed TeX using i-Installer for Mac OS X; it still uses pdftex 1.30.4. Here is the output of pdftex when running the test file: This is pdfeTeX, Version 3.141592-1.30.4-2.2 (Web2C 7.5.5) entering extended mode (./test3.tex [1{/Users/tbishop/Library/texmf/fonts/map/pdftex/ updmap/pdftex.map }] )</usr/local/teTeX/share/texmf.tetex/fonts/type1/bluesky/cm/ cmr10.pfb>{/usr/ local/teTeX/share/texmf.local/fonts/enc/pdftex/enc/mssong4e.enc} </usr/local/teT eX/share/texmf.local/fonts/truetype/mssong.ttf> Output written on test3.pdf (1 page, 5067 bytes). Transcript written on test3.log. Thanks in advance for any help! Best wishes, Tom Bishop (wenlin(a)wenlin.com) ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2006-04-13 23:25 Message: Logged In: YES user_id=929 patch makes pdftex lenient with (buggy) TTF fonts that have spaces in PostScript name, strips spaces in /BaseFont and /FontName, e. g.: "MS Song" ---> "MSSong" ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-04-13 22:54 Message: Logged In: YES user_id=929 ah, after the PDF reference 5. ed. page 388 in case there would be no PostScript name entry we could be cruesome and strip the blank. But there is a wrong PostScript name in the font. So maybe one could flag a warning (or not?) and just strip the blank? (which would be easy) Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-04-13 22:39 Message: Logged In: YES user_id=929 This mssong.ttf version seems to be buggy. Here is a diagnostic printout from function ttf_read_name() in writettf.c; these are all available entries from the "Naming Table": i=0 platform_id=1 encoding_id=0 name_id=0 name <(c) Copyright ZHUHAI Stone Computerized typesetting system R&D LTD., 1995-1996> i=1 platform_id=1 encoding_id=0 name_id=1 name <MS Song> i=2 platform_id=1 encoding_id=0 name_id=2 name <Regular> i=3 platform_id=1 encoding_id=0 name_id=3 name <Microsoft:MS Song:1996> i=4 platform_id=1 encoding_id=0 name_id=4 name <MS Song> i=5 platform_id=1 encoding_id=0 name_id=5 name <Version 1.00> i=6 platform_id=1 encoding_id=0 name_id=6 name <MS Song> ---> ttf_read_name <MS Song> There is no usable PostScript name in: The TTF standard tells that under name_id=6 there should be the Postscript font, but here it is "MS Song" with a blank. As long as the font does not contain a valid PostScript name, i have no idea how to tweak this correctly... Other clues anybody? Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=509&group_id=106

1 0

[ pdftex-Bugs-509 ] invalid pdf created if font name contains space
by noreply＠sarovar.org 13 Apr '06

13 Apr '06

Bugs item #509, was opened at 2006-04-13 20:37 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=509&group_id=106 Category: Fonts Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tom Bishop (tbishop) Assigned to: Hartmut Henkel (hhenkel) Summary: invalid pdf created if font name contains space Initial Comment: pdftex 3.141592-1.30.4-2.2 runs the following code without complaining: \pdfmapline{+mssong4e <mssong.ttf <mssong4e.enc} \font\testfont=mssong4e at 20pt \testfont\char"00 \bye -- but the resulting pdf file can't be opened by Adobe Reader or GhostScript. GhostScript reports "Unknown operator: Song". The pdf file includes "/BaseFont /FEVAQU+MS Song". Evidently, the problem is the space in "MS Song", because if I use a hex editor to replace the space with an underscore, then the pdf becomes OK. The same font worked fine with earlier pdftex versions. It's a Chinese Unicode TrueType font, from Microsoft. I haven't tried installing pdftex 1.30.6; is it possible that would fix the problem? I just re-installed TeX using i-Installer for Mac OS X; it still uses pdftex 1.30.4. Here is the output of pdftex when running the test file: This is pdfeTeX, Version 3.141592-1.30.4-2.2 (Web2C 7.5.5) entering extended mode (./test3.tex [1{/Users/tbishop/Library/texmf/fonts/map/pdftex/ updmap/pdftex.map }] )</usr/local/teTeX/share/texmf.tetex/fonts/type1/bluesky/cm/ cmr10.pfb>{/usr/ local/teTeX/share/texmf.local/fonts/enc/pdftex/enc/mssong4e.enc} </usr/local/teT eX/share/texmf.local/fonts/truetype/mssong.ttf> Output written on test3.pdf (1 page, 5067 bytes). Transcript written on test3.log. Thanks in advance for any help! Best wishes, Tom Bishop (wenlin(a)wenlin.com) ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2006-04-13 22:54 Message: Logged In: YES user_id=929 ah, after the PDF reference 5. ed. page 388 in case there would be no PostScript name entry we could be cruesome and strip the blank. But there is a wrong PostScript name in the font. So maybe one could flag a warning (or not?) and just strip the blank? (which would be easy) Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-04-13 22:39 Message: Logged In: YES user_id=929 This mssong.ttf version seems to be buggy. Here is a diagnostic printout from function ttf_read_name() in writettf.c; these are all available entries from the "Naming Table": i=0 platform_id=1 encoding_id=0 name_id=0 name <(c) Copyright ZHUHAI Stone Computerized typesetting system R&D LTD., 1995-1996> i=1 platform_id=1 encoding_id=0 name_id=1 name <MS Song> i=2 platform_id=1 encoding_id=0 name_id=2 name <Regular> i=3 platform_id=1 encoding_id=0 name_id=3 name <Microsoft:MS Song:1996> i=4 platform_id=1 encoding_id=0 name_id=4 name <MS Song> i=5 platform_id=1 encoding_id=0 name_id=5 name <Version 1.00> i=6 platform_id=1 encoding_id=0 name_id=6 name <MS Song> ---> ttf_read_name <MS Song> There is no usable PostScript name in: The TTF standard tells that under name_id=6 there should be the Postscript font, but here it is "MS Song" with a blank. As long as the font does not contain a valid PostScript name, i have no idea how to tweak this correctly... Other clues anybody? Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=509&group_id=106

1 0

[ pdftex-Bugs-509 ] invalid pdf created if font name contains space
by noreply＠sarovar.org 13 Apr '06

13 Apr '06

Bugs item #509, was opened at 2006-04-13 20:37 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=509&group_id=106 Category: Fonts Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tom Bishop (tbishop) Assigned to: Hartmut Henkel (hhenkel) Summary: invalid pdf created if font name contains space Initial Comment: pdftex 3.141592-1.30.4-2.2 runs the following code without complaining: \pdfmapline{+mssong4e <mssong.ttf <mssong4e.enc} \font\testfont=mssong4e at 20pt \testfont\char"00 \bye -- but the resulting pdf file can't be opened by Adobe Reader or GhostScript. GhostScript reports "Unknown operator: Song". The pdf file includes "/BaseFont /FEVAQU+MS Song". Evidently, the problem is the space in "MS Song", because if I use a hex editor to replace the space with an underscore, then the pdf becomes OK. The same font worked fine with earlier pdftex versions. It's a Chinese Unicode TrueType font, from Microsoft. I haven't tried installing pdftex 1.30.6; is it possible that would fix the problem? I just re-installed TeX using i-Installer for Mac OS X; it still uses pdftex 1.30.4. Here is the output of pdftex when running the test file: This is pdfeTeX, Version 3.141592-1.30.4-2.2 (Web2C 7.5.5) entering extended mode (./test3.tex [1{/Users/tbishop/Library/texmf/fonts/map/pdftex/ updmap/pdftex.map }] )</usr/local/teTeX/share/texmf.tetex/fonts/type1/bluesky/cm/ cmr10.pfb>{/usr/ local/teTeX/share/texmf.local/fonts/enc/pdftex/enc/mssong4e.enc} </usr/local/teT eX/share/texmf.local/fonts/truetype/mssong.ttf> Output written on test3.pdf (1 page, 5067 bytes). Transcript written on test3.log. Thanks in advance for any help! Best wishes, Tom Bishop (wenlin(a)wenlin.com) ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2006-04-13 22:39 Message: Logged In: YES user_id=929 This mssong.ttf version seems to be buggy. Here is a diagnostic printout from function ttf_read_name() in writettf.c; these are all available entries from the "Naming Table": i=0 platform_id=1 encoding_id=0 name_id=0 name <(c) Copyright ZHUHAI Stone Computerized typesetting system R&D LTD., 1995-1996> i=1 platform_id=1 encoding_id=0 name_id=1 name <MS Song> i=2 platform_id=1 encoding_id=0 name_id=2 name <Regular> i=3 platform_id=1 encoding_id=0 name_id=3 name <Microsoft:MS Song:1996> i=4 platform_id=1 encoding_id=0 name_id=4 name <MS Song> i=5 platform_id=1 encoding_id=0 name_id=5 name <Version 1.00> i=6 platform_id=1 encoding_id=0 name_id=6 name <MS Song> ---> ttf_read_name <MS Song> There is no usable PostScript name in: The TTF standard tells that under name_id=6 there should be the Postscript font, but here it is "MS Song" with a blank. As long as the font does not contain a valid PostScript name, i have no idea how to tweak this correctly... Other clues anybody? Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=509&group_id=106

1 0

[ pdftex-Bugs-509 ] invalid pdf created if font name contains space
by noreply＠sarovar.org 13 Apr '06

13 Apr '06

Bugs item #509, was opened at 2006-04-13 11:37 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=509&group_id=106 Category: Fonts Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tom Bishop (tbishop) Assigned to: Hartmut Henkel (hhenkel) Summary: invalid pdf created if font name contains space Initial Comment: pdftex 3.141592-1.30.4-2.2 runs the following code without complaining: \pdfmapline{+mssong4e <mssong.ttf <mssong4e.enc} \font\testfont=mssong4e at 20pt \testfont\char"00 \bye -- but the resulting pdf file can't be opened by Adobe Reader or GhostScript. GhostScript reports "Unknown operator: Song". The pdf file includes "/BaseFont /FEVAQU+MS Song". Evidently, the problem is the space in "MS Song", because if I use a hex editor to replace the space with an underscore, then the pdf becomes OK. The same font worked fine with earlier pdftex versions. It's a Chinese Unicode TrueType font, from Microsoft. I haven't tried installing pdftex 1.30.6; is it possible that would fix the problem? I just re-installed TeX using i-Installer for Mac OS X; it still uses pdftex 1.30.4. Here is the output of pdftex when running the test file: This is pdfeTeX, Version 3.141592-1.30.4-2.2 (Web2C 7.5.5) entering extended mode (./test3.tex [1{/Users/tbishop/Library/texmf/fonts/map/pdftex/ updmap/pdftex.map }] )</usr/local/teTeX/share/texmf.tetex/fonts/type1/bluesky/cm/ cmr10.pfb>{/usr/ local/teTeX/share/texmf.local/fonts/enc/pdftex/enc/mssong4e.enc} </usr/local/teT eX/share/texmf.local/fonts/truetype/mssong.ttf> Output written on test3.pdf (1 page, 5067 bytes). Transcript written on test3.log. Thanks in advance for any help! Best wishes, Tom Bishop (wenlin(a)wenlin.com) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=509&group_id=106

1 0

[ pdftex-Bugs-505 ] file with only \immediate\pdfobj stream results in garbage
by noreply＠sarovar.org 08 Apr '06

08 Apr '06

Bugs item #505, was opened at 2006-04-06 00:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=505&group_id=106 Category: None >Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) Summary: file with only \immediate\pdfobj stream results in garbage Initial Comment: The input \pdfcompresslevel=0 \immediate\pdfobj stream {xx} \end results in the message No pages of output. but produces the garbage pdf attached. Confirmed with 1.30.2 and the last 1.40.0-beta. ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2006-04-08 08:45 Message: Logged In: YES user_id=929 tried 2 approaches: 1) try to make a complete PDF file without pages, like: << /Type /Pages /Count 0 /Kids [] >> Then xpdf shows a white background, but acroread complains. So this can't be done. 2a) silently delete faulty PDF. But one should give at least a warning. 2b) flag warning and delete faulty PDF. That's the current patch for 1.40.0-beta-20060213. Now it says: This is pdfTeXk, Version 3.141592-1.40.0-beta-20060213 (Web2C 7.5.5) (format=pdftex 2006.4.8) 8 APR 2006 07:41 %&-line parsing enabled. **test1 (./test1.tex ) No pages of output. Warning: pdftex: dangling objects discarded, no output file produced. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=505&group_id=106

1 0

[ pdftex-Bugs-505 ] file with only \immediate\pdfobj stream results in garbage
by noreply＠sarovar.org 05 Apr '06

05 Apr '06

Bugs item #505, was opened at 2006-04-06 00:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=505&group_id=106 Category: None Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) Summary: file with only \immediate\pdfobj stream results in garbage Initial Comment: The input \pdfcompresslevel=0 \immediate\pdfobj stream {xx} \end results in the message No pages of output. but produces the garbage pdf attached. Confirmed with 1.30.2 and the last 1.40.0-beta. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=505&group_id=106

1 0

possible bug
by Hans Hagen 05 Apr '06

05 Apr '06

Hi, When I process: \pdfcompresslevel=0 \immediate\pdfobj stream {xx} \end pdftex reports 0 paes bug produces a faulty pdf file that looks like: %PDF-1.5 %ÐÔÅØ 1 0 obj << /Length 2 >> stream xx so, apart from content ending up in a file with no pages, the object is also faulty (no endstream) (version: This is pdfeTeX, Version 3.141592-1.30.3-2.2 (Web2c 7.5.5)) maybe this is already solved Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

3 2

Changing the banner is hardly possible
by Frank Küster 04 Apr '06

04 Apr '06

Hi, I just tried to change the banner for our Debian-specific changes in teTeX's pdftex 1.21a, but that doesn't work well. --- tetex-bin-3.0.orig/texk/web2c/pdfetexdir/pdfetexextra.in 2005-07-20 12:28:21.000000000 +0200 +++ tetex-bin-3.0/texk/web2c/pdfetexdir/pdfetexextra.in 2006-03-24 10:17:29.000000000 +0100 @@ -26,7 +26,7 @@ (generated from ../lib/texmfmp.c). */ -#define BANNER "This is pdfeTeX, Version 3.141592-PDFTEX-VERSION-ETEX-VERSION" +#define BANNER "This is pdfeTeX using libpoppler, Version 3.141592-PDFTEX-VERSION-ETEX-VERSION" #define COPYRIGHT_HOLDER "Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX)" #define AUTHOR NULL #define PROGRAM_HELP PDFETEXHELP leads to the funny output # pdftex --version pdfeTeX using libpoppler 3.141592-1.21a-2.2 (Web2C 7.5.4) kpathsea version 3.5.4 Copyright (C) 1997-2004 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Kpathsea is copyright (C) 1997-2004 Free Software Foundation, Inc. There is NO warranty. Redistribution of this software is covered by the terms of both the pdfeTeX using libpoppler copyright and the GNU General Public License. For more information about these matters, see the files named COPYING and the pdfeTeX using libpoppler source. Primary author of pdfeTeX using libpoppler: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Kpathsea written by Karl Berry and others. Appending something after the version number doesn't seem to work, either. If this is still the same in the 1.40 betas, I'll report a bug... Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)

2 2

[ pdftex-Bugs-498 ] pdftex leaves included files opened thus overflowing the ulimit
by noreply＠sarovar.org 27 Mar '06

27 Mar '06

Bugs item #498, was opened at 2006-03-26 23:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=498&group_id=106 Category: PDF inclusion Group: v1.30.0 Status: Closed Resolution: Works For Me Priority: 3 Submitted By: Vladimir Volovich (vvv) Assigned to: Martin Schröder (oneiros) Summary: pdftex leaves included files opened thus overflowing the ulimit Initial Comment: [re-sending through sarovar bug reporting form] i'm reporting a bug discovered by Tigran Aivazian: He got this message: pdflatex: ./1016.pdf: Too many open files by running pdflatex on this simple source: \documentclass[pdftex,a5paper]{book} \usepackage[papersize={8.5in,11in}]{geometry} \usepackage{pdfpages} \begin{document} \newcount\i \i=2 \loop \ifnum\i<1725 \includepdf[pages={-}]{\number\i.pdf}% \advance\i by1 \repeat \end{document} It appears that this is due to the "ulimit" on the number of simultaneously opened files which was 1024 by default. Increasing "ulimit" allowed to process the file. But it looks like a bug in pdftex: it seems that it keeps all the files which were \includepdf'ed opened, thus causing this limit to be reached. Instead, it seems, it should close the included files. WDYT? ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-03-27 14:51 Message: Logged In: YES user_id=421 Hans, please try it on Windows -- if it doesn't fail there, I'd be surprised. IIRC Fabrice' fix was for the \immediate version which also ran out of filedescriptors some years ago. ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2006-03-27 09:52 Message: Logged In: YES user_id=927 (this problem does not occur on windows; i remember that fabrice looked into it long ago) there is a relationship between open files and using \immediate and/or the page key and/or re-use; using immediate solves the open file problems but may lead to bigger files; i asume that opening a file twice is taken care of since there was a request from choff (tug conference china) with respect to splitting the 'get dimensions' code (also needed for dvi mode) from the inclusion code it may make sense to look into that direction [for instance, provide a primitive to determine the dimensions and then always delay inclusion of the objects] there is also the matter of efficiently embedding fonts in included files (sharing with parent document) so that's another pitfall keeping files open has to do with sharing objects so patching this code in order to overcome the open file limits may turn out to be tricky ---------------------------------------------------------------------- Comment By: Vladimir Volovich (vvv) Date: 2006-03-27 09:39 Message: Logged In: YES user_id=2086 please clarify why non-\immediate \pdfximage is still allowed to leave the included files opened. (i.e. why the current behavior is considered normal, when the files are left opened and the ulimit eventually overflows). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-03-27 02:58 Message: Logged In: YES user_id=421 The "problem" here is that \pdfximage normally is not immediate. If you make it immediate by e.g. inserting \let\mypdfximage\pdfximage \def\pdfximage{\immediate\mypdfximage} everything works fine. So maybe pdfpages should work use an \immediate. We still need to fix the problem with the remaining broken file, but that is another bug. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-03-27 00:43 Message: Logged In: YES user_id=421 I at least found why the resulting file is not deleted (i.e. where pdfTeX actually crashes): The callstack is thus: - pdftex.web:scan_image - writeimg.c:readimage - writeimg.c:checktypebyheader - kpathsea/xfopen.c:xfopen, which calls FATAL_PERROR So we should register our error handler through atexit (3) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=498&group_id=106

1 0

[ pdftex-Bugs-498 ] pdftex leaves included files opened thus overflowing the ulimit
by noreply＠sarovar.org 27 Mar '06

27 Mar '06

Bugs item #498, was opened at 2006-03-26 21:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=498&group_id=106 Category: PDF inclusion Group: v1.30.0 Status: Closed Resolution: Works For Me Priority: 3 Submitted By: Vladimir Volovich (vvv) Assigned to: Martin Schröder (oneiros) Summary: pdftex leaves included files opened thus overflowing the ulimit Initial Comment: [re-sending through sarovar bug reporting form] i'm reporting a bug discovered by Tigran Aivazian: He got this message: pdflatex: ./1016.pdf: Too many open files by running pdflatex on this simple source: \documentclass[pdftex,a5paper]{book} \usepackage[papersize={8.5in,11in}]{geometry} \usepackage{pdfpages} \begin{document} \newcount\i \i=2 \loop \ifnum\i<1725 \includepdf[pages={-}]{\number\i.pdf}% \advance\i by1 \repeat \end{document} It appears that this is due to the "ulimit" on the number of simultaneously opened files which was 1024 by default. Increasing "ulimit" allowed to process the file. But it looks like a bug in pdftex: it seems that it keeps all the files which were \includepdf'ed opened, thus causing this limit to be reached. Instead, it seems, it should close the included files. WDYT? ---------------------------------------------------------------------- >Comment By: Hans Hagen (hagen) Date: 2006-03-27 07:52 Message: Logged In: YES user_id=927 (this problem does not occur on windows; i remember that fabrice looked into it long ago) there is a relationship between open files and using \immediate and/or the page key and/or re-use; using immediate solves the open file problems but may lead to bigger files; i asume that opening a file twice is taken care of since there was a request from choff (tug conference china) with respect to splitting the 'get dimensions' code (also needed for dvi mode) from the inclusion code it may make sense to look into that direction [for instance, provide a primitive to determine the dimensions and then always delay inclusion of the objects] there is also the matter of efficiently embedding fonts in included files (sharing with parent document) so that's another pitfall keeping files open has to do with sharing objects so patching this code in order to overcome the open file limits may turn out to be tricky ---------------------------------------------------------------------- Comment By: Vladimir Volovich (vvv) Date: 2006-03-27 07:39 Message: Logged In: YES user_id=2086 please clarify why non-\immediate \pdfximage is still allowed to leave the included files opened. (i.e. why the current behavior is considered normal, when the files are left opened and the ulimit eventually overflows). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-03-27 00:58 Message: Logged In: YES user_id=421 The "problem" here is that \pdfximage normally is not immediate. If you make it immediate by e.g. inserting \let\mypdfximage\pdfximage \def\pdfximage{\immediate\mypdfximage} everything works fine. So maybe pdfpages should work use an \immediate. We still need to fix the problem with the remaining broken file, but that is another bug. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-03-26 22:43 Message: Logged In: YES user_id=421 I at least found why the resulting file is not deleted (i.e. where pdfTeX actually crashes): The callstack is thus: - pdftex.web:scan_image - writeimg.c:readimage - writeimg.c:checktypebyheader - kpathsea/xfopen.c:xfopen, which calls FATAL_PERROR So we should register our error handler through atexit (3) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=498&group_id=106

1 0