- ntg-pdftex - NTG Mailing Lists

[pdftex-Bugs][4293] error on build: C compiler cannot create executables
by pdftex-bugs＠sarovar.org 01 Sep '09

01 Sep '09

Bugs item #4293, was opened at 2009-09-01 12:51 Status: Open Priority: 3 Submitted By: Pedrocelli . (pedrocelli) Assigned to: Nobody (None) Summary: error on build: C compiler cannot create executables Category: Build process Group: None Resolution: None Initial Comment: Build of pdfLaTex version 1.40.9 attempted on Red Hat Linux 2.6.18, and failed with the above message. Log file config.log attached. What do I need to do to build this? Cheers Pedrocelli ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4293&group_id=106

1 0

[pdftex-Bugs][4292] \rightmarginkern doesn't work for last lines
by pdftex-bugs＠sarovar.org 22 Jul '09

22 Jul '09

Bugs item #4292, was opened at 2009-06-27 21:11 Status: Open Priority: 3 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: \rightmarginkern doesn't work for last lines Category: hz Group: None Resolution: Accepted Initial Comment: % Protrusion works fine even for the last line of a paragraph. % If, however, you ask \rightmarginkern, it will always report % zero margin kerning. \pdfprotrudechars2 \rpcode\font`\. 200 \parindent0pt \parfillskip=0pt \hsize50pt \tracingoutput1 \showboxbreadth\maxdimen \showboxdepth\maxdimen correct: \setbox0\vbox{AAA AAA. AAA AAA.} \unvcopy0 wrong: \newbox\splitbox \newdimen\rmarg \loop\ifvbox0 \setbox\splitbox\vsplit0 to\baselineskip \unvbox\splitbox\setbox\splitbox=\lastbox \rmarg\rightmarginkern\splitbox \unhbox\splitbox\kern\rmarg\rlap{ : \the\rmarg} \repeat \bye ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-07-22 10:49 Message: here is a patch for pdftex stable. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-06-30 09:26 Message: yes I confirm this is a bug that should be fixed. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4292&group_id=106

1 0

[pdftex-Feature Requests][743] Fake beginning/end of line for protrusion
by pdftex-featurerequests＠sarovar.org 22 Jul '09

22 Jul '09

Feature Requests item #743, was opened at 2007-03-06 02:20 Status: Open Priority: 3 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: Fake beginning/end of line for protrusion Category: HZ Group: v1.50 Resolution: Accepted Initial Comment: Although the situation with missing protrusion has certainly improved, there are still a lot of cases where characters will not be protruded (e.g. with indented paragraphs, at the beginning of list items, or of table cells). So I think it would be useful to have some commands that make pdftex believe that it is at the beginning or end of a line (e.g. \protchar{left,right}). So that you could for instance say: \item\protcharleft ``... Difficult? ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-07-22 09:14 Message: here is a patch for pdftex stable. Test file: \font\f=cmr10 \lpcode\f`\A=500 \f \hbox{ABC} \hbox{DEF} \setbox0=\hbox{\pdfprotcharleft ABC} \showbox0 \box0 \bye ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2009-06-27 21:14 Message: Any news with this feature request? ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-07 09:52 Message: Logged In: YES user_id=710 yes inserting a whatsit node that would be changed to a kern seems the easiest way. I will give a try soon. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-03-06 17:21 Message: Logged In: YES user_id=2217 Maybe new (whatsit) nodes that can be caught in find_protchar_left/right? microtype is quite good in translating characters into slots (\MT@get@slot), but not really good enough to always allow natural input, e.g., ligatures and things like "` (German babel) won't be recognised. So my current workaround is: \def\protcharleft#1{% {\everypar{}% \setbox0\vbox{\noindent#1}% \vbadness=10000 \splittopskip=0pt \global\setbox0=\vsplit0 to \baselineskip \unvbox0 \global\setbox0=\lastbox}% \ifhbox0 \leavevmode \kern\leftmarginkern0 \fi #1} But this doesn't always work, e.g. in tabulars. Ligatures and other stuff still have to be enclosed in braces. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-03-06 08:00 Message: Logged In: YES user_id=1608 I will be experimenting with Aleph's \localleftbox somewhere next month, that may be a starting point. But it is unlikely that any command based on that will be able to influence line breaking. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-06 07:52 Message: Logged In: YES user_id=710 yes it makes sense. I am not sure whether \protcharleft could be implemented as macro: one can fetch the next char, get the lpcode and do a corresponding kern. However I don't know how to convert a character to its charcode to fetch the relevant lpcode. Another problem is that if the next char is part of a ligature (as in your example), it doesn't work. Looks like a primitive is needed. Does anyone have a suggestion how it could be implemented? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=743&group_id=106

1 0

Re: [NTG-pdftex] processing speed
by Reinhard Kotucha 03 Jul '09

03 Jul '09

On 1 July 2009 Jérome Laurens wrote: > Hahn found a bug in synctex, I fixed it and made the tests with the > stable branch of pdftex Hi Jérome, of course, if there had been a bug in synctex, it's good that it is fixed now. However, I doubt that synctex was responsible for the problem I reported. There must still be another problem. Isn't synctex very new technology? I could reproduce the problem with older versions of TeX Live. Please try: http://tug.org/~kotucha/testpgfplots.tex.gz I suppose that it's a better test file than the one I prepared first. What I've found out so far is that 1. the problem is not new, 2. luatex has the same problem, 3. the string pool is growing. Because I don't know what exactly causes the problem, I can't even provide a minimal test file. "Unfortunately" pgfplots depends on e-TeX and I don't have a "Knuth's TeX + e-TeX" binary. Maybe there exists something like this in older TL releases. Maybe even Knuth's TeX has this problem, but I don't know to prove it. Hans and Taco said that the string pool is the culprit. Yes, after adding some tiny things to the .tex file, I had to create a new format file with an increased string pool in order to get PDF files at all. It's definitely the string pool which causes trouble. I don't know anything about TeX's innards but the name "string pool" implies that it contains human readable stuff. If this is true, isn't it possible to convince TeX to dump the string pool to a file or to standard output, for instance, whenever a page is shipped out? This probably helps to find out what's going on. Anyway, please try http://tug.org/~kotucha/testpgfplots.tex.gz instead of mktestfiles.gz. Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------

3 5

Re: [NTG-pdftex] processing speed
by The Thanh Han 03 Jul '09

03 Jul '09

On Wed, Jul 01, 2009 at 04:01:02PM +0200, Jerome Laurens wrote: > Hi there, > > Hahn found a bug in synctex, I fixed it and made the tests with the > stable branch of pdftex > > [...] > > That makes 74 files processed at 4.75 sec/file > > [...] > > That makes 63 files processed at 5.3 sec/file > > If that's OK I'll send the diff file please do post the diff file. thanks, Thanh

1 0

[pdftex] New document - tcuythga
by noreply＠sarovar.org 02 Jul '09

02 Jul '09

Project: pdftex Group: Document title: tcuythga Document description: twhtKaPLeSBTjmu Submitter: Nobody (None) ------------------------------------------------------- For more info, visit: http://sarovar.org/docman/index.php?group_id=106

1 0

