- ntg-pdftex - NTG Mailing Lists

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

06 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 06 Apr '06

06 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

[ 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-27 01: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: Vladimir Volovich (vvv) Date: 2006-03-27 11: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 04: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 02: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-Feature Requests-87 ] In case of fatal errors, delete the output file
by noreply＠sarovar.org 27 Mar '06

27 Mar '06

Feature Requests item #87, was opened at 2004-07-02 11:13 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=87&group_id=106 Category: None Group: v1.21 Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Martin Schröder (oneiros) Summary: In case of fatal errors, delete the output file Initial Comment: When pdfTeX currently encounters a fatal error, it closes it's output file, which leads to incomplete/corrupt files. pdfTeX should produce only valid files, and in case of fatal errors the output should be deleted. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-03-27 03:00 Message: Logged In: YES user_id=421 Currently we only handle exits through pdf_fail. But we also need to trap other exits; this must be done through atexit(3). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-12-19 00:38 Message: Logged In: YES user_id=421 The attached patch unlinks the current file, if a fatal error happens. Currently this is done without any checks, and may be a security problem. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2004-07-02 14:35 Message: Logged In: YES user_id=1608 When you truncate a file, the result is an empty file. From a user's viewpoint, that is not the same thing as a corrupt PDF. The distinction is small, but the advantage of an empty file is that it is not likely to be confused for a correct PDF. If it is possible, then deleting the PDF file is definately better, but file deletion doesn't always work. Truncation almost always does work, and it's only two syscalls extra, so why not? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-07-02 14:21 Message: Logged In: YES user_id=421 Simply truncating a pdf still makes it invalid (because the file structure is incomplete). Producing a valid truncated output file in case of fatal errors will be tricky and not always possible. Deleting the corrupt output is much easier. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2004-07-02 13:50 Message: Logged In: YES user_id=1608 If deleting the file doesnt work, truncation is probably still better than nothing. (?) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=87&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 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 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 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: Open >Resolution: Accepted >Priority: 7 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 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-27 01:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=498&group_id=106 Category: PDF inclusion Group: None Status: Open Resolution: None Priority: 5 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? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=498&group_id=106

1 0