- ntg-pdftex - NTG Mailing Lists

Re: [NTG-pdftex] Re: pdftex: unrecognized option `-output-format=pdf'
by Akira Kakuto 14 Jul '04

14 Jul '04

> in texmfmp.c, just add the three marked lines: > > #endif /* MP */ > + #if defined(pdfTeX) || defined(pdfeTeX) || defined(pdfxTeX) > + { "output-format", 1, 0, 0 }, > + #endif /* pdfTeX or pdfeTeX or pdfxTeX */ > { 0, 0, 0, 0 } }; > > It overruns the initex setting, but it can be overrun by \pdfoutput (not > the other way around, as it may be practical for such an option?). I'm sorry I did not notice that --output-format was thrown out of getopt option list. I think the option is useful in some cases. I hope that the above three lines are revived. Best regards Akira

1 0

pdftex: unrecognized option `-output-format=pdf'
by Hartmut Henkel 14 Jul '04

14 Jul '04

Option -output-format is part of the -help menu, but it seems not to work in rc4/teTeX 2.96.5 (error before even the substring "dvi" or "pdf" is checked); it's at least missing from the getopt option list. Should it be pulled in or thrown out? Regards, Hartmut

1 1

[ pdftex-Patches-91 ] \tagcode patch
by noreply＠sarovar.org 13 Jul '04

13 Jul '04

Patches item #91, was opened at 2004-07-13 10:58 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=91&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Martin Schröder (oneiros) Assigned to: The Thanh Han (hanthethanh) Summary: \tagcode patch Initial Comment: Patch from Taco Hoekwater for an extra primitive named \tagcode, allowing read and write access to a character's char_tag info. The associated internal command is assign_font_int, with the new modifier value tag_code. More info at http://www.metatex.org/web/tagcode.html ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=91&group_id=106

1 0

\tagcode patch
by Taco Hoekwater 13 Jul '04

13 Jul '04

Hi all, I have created a small patch file that I expect some of us will consider useful: It allows the querying and removal of ligature/kerning/charlist information from within the TeX macro language. See: http://www.metatex.org/web/tagcode.html for more information -- groeten, Taco

1 0

Re: [NTG-pdftex] pdftex -output-comment=STRING
by Akira Kakuto 12 Jul '04

12 Jul '04

> pdftex --help gives > > -output-comment=STRING use STRING for PDF file comment instead of date > > but the manpage says that "In DVI mode, use string for the DVI file > comment instead of the date. This option is ignored in PDF mode." > > And i couldn't find any trace of STRING in the PDF file, but it's in the > DVI file. So it seems this would be more correct: > > -output-comment=STRING use STRING for DVI file comment instead of date I send an example patch: Best regards Akira ------------------------------------------------ --- texmfmp-help.h.orig Mon Jun 07 19:39:40 2004 +++ texmfmp-help.h Sun May 09 12:53:26 2004 @@ -31,7 +31,7 @@ " most commonly `aleph'.", "", " Alternatively, if the first non-option argument begins with a backslash,", - " interpret all non-option arguments as a line of e-Omega input.", + " interpret all non-option arguments as a line of Aleph input.", "", " Alternatively, if the first non-option argument begins with a &, the", " next word is taken as the FMT to read, overriding all else. Any", @@ -360,7 +360,9 @@ " the bits of NUMBER", "[-no]-mktex=FMT disable/enable mktexFMT generation (FMT=tex/tfm)", "-mltex enable MLTeX extensions such as \\charsubdef", - "-output-comment=STRING use STRING for PDF file comment instead of date", + "-output-comment=STRING use STRING for DVI file comment instead of date", + " in the case of DVI output (no effect for PDF)", + "-output-format=FORMAT use FORMAT for job output; FORMAT is `dvi' or `pdf'", "[-no]-parse-first-line disable/enable parsing of the first line of the", " input file", "-progname=STRING set program (and fmt) name to STRING", @@ -416,7 +418,9 @@ " the bits of NUMBER", "[-no]-mktex=FMT disable/enable mktexFMT generation (FMT=tex/tfm)", "-mltex enable MLTeX extensions such as \\charsubdef", - "-output-comment=STRING use STRING for PDF file comment instead of date", + "-output-comment=STRING use STRING for DVI file comment instead of date", + " in the case of DVI output (no effect for PDF)", + "-output-format=FORMAT use FORMAT for job output; FORMAT is `dvi' or `pdf'", "[-no]-parse-first-line disable/enable parsing of the first line of the", " input file", "-progname=STRING set program (and fmt) name to STRING", @@ -443,10 +447,10 @@ " Any remaining COMMANDS are processed as pdfxTeX input, after TEXNAME is read.", " If the first line of TEXNAME is %&FMT, and FMT is an existing .fmt file,", " use it. Else use `NAME.fmt', where NAME is the program invocation name,", - " most commonly `pdfetex'.", + " most commonly `pdfxtex'.", "", " Alternatively, if the first non-option argument begins with a backslash,", - " interpret all non-option arguments as a line of pdfeTeX input.", + " interpret all non-option arguments as a line of pdfxTeX input.", "", " Alternatively, if the first non-option argument begins with a &, the", " next word is taken as the FMT to read, overriding all else. Any", @@ -472,7 +476,9 @@ " the bits of NUMBER", "[-no]-mktex=FMT disable/enable mktexFMT generation (FMT=tex/tfm)", "-mltex enable MLTeX extensions such as \\charsubdef", - "-output-comment=STRING use STRING for PDF file comment instead of date", + "-output-comment=STRING use STRING for DVI file comment instead of date", + " in the case of DVI output (no effect for PDF)", + "-output-format=FORMAT use FORMAT for job output; FORMAT is `dvi' or `pdf'", "[-no]-parse-first-line disable/enable parsing of the first line of the", " input file", "-progname=STRING set program (and fmt) name to STRING",