[pdftex-Bugs][4290] processing speed: pdftex slows down when processes long files in DVI mode
by pdftex-bugs＠sarovar.org 01 Jul '09

01 Jul '09

Bugs item #4290, was opened at 2009-06-26 17:55 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: processing speed: pdftex slows down when processes long files in DVI mode Category: None Group: None Resolution: None Initial Comment: see http://www.ntg.nl/pipermail/ntg-pdftex/2009-May/003786.html ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-07-01 19:46 Message: with the help from Taco and Hartmut, the problem has been traced down to this: section 816 from tex the program says: ,-------- | This code assumes that a |glue_node| and a |penalty_node| occupy the | same number of |mem|~words. | @^data structure assumptions@> | | @<Get ready to start...@>= | link(temp_head):=link(head); | if is_char_node(tail) then tail_append(new_penalty(inf_penalty)) | else if type(tail)<>glue_node then tail_append(new_penalty(inf_penalty)) | else begin type(tail):=penalty_node; delete_glue_ref(glue_ptr(tail)); | flush_node_list(leader_ptr(tail)); penalty(tail):=inf_penalty; | end; `-------- and synctex has changed glue_node_size to 4, so that when a paragraph is processed, there is one node that was located with size=4 but freed with size=2. Therefore the problem is only visible with very long document like Reinhard's test file. Taco's suggestion for the problem: > I strongly suggest you just change the penalty size to 4, because > the other possibilities that I see have much more impact. Starting > from the head node each time is quite slow (much slower than the > speed penalty incurred by the extra size of the penalty node). > > There are other options, but increasing the penalty size is simplest > by far. And it is not like a typical paragraph has hundreds of > penalties, anyway. > > In luatex this worked out reasonably well in the end because in > luatex the node list is doubly linked. But in pdftex there is no > room for an extra back pointer in the node objects (nor is there > in either tex or xetex) so that won't work without a lot of work. and my response: ,-------- | yes this seems a good option. There is still one catch that | pdftex without synctex still has glue_node_size=2 and | doesn't need this change. Therefore this should better be | done by synctex. `-------- I have sent an email asking synctex's author for this change. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4290&group_id=106

1 0

[pdftex-Bugs][4292] \rightmarginkern doesn't work for last lines
by pdftex-bugs＠sarovar.org 30 Jun '09

30 Jun '09

Bugs item #4292, was opened at 2009-06-27 21:11 Status: Open Priority: 3 Submitted By: Robert (schlcht) >Assigned to: The Thanh Han (hanthethanh) Summary: \rightmarginkern doesn't work for last lines Category: hz Group: None >Resolution: Accepted Initial Comment: % Protrusion works fine even for the last line of a paragraph. % If, however, you ask \rightmarginkern, it will always report % zero margin kerning. \pdfprotrudechars2 \rpcode\font`\. 200 \parindent0pt \parfillskip=0pt \hsize50pt \tracingoutput1 \showboxbreadth\maxdimen \showboxdepth\maxdimen correct: \setbox0\vbox{AAA AAA. AAA AAA.} \unvcopy0 wrong: \newbox\splitbox \newdimen\rmarg \loop\ifvbox0 \setbox\splitbox\vsplit0 to\baselineskip \unvbox\splitbox\setbox\splitbox=\lastbox \rmarg\rightmarginkern\splitbox \unhbox\splitbox\kern\rmarg\rlap{ : \the\rmarg} \repeat \bye ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-06-30 09:26 Message: yes I confirm this is a bug that should be fixed. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4292&group_id=106

1 0

[pdftex-Feature Requests][743] Fake beginning/end of line for protrusion
by pdftex-featurerequests＠sarovar.org 27 Jun '09

27 Jun '09

Feature Requests item #743, was opened at 2007-03-06 02:20 Status: Open Priority: 3 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: Fake beginning/end of line for protrusion Category: HZ Group: v1.50 Resolution: Accepted Initial Comment: Although the situation with missing protrusion has certainly improved, there are still a lot of cases where characters will not be protruded (e.g. with indented paragraphs, at the beginning of list items, or of table cells). So I think it would be useful to have some commands that make pdftex believe that it is at the beginning or end of a line (e.g. \protchar{left,right}). So that you could for instance say: \item\protcharleft ``... Difficult? ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2009-06-27 21:14 Message: Any news with this feature request? ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-07 09:52 Message: Logged In: YES user_id=710 yes inserting a whatsit node that would be changed to a kern seems the easiest way. I will give a try soon. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-03-06 17:21 Message: Logged In: YES user_id=2217 Maybe new (whatsit) nodes that can be caught in find_protchar_left/right? microtype is quite good in translating characters into slots (\MT@get@slot), but not really good enough to always allow natural input, e.g., ligatures and things like "` (German babel) won't be recognised. So my current workaround is: \def\protcharleft#1{% {\everypar{}% \setbox0\vbox{\noindent#1}% \vbadness=10000 \splittopskip=0pt \global\setbox0=\vsplit0 to \baselineskip \unvbox0 \global\setbox0=\lastbox}% \ifhbox0 \leavevmode \kern\leftmarginkern0 \fi #1} But this doesn't always work, e.g. in tabulars. Ligatures and other stuff still have to be enclosed in braces. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-03-06 08:00 Message: Logged In: YES user_id=1608 I will be experimenting with Aleph's \localleftbox somewhere next month, that may be a starting point. But it is unlikely that any command based on that will be able to influence line breaking. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-06 07:52 Message: Logged In: YES user_id=710 yes it makes sense. I am not sure whether \protcharleft could be implemented as macro: one can fetch the next char, get the lpcode and do a corresponding kern. However I don't know how to convert a character to its charcode to fetch the relevant lpcode. Another problem is that if the next char is part of a ligature (as in your example), it doesn't work. Looks like a primitive is needed. Does anyone have a suggestion how it could be implemented? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=743&group_id=106

1 0

[pdftex-Bugs][4292] \rightmarginkern doesn't work for last lines
by pdftex-bugs＠sarovar.org 27 Jun '09

27 Jun '09

Bugs item #4292, was opened at 2009-06-27 21:11 Status: Open Priority: 3 Submitted By: Robert (schlcht) Assigned to: Nobody (None) Summary: \rightmarginkern doesn't work for last lines Category: hz Group: None Resolution: None Initial Comment: % Protrusion works fine even for the last line of a paragraph. % If, however, you ask \rightmarginkern, it will always report % zero margin kerning. \pdfprotrudechars2 \rpcode\font`\. 200 \parindent0pt \parfillskip=0pt \hsize50pt \tracingoutput1 \showboxbreadth\maxdimen \showboxdepth\maxdimen correct: \setbox0\vbox{AAA AAA. AAA AAA.} \unvcopy0 wrong: \newbox\splitbox \newdimen\rmarg \loop\ifvbox0 \setbox\splitbox\vsplit0 to\baselineskip \unvbox\splitbox\setbox\splitbox=\lastbox \rmarg\rightmarginkern\splitbox \unhbox\splitbox\kern\rmarg\rlap{ : \the\rmarg} \repeat \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4292&group_id=106

1 0

