[pdftex] Font (embedding) problem

[Reinhard Kotucha]

>>>>> "James" == James Cloos <cloos at jhcloos.com> writes:

>>>>> "Thierry" == Thierry Bouche <thierry.bouche at ujf-grenoble.fr> writes:
  Thierry> I remember vaguely that distiller removed UniqueIDs so as
  Thierry> to disable font cacheing, maybe does ghostscript something
  Thierry> similar?

  > Adobe reps have written that Adobe considers UniqueIDs essentially
  > deprecated.  As I recall, their RIPs ignore them and they stopped
  > including them in new fonts.  (Of course, they have since moved to
  > otf fonts.)

  > Part of the reason is that modern RIPs have enough RAM and CPU
  > that the advantage of caching the fonts is so small -- in terms of
  > wall- clock time -- as to be lost in the noise.  The rest is that
  > problems sometimes occur, such as what the OP is likely seeing.

  > The post, again as I recall, suggested not including UniqueID when
  > creating or embedding fonts, and ignoring it when rendering fonts.

  > So, pdftex should drop the UniqueID when embedding fonts.

I doubt that this is a good idea.  The UniqueIDs are useful, given
they are unique.  There are different fonts which have the same
FontName.  A good example is Courier.  Adobe provides a Courier, X11
provides a font named Courier and there is an embedded Courier from
Bitstream in Kyocera printers.  And they are all different.

The "Helvetica" in Kyocera printers even has different metrics than
the Adobe/URW fonts.

What sometimes causes trouble is if the UniqueIDs are not unique.
This had been reported once on one of the TeX related mailing lists.
In this case the guy who created the fonts assigned the same UniqueID
to two fonts of the same font family accidentally.

It is not clear whether Marcel's problem has to do anything with
UniqueIDs at all.  He created one big Type1 font.  If there is only
one font why should its UniqueID break anything?

It is much more likely that there is something wrong with re-encoding.

Before anything in pdfTeX is changed, I think that some debugging
should be done.  It would be helpful if I can get a PDF file poduced
by pdfTeX.  I can run it through ghostscript myself, and compare the
output files.

There is one very nasty thing:  Though a user does not notice any
difference when pressing the "print" button in Acroread on Linux or
Windows, there are subtle differences.

On Linux, Acroread creates PostScript directly.  As far as I can tell
it is quite clean PostScript, comparable with the output from pdftops
(part of the xdvi distribution).  

On Windows, PDF is converted to WMF (Windows Meta File Format) first,
the actual PostScript file is generated by pscript.dll.  If you print
to a file and load it into a text editor you'll see that there is a
big macro package at the top of the file.

These macros might contain bugs but I don't have enough time to
examine them.  There are also known limitations in WMF itself, for
instance, CMYK is not supported.

In order to make sure that Windows is not involved, pdftops can be
used to create a PostScript file.  The file can then be copied to the
printer.

pdftops for Windows is part of TeXLive and can be downloaded from

   http://tug.org/svn/texlive/trunk/Master/bin/win32/pdftops.exe

Regards,
  Reinhard

-- 
----------------------------------------------------------------------------
Reinhard Kotucha			              Phone: +49-511-4592165
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.
----------------------------------------------------------------------------