2 1

Re: backslashes in \pdfoutline
by Martin Schröder 11 Jul '04

11 Jul '04

On 2004-07-10 20:39:06 -0400, Karl Berry wrote: > Hi Martin, > > As you may have noticed, I reported an issue on the pdftex lists a few > days ago regarding catcode 12 backslashes in \pdfoutline et al. > Although Hartmut and Heiko and I have discussed it some, and Hartmut has > written some patches, I haven't seen any definitive decisions on what we > want to do, and I want to fix texinfo.tex accordingly. > > (It comes up in practice with Texinfo because in Texinfo, unlike most > (all?) other common formats, backslash is supposed to be a "normal" > character that can be used in cross-reference targets.) > > In short, suppose we have: > > \catcode`\/=0 /catcode`\\=12 > /pdfcompresslevel=0 > /pdfdest name {xyz\} hello from xyz /vfill/eject > /pdfoutline goto name{xyz\}{to xyz\} > > This produces an invalid PDF file, because the \ escapes the > end-of-string ) delimiter in the output: > > << /S /GoTo /D (xyz\) >> > ... > (to xyz\) > > The choices seem to be: > > 1) do nothing, and leave it up to the document's TeX code to double the > backslashes in all cases. This is the current situation, de facto. > > 2) have pdftex escape the backslashes in the target names only, so that > it would produce (xyz\\) and (to xyz\). > > 3) have pdftex escape the backslashes in the outline text only, so that > it would produce (xyz\) and (to xyz\\). > > 4) have pdftex escape the backslashes in all situations, so that > it would produce (xyz\\) and (to xyz\\). Karl, 4 would be the logical choice for pdf. > Escaping the backslashes implies that TeX code cannot produce PDF string > escapes. This does not seem like a serious limitation to me, since TeX > can write any byte value (and pdftex "should" escape as necessary into > \nnn octal notation in string constants -- I have not tested this). I will. > Not escaping the backslashes implies that it's possible to write TeX > documents which produce invalid PDF. This seems bad, however, if this > is the case with other pdftex commands also, the argument loses its force. We'll have to check this for consistency. Best regards Martin PS: I'm cc'ing the ntg-pdftex list so that Hans and Thanh and others are included. -- 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

pdftex -output-comment=STRING
by Hartmut Henkel 11 Jul '04

11 Jul '04

pdftex --help gives -output-comment=STRING use STRING for PDF file comment instead of date but the manpage says that "In DVI mode, use string for the DVI file comment instead of the date. This option is ignored in PDF mode." And i couldn't find any trace of STRING in the PDF file, but it's in the DVI file. So it seems this would be more correct: -output-comment=STRING use STRING for DVI file comment instead of date Regards, Hartmut

1 0

PNG image embedding
by Hartmut Henkel 08 Jul '04

08 Jul '04

There is a small q+d patch on my homepage at http://www.circuitwizard.de/pdftex/patch5/index.html which tries to embed PNG files natively, without the usual slow decompressing + compressing steps done by pdftex---only if the PNG image type allows that. This usually results in a smaller overall PDF file size, as the original line-by-line predictor type informations from the PNG image are carried over into the PDF file. And the PNG embedding is speedier. Best Regards, Hartmut P.S. The newest libtiff comes with a tiff2pdf program. Quite handy.

4 3