[pdftex-Bugs][4291] \pdfgentounicode conflicts with cmap+\pdffontattr
by pdftex-bugs＠sarovar.org 27 Jun '09

27 Jun '09

Bugs item #4291, was opened at 2009-06-26 22:37 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: \pdfgentounicode conflicts with cmap+\pdffontattr Category: None Group: None Resolution: None Initial Comment: from https://www.tug.org/pipermail/tex-live/2007-October/014986.html > I think there are unsolved issues. Now there are two methods > for adding CMaps: > (a) \pdffontattr, package cmap > (b) \pdfgentounicode, glyphtounicode.tex > > Both methods have its limitations, e.g. (b) only works for Type 1 > fonts. Thus you could need both methods to cover all fonts, but the > methods doesn't know each other, thus fonts can end up with two CMap > tables. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4291&group_id=106

1 0

[pdftex-Bugs][4290] processing speed: pdftex slows down when processes long files in DVI mode
by pdftex-bugs＠sarovar.org 26 Jun '09

26 Jun '09

Bugs item #4290, was opened at 2009-06-26 17:55 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: processing speed: pdftex slows down when processes long files in DVI mode Category: None Group: None Resolution: None Initial Comment: see http://www.ntg.nl/pipermail/ntg-pdftex/2009-May/003786.html ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4290&group_id=106

1 0

Re: [NTG-pdftex] Bug#532074: texlive-base-bin: 'man pdftex': missing .ds WB
by Frank Küster 14 Jun '09

14 Jun '09

Dear pdftex developers, Török Edwin <edwintorok(a)gmail.com> wrote: > 'man pdftex' shows at the bottom: > "that generated by the to C system (web2c), originally written by" > > There is a missing word after 'the': 'Web', the manpage source has: > 'by the \*(WB to'. But there is no .ds WB at the top of the manpage. > > The fix would be to copy the definition of WB from another manpage, for example > pltotf: > .if n .ds WB Web > .if t .ds WB W\s-2EB\s0 In current TeXLive svn, the patch would be the following. Index: pdftex.man =================================================================== --- pdftex.man (revision 13610) +++ pdftex.man (working copy) @@ -19,6 +19,8 @@ .if n .ds AX AmSTeX .if t .ds AY \fRA\\h'-0.1667m'\\v'0.20v'M\\v'-0.20v'\\h'-0.125m'S\fP\*(LX .if n .ds AY AmSLaTeX +.if n .ds WB Web +.if t .ds WB W\s-2EB\s0 .\"===================================================================== .SH NAME pdftex, pdfinitex, pdfvirtex \- PDF output from TeX We would be happy if you could apply the patch. Regards, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg

2 1

processing speed
by Reinhard Kotucha 30 May '09

30 May '09

Hi, did anybody observe already that pdftex gets slower and slower when processing huge documents? I recently wrote a few perl scripts which create huge LaTeX files containing data from spectrum analyzers and I'm using the pgfplots package in order to visualize the results. On my humble Windows machine it takes about one second to create such a plot. This is ok even if I have to create thousands of them. But now I have to create thousands of them, and I noticed that the amount of time needed to produce one single plot is increasing steadily. I first thought that it's a pgfplots issue but I created test files which confirm that it's a pdftex problem. Download the tiny Perl script http://tug.org/~kotucha/mktestfiles.gz and then try: tex --shell-escape testplain.tex and pdftex --shell-escape testplain.tex What you'll see on screen is the output of "date +%s" whenever the \input file had been processed. (Thus, it works only on UNIX). You'll see that at the beginning Knuth's TeX and pdfTeX need approximately the same amount of time to process one \input file. But while Knuth's TeX needs the same amount of time to process any \input file, the amount of time pdfTeX needs increases steadily. Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------

6 25

[pdftex-Bugs][4289] \primitive\pdfoutput cannot be queried
by pdftex-bugs＠sarovar.org 21 May '09

21 May '09

Bugs item #4289, was opened at 2009-05-21 18:52 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: \primitive\pdfoutput cannot be queried Category: None Group: None >Resolution: Accepted Initial Comment: see http://www.ntg.nl/pipermail/ntg-pdftex/2009-April/003769.html ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-05-21 18:54 Message: fix from Taco attached. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4289&group_id=106

1 0

[pdftex-Bugs][4289] \primitive\pdfoutput cannot be queried
by pdftex-bugs＠sarovar.org 21 May '09

21 May '09

Bugs item #4289, was opened at 2009-05-21 18:52 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: \primitive\pdfoutput cannot be queried Category: None Group: None Resolution: None Initial Comment: see http://www.ntg.nl/pipermail/ntg-pdftex/2009-April/003769.html ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4289&group_id=106

1 0

[pdftex-Bugs][4288] character width mismatch in font XY.vf ignored
by pdftex-bugs＠sarovar.org 12 May '09

12 May '09

Bugs item #4288, was opened at 2009-05-12 07:47 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: character width mismatch in font XY.vf ignored Category: Fonts Group: None Resolution: Accepted Initial Comment: see http://tug.org/pipermail/pdftex/2009-May/008031.html ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-05-12 12:23 Message: bugfix from Hartmut attached. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4288&group_id=106

1 0

[pdftex-Bugs][4288] character width mismatch in font XY.vf ignored
by pdftex-bugs＠sarovar.org 12 May '09

12 May '09

Bugs item #4288, was opened at 2009-05-12 07:47 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: character width mismatch in font XY.vf ignored Category: Fonts Group: None Resolution: Accepted Initial Comment: see http://tug.org/pipermail/pdftex/2009-May/008031.html ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4288&group_id=106

1 0

Urgent help needed (Document open settings)
by Philip TAYLOR 22 Apr '09

22 Apr '09

Dear Colleagues -- I am being driven to distraction by my inability to persuade PdfTeX to set the default "Document open" option to "Fit Visible". I know that Hyperref can accomplish this, but I am working in TeX, not LaTeX. I assume that an appropriate incantation to \pdfliteral will be all that is required, but so far Google has failed to throw up any useful hints as to what to pass to \pdfliteral to accomplish this. Your help will be much appreciated. Philip Taylor

2 2

\primitive\pdfoutput cannot be queried
by Heiko Oberdiek 16 Apr '09

16 Apr '09

Hello, AFAIK, an expression with \primitive will become expandable if and only if the primitive is expandable. (pdfTeX: \pdfprimitive) The problem arises with \pdfoutput, a kind of count register. Therefore it isn't expandable. This doesn't hurt, if \pdfoutput is set. However it cannot get its value anymore: \gdef\pdfoutput{\primitive\pdfoutput} a) \ifcase\pdfoutput fails with ! Missing number, treated as zero. <to be read again> \primitive b) \ifcase\the\pdfoutput fails with ! You can't use `\primitive' after \the. c) \ifcase\number\pdfoutput fails with ! Missing number, treated as zero. <to be read again> \primitive d) \count0=\pdfoutput fails with ! Missing number, treated as zero. <to be read again> \primitive Yours sincerely Heiko <oberdiek(a)uni-freiburg.de>

2 7

[pdftex-Bugs][4014] Drops characters from included pdf figure
by pdftex-bugs＠sarovar.org 12 Apr '09

12 Apr '09

