- ntg-pdftex - NTG Mailing Lists

outpu tfile in pdftex
by Hans Hagen 06 Jul '04

06 Jul '04

Hi, Since we're in 'making pdftex robust' mode ... when the pdf file cannot be written, pdftex asks for a filename; is it possible to replace en empty name (one hits return after closing the file in acroread for instance) by the 'normal' one? Now er can get funny names like .pdf and such; so: while invalidfile asknameonconsole useoriginalname if emptyname end 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 -----------------------------------------------------------------

4 3

Re: pdftex status
by Martin Schröder 06 Jul '04

06 Jul '04

On 2004-07-05 19:44:22 -0400, Karl Berry wrote: > I guess it's time to ask again how pdftex is doing, since Olaf is > apparently winding down web2c ... any info appreciated :). Karl, we are also closing down 1.20a; I expect a release this week. Best regards Martin -- Martin Schröder, ms(a)artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de

1 0

\escapes and /Limits
by karl＠freefriends.org 03 Jul '04

03 Jul '04

I posted a complex bug report to pdftex(a)tug.org. Hartmut posted a change to tex.ch2 which partially fixes it, and suggested we move discussion to this list. So ... http://tug.org/pipermail/pdftex/2004-July/005138.html http://tug.org/pipermail/pdftex/2004-July/005139.html http://tug.org/pipermail/pdftex/2004-July/005140.html Thanks, karl

1 0

[ pdftex-Feature Requests-87 ] In case of fatal errors, delete the output file
by noreply＠sarovar.org 02 Jul '04

02 Jul '04

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: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Nobody (None) 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: 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-Feature Requests-87 ] In case of fatal errors, delete the output file
by noreply＠sarovar.org 02 Jul '04

02 Jul '04

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: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Nobody (None) 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: 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-Feature Requests-87 ] In case of fatal errors, delete the output file
by noreply＠sarovar.org 02 Jul '04

02 Jul '04

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: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Nobody (None) 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: 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-Feature Requests-87 ] In case of fatal errors, delete the output file
by noreply＠sarovar.org 02 Jul '04

02 Jul '04

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: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Nobody (None) 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. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=87&group_id=106

1 0

problem with hz in rc4
by The Thanh Han 30 Jun '04

30 Jun '04

Hi, Hans Hagen and Ulrich Dirr are experiencing some serious problem with hz in the latest version (rc4), but so far I am not able to reproduce them. Just want to let everybody aware of this problem. We are working on it. Thanh

3 2

strange split of tokens
by Hans Hagen 08 Jun '04

08 Jun '04

Hi The attached file shows some strange split of tokens in the pdf output: /F1 11.9552 Tf 280.537 760.6529 Td[(1)]TJ -209.67 -58.2684 Td[(test)-326(red)-327(r)1(e)-1(d)]TJ 0 -14.4126 Td[(test)-326(red)-653(red)]TJ watch how red is split once into r e d -- 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 3

Re: bad pk file, expected pre?
by Martin Schröder 07 Jun '04

07 Jun '04

On 2004-06-06 00:06:40 +0200, Karl Berry wrote: > My map file was temporarily set to use CM pk fonts, and the current > pdftex complained about the PK files checked in to p4: > > [1{/home/karl/tmp/inst/texmf-var/fonts/map/pdftex/updmap/pdftex.map}] > ) </home/karl/tmp/inst/texmf-dist/fonts/pk/ljfour/public/cm/dpi600/cmr10.pk > Error: pdftex (file cmr10): bad pk file, expected pre > ==> Fatal error occurred, the output PDF file is not finished! > > Does this make sense to you? pktype is happy with that cmr10.pk as far > as I can see. I generated a new PK file for another random font > (teng10), and pdftex was happy with that one. Karl, please test again with the current developement sources (rc4). Best regards Martin -- Martin Schröder, ms(a)artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de

1 0