[ pdftex-Feature Requests-89 ] Handle missing pages in included pdfs better
by noreply＠sarovar.org 08 Jul '04

08 Jul '04

Feature Requests item #89, was opened at 2004-07-08 14:38 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=89&group_id=106 Category: None Group: v1.21 Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Nobody (None) Summary: Handle missing pages in included pdfs better Initial Comment: Currently, when one tries to include page 10 of a 9 page document, pdftex quits. Proposed change: Behaviour of pdfTeX for pdf image inclusion: UNKNOWN := -1 Initialization: \pdflastximagepages := UNKNOWN Continue := Continue with empty xform object with dimension 1bp x 1bp. // 1bp because it avoids zero and possible problems and // the output is small (/BBox [0 0 1 1]) if PDFFileExists if PageNumber < 1 \pdflastximagepages = UNKNOWN Warning "Invalid page number" Continue elsif PageNumber > \pdflastximagepages \pdflastximagepages is set Warning "Page number to large (out of range) Continue else \pdflastximagepages is set image is included fi else Warning "PDF file does not exist" \pdflastximagepages = UNKNOWN Continue fi Failure/Success checking: if [page] < 1 * Page number too small elsif \pdflastximagepages = -1 * PDF file does not exist elsif [page] > \pdflastximagepages * Page number too large else * Success fi or with optimization for success: if [page] < 1 * Page number too small elsif [page] > \pdflastximagepages if \pdflastximagepages = -1 * PDF file does not exist else * Page number too large fi else * Success fi ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=89&group_id=106

1 0

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

08 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: v1.21 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-Bugs-88 ] \pdforigin=0pt shifts output on 1in
by noreply＠sarovar.org 08 Jul '04

08 Jul '04

Bugs item #88, was opened at 2004-07-06 16:55 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=88&group_id=106 Category: None Group: v1.20a >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: The Thanh Han (hanthethanh) Summary: \pdforigin=0pt shifts output on 1in Initial Comment: In the attached file foo1.tex the output starts at (1in/1in), although it should start at (0pt/0pt). The output of foo2.tex starts at (1pt/1pt) as expected. Tested with the latest teTeX-beta. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2004-07-08 11:50 Message: Logged In: YES user_id=421 #5452 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=88&group_id=106

1 0

\pdfhorigin / \pdfvorigin broken?
by Thomas Esser 07 Jul '04

07 Jul '04

I wonder if there is some automatic translation from 0pt to 1in somewhere... The following \pdfhorigin=0pt \pdfvorigin=0pt \pdfximage page 1 {foo.pdf}% \setbox0=\hbox{\pdfrefximage\pdflastximage}% \pdfpagewidth=\wd0 \pdfpageheight=\ht0 \shipout\box0 \bye gives a shifted output of foo.pdf (by 1in), while \pdfhorigin=1pt \pdfvorigin=1pt \pdfximage page 1 {foo.pdf}% \setbox0=\hbox{\pdfrefximage\pdflastximage}% \pdfpagewidth=\wd0 \pdfpageheight=\ht0 \shipout\box0 \bye gives only a shift by 1pt (as specified)- Something to fix for 1.20 hopefully... Thomas

3 9

empty \special
by Rolf Niepraschk 07 Jul '04

07 Jul '04

Processing a TeX document with \special{} inside the pdfTeX compiler writes the warning Non-PDF special ignored! My suggestion: Let an empty \special to be a valid PDF special. ...Rolf -- || Rolf Niepraschk c/o Physikalisch-Technische Bundesanstalt || || Abbestr. 2-12; D-10587 Berlin, Germany || || Tel/Fax: ++49-30-3481-316/490, email: Rolf.Niepraschk(a)ptb.de ||

2 1

[ pdftex-Bugs-88 ] \pdforigin=0pt shifts output on 1in
by noreply＠sarovar.org 06 Jul '04

06 Jul '04

Bugs item #88, was opened at 2004-07-06 16:55 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=88&group_id=106 Category: None Group: v1.20a Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: The Thanh Han (hanthethanh) Summary: \pdforigin=0pt shifts output on 1in Initial Comment: In the attached file foo1.tex the output starts at (1in/1in), although it should start at (0pt/0pt). The output of foo2.tex starts at (1pt/1pt) as expected. Tested with the latest teTeX-beta. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=88&group_id=106

1 0

pdfannot in xform
by Hans Hagen 06 Jul '04

06 Jul '04

Hi, Something to keep an eye on: pdftex bombs when an pdfannot happens inside an xform (still playing with that, so no pattern yet) 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 -----------------------------------------------------------------

6 24

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