Bugs item #4014, was opened at 2009-04-08 17:24 Status: Closed Priority: 3 Submitted By: Andrey Paramonov (pent) Assigned to: Nobody (None) Summary: Drops characters from included pdf figure Category: PDF inclusion Group: None Resolution: Wont Fix Initial Comment: To reproduce: 1) Download attached file. It is a pdf figure containing some non-latin characters. Note that the used font subset is embedded. 2) Create the following minimal LaTeX document: \documentclass{article} \usepackage[T2A]{fontenc} \usepackage[utf8]{inputenc} \usepackage[russian]{babel} \usepackage{graphicx} \begin{document} \includegraphics{fig} \end{document} 3) pdflatex it. Open the resulting pdf file and note that all non-latin characters have disappeared. My pdflatex says: --------- Running `LaTeX' on `test' with ``pdflatex "\nonstopmode\input {test.tex}"'' This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6) %&-line parsing enabled. entering extended mode LaTeX2e <2005/12/01> Babel <v3.8h> and hyphenation patterns for english, usenglishmax, dumylang, noh yphenation, ukrainian, russian, bulgarian, loaded. (./test.tex (/usr/share/texmf-texlive/tex/latex/base/article.cls Document Class: article 2005/09/16 v1.4f Standard LaTeX document class (/usr/share/texmf-texlive/tex/latex/base/size10.clo)) (/usr/share/texmf-texlive/tex/latex/base/fontenc.sty (/usr/share/texmf-texlive/tex/latex/cyrillic/t2aenc.def) (/usr/share/texmf-texlive/tex/latex/cyrillic/t2acmr.fd)) (/usr/share/texmf-texlive/tex/latex/base/inputenc.sty (/usr/share/texmf-texlive/tex/latex/base/utf8.def (/usr/share/texmf-texlive/tex/latex/base/t1enc.dfu) (/usr/share/texmf-texlive/tex/latex/base/ot1enc.dfu) (/usr/share/texmf-texlive/tex/latex/base/omsenc.dfu) (/usr/share/texmf-texlive/tex/latex/base/t2aenc.dfu))) (/usr/share/texmf-texlive/tex/generic/babel/babel.sty (/usr/share/texmf-texlive/tex/generic/babel/russianb.ldf (/usr/share/texmf-texlive/tex/generic/babel/babel.def))) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty (/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty) (/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty (/usr/share/texmf-texlive/tex/latex/graphics/trig.sty) (/etc/texmf/tex/latex/config/graphics.cfg) (/usr/share/texmf-texlive/tex/latex/pdftex-def/pdftex.def))) (./ test.aux) <fig.pdf, id=1, 578.16pt x 289.08pt> <use fig.pdf> Overfull \hbox (248.15858pt too wide) in paragraph at lines 10--11 [][] [1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map} <./fig.pdf>] (./ test.aux) ) (see the transcript file for additional information){/usr/share/texmf/ fonts/enc /dvips/cm-super/cm-super-t2a.enc}</usr/share/texmf/fonts/type1/public/ cm-super/ sfrm1000.pfb></usr/share/texmf-texlive/fonts/type1/urw/times/ utmr8a.pfb pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10019' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10021' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10026' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10028' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10030' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10031' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10032' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10033' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10035' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10049' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10065' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10067' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10070' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10075' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10077' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10079' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10080' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10082' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10084' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10096' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10097' undefined Output written on test.pdf (1 page, 19327 bytes). Transcript written on test.log. LaTeX finished at Wed Apr 8 00:01:45 --------- My pdftex --version says: --------- pdfTeX using libpoppler 3.141592-1.40.3-2.2 (Web2C 7.5.6) kpathsea version 3.5.6 Copyright 2007 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Kpathsea is copyright 2007 Karl Berry and Olaf Weber. There is NO warranty. Redistribution of this software is covered by the terms of both the pdfTeX using libpoppler copyright and the Lesser GNU General Public License. For more information about these matters, see the file named COPYING and the pdfTeX using libpoppler source. Primary author of pdfTeX using libpoppler: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Kpathsea written by Karl Berry, Olaf Weber, and others. Compiled with libpng 1.2.35; using libpng 1.2.35 Compiled with zlib 1.2.3.3; using zlib 1.2.3.3 Compiled with libpoppler version 0.10.4 --------- I'm ready to provide any additional info, Andrey Paramonov ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-04-12 14:27 Message: the problem we have is basically this: we have fontA in fig.pdf and fontB on disk. They have the same name. How pdftex can detect whether fontB is a superset of fontA, so that fontA will be replaced by fontB only when it is safe to do so. This sounds simple, but it's not easy to do for some reasons: - pdftex parses fontB at the end, not during pdf inclusion. At this phase it's too late to change the decision whether to copy fontA. - telling whether "fontB is a superset of fontA" is difficult. They might differ in various ways, not only in glyph set. - fontA might be in Type1C format, which pdftex cannot parse. ---------------------------------------------------------------------- Comment By: Andrey Paramonov (pent) Date: 2009-04-10 19:50 Message: Hello! Thanks for the detailed explanations. I've dug a bit deeper and indeed, there are two versions of NimbusRomNo9L-Regu in my system: /usr/share/fonts/type1/gsfonts/n021003l.pfb (v.1.0.6, dated 08/02/2007, Debian package gsfonts) /usr/share/texmf-texlive/fonts/type1/urw/times/utmr8a.pfb (v.1.0.5, dated 01/10/2006, Debian package texlive-fonts-recommended) The workarounds you suggest are helpful, but I still think the problem must be eliminated completely, if there is a way to do so. Probably you are right that different fonts should always have different names. But such an assertion only works in the ideal world. In reality, if user A sends a figure to user B, there is a (rather high) chance that their versions of the font do not match. Even on my local system I'm not sure which of the packages to blame: gsfonts for not renaming font after major upgrade, or texlive-fonts-recommended for providing an old version of the font (or myself for using Debian at all ;-). In my opinion, we should be more tolerant to what we receive. If there is a way to detect "glyph xxx undefined" situation beforehand, pdftex should do so and act as if \pdfmapline{-l7x-utmr NimbusRomNo9L-Regu} (for my example) is present in the document. Is there a way to implement such a behavior? Thanks for your effort, Andrey ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-09 21:28 Message: I think it's useful to have a summary of the problem for further reference: - fig.pdf contains a font named NimbusRomNo9L-Regu - pdftex sees that it has the same font on disk and tries to use the font on disk instead of copying the font from fig.pdf. (Reason: if we have eg fig.pdf & fig2.pdf, the font would be included once instead of twice) - however these 2 fonts are different: the one embedded in fig.pdf has extra glyphs that the font on disk doesn't have. pdftex cannot know this, since the font names are the same. - hence the output pdf doesn't have those glyphs, too. workarounds/solutions: - if you are in hurry, just say: \pdfinclusioncopyfonts=1 - for more detailed info, see bug report #2092 - the proper solution IMO is to change the font name to denote that it differ from the original NimbusRomNo9L-Regu It's questionable whether pdftex should use the font on disk instead of copying the font from fig.pdf by default. There are 2 main arguments for this behavior: - that behavior was the default since the beginning, and it's not wise to change it; it can break pdf inclusion in existing documents - if this behavior is not desired, it can be changed easily (\pdfinclusioncopyfonts=1) btw, if you think this is a bug, please describe what should be the correct behavior in your opinion. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-09 05:41 Message: if the font has been changed, the font name should have be changed too. ---------------------------------------------------------------------- Comment By: Andrey Paramonov (pent) Date: 2009-04-09 04:13 Message: Yes, probably a different version of the font was used to create the figure. I don't see however why it is forbidden. The font embedding feature has been *designed* to resolve the problems with different version of the fonts. If pdftex ignores the feature, and does so consciously, I see the problem is in pdftex. The discussion and workarounds mentioned in #2092 suggest that by default, pdftex tries to be clever and drops embedded fonts that would later be included anyway. In this case however pdftex becomes overconfident and drops fonts it cannot later restore. To me, this is a clear optimization bug. Andrey Paramonov ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-08 19:05 Message: update: the link was wrong again; somehow a ';' was automatically inserted to the link. Please see bug #2092 for a similar problem and workaround. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-08 19:02 Message: update: the previous link was broken, correction: http://sarovar.org/tracker/index.php?func=detail&aid=2092&group_id=106&atid… ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-08 18:59 Message: I guess the figure was created with a modified version of utmr8a.pfb (NimbusRomNo9L-Regu), since the original utmr8a.pfb doesn't have non-latin glyphs. This is not a bug of pdftex. For a workaround, please see http://sarovar.org/tracker/index.php?func=detail&aid=2092&group_id=106&atid… ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4014&group_id=106

