[pdftex] inclusion of PDF file fails

[Reinhard Kotucha]

On 2012-01-23 at 11:32:38 +0100, Thanh Han The wrote:

 > On Mon, Jan 23, 2012 at 8:31 AM, Werner LEMBERG <wl at gnu.org> wrote:
 > >>  > > While the `CenturySchL-Roma' font embedded in `BFEx.pdf' is
 > >>  > > version 1.06 (file `c059013l.pfb' from ghostscript), pdftex
 > >>  > > uses `uncr8a.pfb' from TeXLive, which is version 1.05.
 > >>  > > Obviously, version 1.05 misses all Cyrillic glyphs.  IMHO, the
 > >>  > > right solution is to allow font merging only if the font
 > >>  > > versions are identical.
 > >>  >
 > >>  > Is someone going to fix this?
 > >>
 > >> PdfTeX already merges fonts only if they have the same /FontName and
 > >> /UniqueID.
 > >
 > > But the concept of /UniqueID has been abandonded by Adobe a very long
 > > time ago:
 > >
 > >  http://typophile.com/node/18749
 > >
 > > (This link is from 2006.)  So it's actually another bug if pdftex
 > > relies on it.
 > >
 > >> However, ghostschript provides fonts with are buggy in this respect.
 > >> They contain additional glyphs but have the same /FontName and
 > >> /UniqueID as the original URW fonts.  I don't know how pdfTeX should
 > >> recognize this.
 > >
 > > As I've already mentioned: Use the font's version (1.05 vs. 1.06 in
 > > the example given by me)!  If someone produces fonts which are
 > > different but have exactly the same identifier, nothing can be done
 > > except punishing the font developer.
 > 
 > pdftex considers two fonts are the same if they have the same
 > /FontName (/UniqueID is not used).
 > 
 > comparing font version is certain a better way to do it, but the
 > change is not something like a few lines of code. pdftex must parse
 > the font file (from disk) and the font embedded in the pdf. Both are
 > doable but not trivial due to the way pdftex handles fonts now.
 > 
 > In the meantime, perhaps setting \pdfinclusioncopyfonts=1 (as the
 > default value at engine level) is the safe thing to do (with the risk
 > that some people will blame pdftex for increasing pdf output size).

Hi, 
maybe this is not necessary.  We had several discussions about this
problem on some TeX related mailing lists already.  Someone forwarded
one of my mails to the ghostscript developers in which I described the
problem.  Chris Liddell considered to revert to the pristine URW fonts
we are also using in TeX Live.

Now I found this at http://bugs.ghostscript.com/show_bug.cgi?id=687297

| Chris Liddell 2011-12-15 16:19:21 UTC
| Partially fixed by reverting to the pristine URW fonts.
|
| This removes the problematic Cyrillic glyphs, and gives us a "clean"
| base to get back to URW with remaining issues.

Seems that we simply have to wait for the next ghostscript release.

Regards,
  Reinhard

-- 
----------------------------------------------------------------------------
Reinhard Kotucha                                      Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover                              mailto:reinhard.kotucha at web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------