1 0

[pdftex-Bugs][4014] Drops characters from included pdf figure
by pdftex-bugs＠sarovar.org 10 Apr '09

10 Apr '09

Bugs item #4014, was opened at 2009-04-08 21:24 Status: Closed Priority: 3 Submitted By: Andrey Paramonov (pent) Assigned to: Nobody (None) Summary: Drops characters from included pdf figure Category: PDF inclusion Group: None Resolution: Wont Fix Initial Comment: To reproduce: 1) Download attached file. It is a pdf figure containing some non-latin characters. Note that the used font subset is embedded. 2) Create the following minimal LaTeX document: \documentclass{article} \usepackage[T2A]{fontenc} \usepackage[utf8]{inputenc} \usepackage[russian]{babel} \usepackage{graphicx} \begin{document} \includegraphics{fig} \end{document} 3) pdflatex it. Open the resulting pdf file and note that all non-latin characters have disappeared. My pdflatex says: --------- Running `LaTeX' on `test' with ``pdflatex "\nonstopmode\input {test.tex}"'' This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6) %&-line parsing enabled. entering extended mode LaTeX2e <2005/12/01> Babel <v3.8h> and hyphenation patterns for english, usenglishmax, dumylang, noh yphenation, ukrainian, russian, bulgarian, loaded. (./test.tex (/usr/share/texmf-texlive/tex/latex/base/article.cls Document Class: article 2005/09/16 v1.4f Standard LaTeX document class (/usr/share/texmf-texlive/tex/latex/base/size10.clo)) (/usr/share/texmf-texlive/tex/latex/base/fontenc.sty (/usr/share/texmf-texlive/tex/latex/cyrillic/t2aenc.def) (/usr/share/texmf-texlive/tex/latex/cyrillic/t2acmr.fd)) (/usr/share/texmf-texlive/tex/latex/base/inputenc.sty (/usr/share/texmf-texlive/tex/latex/base/utf8.def (/usr/share/texmf-texlive/tex/latex/base/t1enc.dfu) (/usr/share/texmf-texlive/tex/latex/base/ot1enc.dfu) (/usr/share/texmf-texlive/tex/latex/base/omsenc.dfu) (/usr/share/texmf-texlive/tex/latex/base/t2aenc.dfu))) (/usr/share/texmf-texlive/tex/generic/babel/babel.sty (/usr/share/texmf-texlive/tex/generic/babel/russianb.ldf (/usr/share/texmf-texlive/tex/generic/babel/babel.def))) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty (/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty) (/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty (/usr/share/texmf-texlive/tex/latex/graphics/trig.sty) (/etc/texmf/tex/latex/config/graphics.cfg) (/usr/share/texmf-texlive/tex/latex/pdftex-def/pdftex.def))) (./ test.aux) <fig.pdf, id=1, 578.16pt x 289.08pt> <use fig.pdf> Overfull \hbox (248.15858pt too wide) in paragraph at lines 10--11 [][] [1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map} <./fig.pdf>] (./ test.aux) ) (see the transcript file for additional information){/usr/share/texmf/ fonts/enc /dvips/cm-super/cm-super-t2a.enc}</usr/share/texmf/fonts/type1/public/ cm-super/ sfrm1000.pfb></usr/share/texmf-texlive/fonts/type1/urw/times/ utmr8a.pfb pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10019' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10021' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10026' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10028' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10030' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10031' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10032' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10033' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10035' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10049' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10065' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10067' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10070' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10075' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10077' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10079' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10080' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10082' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10084' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10096' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10097' undefined Output written on test.pdf (1 page, 19327 bytes). Transcript written on test.log. LaTeX finished at Wed Apr 8 00:01:45 --------- My pdftex --version says: --------- pdfTeX using libpoppler 3.141592-1.40.3-2.2 (Web2C 7.5.6) kpathsea version 3.5.6 Copyright 2007 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Kpathsea is copyright 2007 Karl Berry and Olaf Weber. There is NO warranty. Redistribution of this software is covered by the terms of both the pdfTeX using libpoppler copyright and the Lesser GNU General Public License. For more information about these matters, see the file named COPYING and the pdfTeX using libpoppler source. Primary author of pdfTeX using libpoppler: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Kpathsea written by Karl Berry, Olaf Weber, and others. Compiled with libpng 1.2.35; using libpng 1.2.35 Compiled with zlib 1.2.3.3; using zlib 1.2.3.3 Compiled with libpoppler version 0.10.4 --------- I'm ready to provide any additional info, Andrey Paramonov ---------------------------------------------------------------------- Comment By: Andrey Paramonov (pent) Date: 2009-04-10 23:50 Message: Hello! Thanks for the detailed explanations. I've dug a bit deeper and indeed, there are two versions of NimbusRomNo9L-Regu in my system: /usr/share/fonts/type1/gsfonts/n021003l.pfb (v.1.0.6, dated 08/02/2007, Debian package gsfonts) /usr/share/texmf-texlive/fonts/type1/urw/times/utmr8a.pfb (v.1.0.5, dated 01/10/2006, Debian package texlive-fonts-recommended) The workarounds you suggest are helpful, but I still think the problem must be eliminated completely, if there is a way to do so. Probably you are right that different fonts should always have different names. But such an assertion only works in the ideal world. In reality, if user A sends a figure to user B, there is a (rather high) chance that their versions of the font do not match. Even on my local system I'm not sure which of the packages to blame: gsfonts for not renaming font after major upgrade, or texlive-fonts-recommended for providing an old version of the font (or myself for using Debian at all ;-). In my opinion, we should be more tolerant to what we receive. If there is a way to detect "glyph xxx undefined" situation beforehand, pdftex should do so and act as if \pdfmapline{-l7x-utmr NimbusRomNo9L-Regu} (for my example) is present in the document. Is there a way to implement such a behavior? Thanks for your effort, Andrey ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-10 01:28 Message: I think it's useful to have a summary of the problem for further reference: - fig.pdf contains a font named NimbusRomNo9L-Regu - pdftex sees that it has the same font on disk and tries to use the font on disk instead of copying the font from fig.pdf. (Reason: if we have eg fig.pdf & fig2.pdf, the font would be included once instead of twice) - however these 2 fonts are different: the one embedded in fig.pdf has extra glyphs that the font on disk doesn't have. pdftex cannot know this, since the font names are the same. - hence the output pdf doesn't have those glyphs, too. workarounds/solutions: - if you are in hurry, just say: \pdfinclusioncopyfonts=1 - for more detailed info, see bug report #2092 - the proper solution IMO is to change the font name to denote that it differ from the original NimbusRomNo9L-Regu It's questionable whether pdftex should use the font on disk instead of copying the font from fig.pdf by default. There are 2 main arguments for this behavior: - that behavior was the default since the beginning, and it's not wise to change it; it can break pdf inclusion in existing documents - if this behavior is not desired, it can be changed easily (\pdfinclusioncopyfonts=1) btw, if you think this is a bug, please describe what should be the correct behavior in your opinion. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-09 09:41 Message: if the font has been changed, the font name should have be changed too. ---------------------------------------------------------------------- Comment By: Andrey Paramonov (pent) Date: 2009-04-09 08:13 Message: Yes, probably a different version of the font was used to create the figure. I don't see however why it is forbidden. The font embedding feature has been *designed* to resolve the problems with different version of the fonts. If pdftex ignores the feature, and does so consciously, I see the problem is in pdftex. The discussion and workarounds mentioned in #2092 suggest that by default, pdftex tries to be clever and drops embedded fonts that would later be included anyway. In this case however pdftex becomes overconfident and drops fonts it cannot later restore. To me, this is a clear optimization bug. Andrey Paramonov ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-08 23:05 Message: update: the link was wrong again; somehow a ';' was automatically inserted to the link. Please see bug #2092 for a similar problem and workaround. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-08 23:02 Message: update: the previous link was broken, correction: http://sarovar.org/tracker/index.php?func=detail&aid=2092&group_id=106&atid… ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-08 22:59 Message: I guess the figure was created with a modified version of utmr8a.pfb (NimbusRomNo9L-Regu), since the original utmr8a.pfb doesn't have non-latin glyphs. This is not a bug of pdftex. For a workaround, please see http://sarovar.org/tracker/index.php?func=detail&aid=2092&group_id=106&atid… ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4014&group_id=106

1 0

[pdftex-Bugs][4014] Drops characters from included pdf figure
by pdftex-bugs＠sarovar.org 09 Apr '09

09 Apr '09

Bugs item #4014, was opened at 2009-04-08 17:24 Status: Closed Priority: 3 Submitted By: Andrey Paramonov (pent) Assigned to: Nobody (None) Summary: Drops characters from included pdf figure Category: PDF inclusion Group: None Resolution: Wont Fix Initial Comment: To reproduce: 1) Download attached file. It is a pdf figure containing some non-latin characters. Note that the used font subset is embedded. 2) Create the following minimal LaTeX document: \documentclass{article} \usepackage[T2A]{fontenc} \usepackage[utf8]{inputenc} \usepackage[russian]{babel} \usepackage{graphicx} \begin{document} \includegraphics{fig} \end{document} 3) pdflatex it. Open the resulting pdf file and note that all non-latin characters have disappeared. My pdflatex says: --------- Running `LaTeX' on `test' with ``pdflatex "\nonstopmode\input {test.tex}"'' This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6) %&-line parsing enabled. entering extended mode LaTeX2e <2005/12/01> Babel <v3.8h> and hyphenation patterns for english, usenglishmax, dumylang, noh yphenation, ukrainian, russian, bulgarian, loaded. (./test.tex (/usr/share/texmf-texlive/tex/latex/base/article.cls Document Class: article 2005/09/16 v1.4f Standard LaTeX document class (/usr/share/texmf-texlive/tex/latex/base/size10.clo)) (/usr/share/texmf-texlive/tex/latex/base/fontenc.sty (/usr/share/texmf-texlive/tex/latex/cyrillic/t2aenc.def) (/usr/share/texmf-texlive/tex/latex/cyrillic/t2acmr.fd)) (/usr/share/texmf-texlive/tex/latex/base/inputenc.sty (/usr/share/texmf-texlive/tex/latex/base/utf8.def (/usr/share/texmf-texlive/tex/latex/base/t1enc.dfu) (/usr/share/texmf-texlive/tex/latex/base/ot1enc.dfu) (/usr/share/texmf-texlive/tex/latex/base/omsenc.dfu) (/usr/share/texmf-texlive/tex/latex/base/t2aenc.dfu))) (/usr/share/texmf-texlive/tex/generic/babel/babel.sty (/usr/share/texmf-texlive/tex/generic/babel/russianb.ldf (/usr/share/texmf-texlive/tex/generic/babel/babel.def))) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty (/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty) (/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty (/usr/share/texmf-texlive/tex/latex/graphics/trig.sty) (/etc/texmf/tex/latex/config/graphics.cfg) (/usr/share/texmf-texlive/tex/latex/pdftex-def/pdftex.def))) (./ test.aux) <fig.pdf, id=1, 578.16pt x 289.08pt> <use fig.pdf> Overfull \hbox (248.15858pt too wide) in paragraph at lines 10--11 [][] [1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map} <./fig.pdf>] (./ test.aux) ) (see the transcript file for additional information){/usr/share/texmf/ fonts/enc /dvips/cm-super/cm-super-t2a.enc}</usr/share/texmf/fonts/type1/public/ cm-super/ sfrm1000.pfb></usr/share/texmf-texlive/fonts/type1/urw/times/ utmr8a.pfb pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10019' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10021' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10026' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10028' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10030' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10031' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10032' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10033' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10035' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10049' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10065' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10067' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10070' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10075' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10077' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10079' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10080' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10082' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10084' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10096' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10097' undefined Output written on test.pdf (1 page, 19327 bytes). Transcript written on test.log. LaTeX finished at Wed Apr 8 00:01:45 --------- My pdftex --version says: --------- pdfTeX using libpoppler 3.141592-1.40.3-2.2 (Web2C 7.5.6) kpathsea version 3.5.6 Copyright 2007 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Kpathsea is copyright 2007 Karl Berry and Olaf Weber. There is NO warranty. Redistribution of this software is covered by the terms of both the pdfTeX using libpoppler copyright and the Lesser GNU General Public License. For more information about these matters, see the file named COPYING and the pdfTeX using libpoppler source. Primary author of pdfTeX using libpoppler: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Kpathsea written by Karl Berry, Olaf Weber, and others. Compiled with libpng 1.2.35; using libpng 1.2.35 Compiled with zlib 1.2.3.3; using zlib 1.2.3.3 Compiled with libpoppler version 0.10.4 --------- I'm ready to provide any additional info, Andrey Paramonov ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-04-09 21:28 Message: I think it's useful to have a summary of the problem for further reference: - fig.pdf contains a font named NimbusRomNo9L-Regu - pdftex sees that it has the same font on disk and tries to use the font on disk instead of copying the font from fig.pdf. (Reason: if we have eg fig.pdf & fig2.pdf, the font would be included once instead of twice) - however these 2 fonts are different: the one embedded in fig.pdf has extra glyphs that the font on disk doesn't have. pdftex cannot know this, since the font names are the same. - hence the output pdf doesn't have those glyphs, too. workarounds/solutions: - if you are in hurry, just say: \pdfinclusioncopyfonts=1 - for more detailed info, see bug report #2092 - the proper solution IMO is to change the font name to denote that it differ from the original NimbusRomNo9L-Regu It's questionable whether pdftex should use the font on disk instead of copying the font from fig.pdf by default. There are 2 main arguments for this behavior: - that behavior was the default since the beginning, and it's not wise to change it; it can break pdf inclusion in existing documents - if this behavior is not desired, it can be changed easily (\pdfinclusioncopyfonts=1) btw, if you think this is a bug, please describe what should be the correct behavior in your opinion. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-09 05:41 Message: if the font has been changed, the font name should have be changed too. ---------------------------------------------------------------------- Comment By: Andrey Paramonov (pent) Date: 2009-04-09 04:13 Message: Yes, probably a different version of the font was used to create the figure. I don't see however why it is forbidden. The font embedding feature has been *designed* to resolve the problems with different version of the fonts. If pdftex ignores the feature, and does so consciously, I see the problem is in pdftex. The discussion and workarounds mentioned in #2092 suggest that by default, pdftex tries to be clever and drops embedded fonts that would later be included anyway. In this case however pdftex becomes overconfident and drops fonts it cannot later restore. To me, this is a clear optimization bug. Andrey Paramonov ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-08 19:05 Message: update: the link was wrong again; somehow a ';' was automatically inserted to the link. Please see bug #2092 for a similar problem and workaround. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-08 19:02 Message: update: the previous link was broken, correction: http://sarovar.org/tracker/index.php?func=detail&aid=2092&group_id=106&atid… ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-08 18:59 Message: I guess the figure was created with a modified version of utmr8a.pfb (NimbusRomNo9L-Regu), since the original utmr8a.pfb doesn't have non-latin glyphs. This is not a bug of pdftex. For a workaround, please see http://sarovar.org/tracker/index.php?func=detail&aid=2092&group_id=106&atid… ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4014&group_id=106

1 0

[pdftex-Bugs][4014] Drops characters from included pdf figure
by pdftex-bugs＠sarovar.org 09 Apr '09

09 Apr '09

Bugs item #4014, was opened at 2009-04-08 17:24 >Status: Closed Priority: 3 Submitted By: Andrey Paramonov (pent) Assigned to: Nobody (None) Summary: Drops characters from included pdf figure Category: PDF inclusion Group: None Resolution: Wont Fix Initial Comment: To reproduce: 1) Download attached file. It is a pdf figure containing some non-latin characters. Note that the used font subset is embedded. 2) Create the following minimal LaTeX document: \documentclass{article} \usepackage[T2A]{fontenc} \usepackage[utf8]{inputenc} \usepackage[russian]{babel} \usepackage{graphicx} \begin{document} \includegraphics{fig} \end{document} 3) pdflatex it. Open the resulting pdf file and note that all non-latin characters have disappeared. My pdflatex says: --------- Running `LaTeX' on `test' with ``pdflatex "\nonstopmode\input {test.tex}"'' This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6) %&-line parsing enabled. entering extended mode LaTeX2e <2005/12/01> Babel <v3.8h> and hyphenation patterns for english, usenglishmax, dumylang, noh yphenation, ukrainian, russian, bulgarian, loaded. (./test.tex (/usr/share/texmf-texlive/tex/latex/base/article.cls Document Class: article 2005/09/16 v1.4f Standard LaTeX document class (/usr/share/texmf-texlive/tex/latex/base/size10.clo)) (/usr/share/texmf-texlive/tex/latex/base/fontenc.sty (/usr/share/texmf-texlive/tex/latex/cyrillic/t2aenc.def) (/usr/share/texmf-texlive/tex/latex/cyrillic/t2acmr.fd)) (/usr/share/texmf-texlive/tex/latex/base/inputenc.sty (/usr/share/texmf-texlive/tex/latex/base/utf8.def (/usr/share/texmf-texlive/tex/latex/base/t1enc.dfu) (/usr/share/texmf-texlive/tex/latex/base/ot1enc.dfu) (/usr/share/texmf-texlive/tex/latex/base/omsenc.dfu) (/usr/share/texmf-texlive/tex/latex/base/t2aenc.dfu))) (/usr/share/texmf-texlive/tex/generic/babel/babel.sty (/usr/share/texmf-texlive/tex/generic/babel/russianb.ldf (/usr/share/texmf-texlive/tex/generic/babel/babel.def))) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty (/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty) (/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty (/usr/share/texmf-texlive/tex/latex/graphics/trig.sty) (/etc/texmf/tex/latex/config/graphics.cfg) (/usr/share/texmf-texlive/tex/latex/pdftex-def/pdftex.def))) (./ test.aux) <fig.pdf, id=1, 578.16pt x 289.08pt> <use fig.pdf> Overfull \hbox (248.15858pt too wide) in paragraph at lines 10--11 [][] [1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map} <./fig.pdf>] (./ test.aux) ) (see the transcript file for additional information){/usr/share/texmf/ fonts/enc /dvips/cm-super/cm-super-t2a.enc}</usr/share/texmf/fonts/type1/public/ cm-super/ sfrm1000.pfb></usr/share/texmf-texlive/fonts/type1/urw/times/ utmr8a.pfb pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10019' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10021' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10026' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10028' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10030' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10031' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10032' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10033' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10035' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10049' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10065' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10067' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10070' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10075' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10077' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10079' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10080' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10082' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10084' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10096' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10097' undefined Output written on test.pdf (1 page, 19327 bytes). Transcript written on test.log. LaTeX finished at Wed Apr 8 00:01:45 --------- My pdftex --version says: --------- pdfTeX using libpoppler 3.141592-1.40.3-2.2 (Web2C 7.5.6) kpathsea version 3.5.6 Copyright 2007 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Kpathsea is copyright 2007 Karl Berry and Olaf Weber. There is NO warranty. Redistribution of this software is covered by the terms of both the pdfTeX using libpoppler copyright and the Lesser GNU General Public License. For more information about these matters, see the file named COPYING and the pdfTeX using libpoppler source. Primary author of pdfTeX using libpoppler: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Kpathsea written by Karl Berry, Olaf Weber, and others. Compiled with libpng 1.2.35; using libpng 1.2.35 Compiled with zlib 1.2.3.3; using zlib 1.2.3.3 Compiled with libpoppler version 0.10.4 --------- I'm ready to provide any additional info, Andrey Paramonov ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-04-09 05:41 Message: if the font has been changed, the font name should have be changed too. ---------------------------------------------------------------------- Comment By: Andrey Paramonov (pent) Date: 2009-04-09 04:13 Message: Yes, probably a different version of the font was used to create the figure. I don't see however why it is forbidden. The font embedding feature has been *designed* to resolve the problems with different version of the fonts. If pdftex ignores the feature, and does so consciously, I see the problem is in pdftex. The discussion and workarounds mentioned in #2092 suggest that by default, pdftex tries to be clever and drops embedded fonts that would later be included anyway. In this case however pdftex becomes overconfident and drops fonts it cannot later restore. To me, this is a clear optimization bug. Andrey Paramonov ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-08 19:05 Message: update: the link was wrong again; somehow a ';' was automatically inserted to the link. Please see bug #2092 for a similar problem and workaround. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-08 19:02 Message: update: the previous link was broken, correction: http://sarovar.org/tracker/index.php?func=detail&aid=2092&group_id=106&atid… ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-08 18:59 Message: I guess the figure was created with a modified version of utmr8a.pfb (NimbusRomNo9L-Regu), since the original utmr8a.pfb doesn't have non-latin glyphs. This is not a bug of pdftex. For a workaround, please see http://sarovar.org/tracker/index.php?func=detail&aid=2092&group_id=106&atid… ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4014&group_id=106

1 0

[pdftex-Bugs][4014] Drops characters from included pdf figure
by pdftex-bugs＠sarovar.org 09 Apr '09

09 Apr '09

Bugs item #4014, was opened at 2009-04-08 21:24 Status: Open Priority: 3 Submitted By: Andrey Paramonov (pent) Assigned to: Nobody (None) Summary: Drops characters from included pdf figure Category: PDF inclusion Group: None Resolution: Wont Fix Initial Comment: To reproduce: 1) Download attached file. It is a pdf figure containing some non-latin characters. Note that the used font subset is embedded. 2) Create the following minimal LaTeX document: \documentclass{article} \usepackage[T2A]{fontenc} \usepackage[utf8]{inputenc} \usepackage[russian]{babel} \usepackage{graphicx} \begin{document} \includegraphics{fig} \end{document} 3) pdflatex it. Open the resulting pdf file and note that all non-latin characters have disappeared. My pdflatex says: --------- Running `LaTeX' on `test' with ``pdflatex "\nonstopmode\input {test.tex}"'' This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6) %&-line parsing enabled. entering extended mode LaTeX2e <2005/12/01> Babel <v3.8h> and hyphenation patterns for english, usenglishmax, dumylang, noh yphenation, ukrainian, russian, bulgarian, loaded. (./test.tex (/usr/share/texmf-texlive/tex/latex/base/article.cls Document Class: article 2005/09/16 v1.4f Standard LaTeX document class (/usr/share/texmf-texlive/tex/latex/base/size10.clo)) (/usr/share/texmf-texlive/tex/latex/base/fontenc.sty (/usr/share/texmf-texlive/tex/latex/cyrillic/t2aenc.def) (/usr/share/texmf-texlive/tex/latex/cyrillic/t2acmr.fd)) (/usr/share/texmf-texlive/tex/latex/base/inputenc.sty (/usr/share/texmf-texlive/tex/latex/base/utf8.def (/usr/share/texmf-texlive/tex/latex/base/t1enc.dfu) (/usr/share/texmf-texlive/tex/latex/base/ot1enc.dfu) (/usr/share/texmf-texlive/tex/latex/base/omsenc.dfu) (/usr/share/texmf-texlive/tex/latex/base/t2aenc.dfu))) (/usr/share/texmf-texlive/tex/generic/babel/babel.sty (/usr/share/texmf-texlive/tex/generic/babel/russianb.ldf (/usr/share/texmf-texlive/tex/generic/babel/babel.def))) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty (/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty) (/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty (/usr/share/texmf-texlive/tex/latex/graphics/trig.sty) (/etc/texmf/tex/latex/config/graphics.cfg) (/usr/share/texmf-texlive/tex/latex/pdftex-def/pdftex.def))) (./ test.aux) <fig.pdf, id=1, 578.16pt x 289.08pt> <use fig.pdf> Overfull \hbox (248.15858pt too wide) in paragraph at lines 10--11 [][] [1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map} <./fig.pdf>] (./ test.aux) ) (see the transcript file for additional information){/usr/share/texmf/ fonts/enc /dvips/cm-super/cm-super-t2a.enc}</usr/share/texmf/fonts/type1/public/ cm-super/ sfrm1000.pfb></usr/share/texmf-texlive/fonts/type1/urw/times/ utmr8a.pfb pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10019' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10021' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10026' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10028' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10030' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10031' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10032' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10033' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10035' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10049' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10065' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10067' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10070' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10075' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10077' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10079' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10080' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10082' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10084' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10096' undefined pdfTeX warning: pdflatex (file /usr/share/texmf-texlive/fonts/type1/ urw/times/u tmr8a.pfb): glyph `afii10097' undefined Output written on test.pdf (1 page, 19327 bytes). Transcript written on test.log. LaTeX finished at Wed Apr 8 00:01:45 --------- My pdftex --version says: --------- pdfTeX using libpoppler 3.141592-1.40.3-2.2 (Web2C 7.5.6) kpathsea version 3.5.6 Copyright 2007 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Kpathsea is copyright 2007 Karl Berry and Olaf Weber. There is NO warranty. Redistribution of this software is covered by the terms of both the pdfTeX using libpoppler copyright and the Lesser GNU General Public License. For more information about these matters, see the file named COPYING and the pdfTeX using libpoppler source. Primary author of pdfTeX using libpoppler: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Kpathsea written by Karl Berry, Olaf Weber, and others. Compiled with libpng 1.2.35; using libpng 1.2.35 Compiled with zlib 1.2.3.3; using zlib 1.2.3.3 Compiled with libpoppler version 0.10.4 --------- I'm ready to provide any additional info, Andrey Paramonov ---------------------------------------------------------------------- Comment By: Andrey Paramonov (pent) Date: 2009-04-09 08:13 Message: Yes, probably a different version of the font was used to create the figure. I don't see however why it is forbidden. The font embedding feature has been *designed* to resolve the problems with different version of the fonts. If pdftex ignores the feature, and does so consciously, I see the problem is in pdftex. The discussion and workarounds mentioned in #2092 suggest that by default, pdftex tries to be clever and drops embedded fonts that would later be included anyway. In this case however pdftex becomes overconfident and drops fonts it cannot later restore. To me, this is a clear optimization bug. Andrey Paramonov ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-08 23:05 Message: update: the link was wrong again; somehow a ';' was automatically inserted to the link. Please see bug #2092 for a similar problem and workaround. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-08 23:02 Message: update: the previous link was broken, correction: http://sarovar.org/tracker/index.php?func=detail&aid=2092&group_id=106&atid… ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-08 22:59 Message: I guess the figure was created with a modified version of utmr8a.pfb (NimbusRomNo9L-Regu), since the original utmr8a.pfb doesn't have non-latin glyphs. This is not a bug of pdftex. For a workaround, please see http://sarovar.org/tracker/index.php?func=detail&aid=2092&group_id=106&atid… ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4014&group_id=106

1 0