Re: [PyX-devel] Missing glyphs when including PyX files

[Michael S. <m-s...@us...>]

Hello André,

On 18/02/12, André Wobst wrote:
> First of all DSC-comments should be optional in almost all cases.
> Like this one here. We should not need those comments. They are not
> required. They can be used for resource management to prevent
> resources to be included several times in a combined postscript
> file.

As I see things, there are other (broken) programs, such as dvips and
the software at SoftMatter journal, which require them. If we add
standard-conforming DSC, we do nothing wrong and avoid a lot of
nuisence on PyX-users' side.

> However and first of all, we should *not* write a
> DocumentSuppliedFonts DSC if we include a stripped version of a font
> only.

I do see your point. But does "DocumentSuppliedFonts" mean that these
fonts are complete? A look into the postscript books
(Reference_3Edition.pdf, 5001.DSC_Spec.pdf, T1_SPEC.PDF) does not
elucidate: I cannot find any comment on partial fonts. The closest is
in the DSC standard:

   A document-producing application should almost always use the same
   prolog for all of its documents, or at least the prolog should be
   drawn from a pool of common procedure sets. The prolog should always
   be constructed in a way that it can be removed from the document and
   downloaded only once into the printer. All subsequent documents that
   are downloaded with this prolog stripped out should still execute
   correctly.

AS the font resources are in the prolog, this would mean that the same
prolog should apply for a bunch of files. So, the first file must
contain all fonts used in the later. This is probably not what they
have in mind.

> Furthermore the DocumentSuppliedFonts is not responsible for
> the "fix" you observe then using dvips. Instead, it is the
> DocumentFonts DSC. But this directive is an older and deprecated
> DSC. It was replaced by DocumentSuppliedFonts and
> DocumentNeededFonts. The DocumentFonts should contain all fonts
> listed in both, the DocumentSuppliedFonts and DocumentNeededFonts
> DSCs.

This is what I erroneously claimed in one of my previous mails. I read
again, and now I understand that all three DocumentXXXFonts are
deprecated and should be written as DocumentXXXResources. I
nevertheless kept the DocumentXXXFonts because our T1fonts are
declared in DSC as "BeginFont ... EndFont" and not as Resources.

> And the "fix" you observe when using dvips is triggered, when
> the font in question is listed at the DocumentNeededFonts and/or the
> DocumentFonts DSC, but not in the DocumentSuppliedFonts. So while
> your proposal seems to resolve the issue (and well, yes, it actually
> does), it does it due to a mis-interpretation of the DocumentFonts
> entries by dvips.

> Actually, to my understanding, DocumentFonts should not be used
> anymore and the stripped font contained in the eps file should not
> be listed in DocumentSuppliedFonts nor in DocumentNeededFonts. I do
> not want to reject all your findings, but to my understanding those
> DSCs are wrong and should not be written into the eps file (of the
> file to be included). It does not at all fix the original source of
> the problem (which is a feature of the CMR-type1 fonts, that they
> are not reloaded from the input stream when it is already available
> in the FontDictionary according to the UniqueID and dvips failing to
> remove the UniqueID when stripping fonts).

So, you propose to keep the old version? I strongly disagree, as these
problems occur far too often. And, we are in away inconsistent in the
use of DSC. We write %%BeginFont/%%EndFont around the font definitions,
but we do not put the corresponding statement in the DSC header.

If your proposition is to circumvent DSC treatment by broken software,
then I would propose to put all the stripped fonts without
%%BeginFont/%%EndFont into the document setup
(%%BeginSetup/%%EndSetup), where postscript code can reside.

So, it comes down to the question: If a software has to combine
several eps files, all coming with their own font, but each of them is
a partial font. Does it have to look into each of them, combining them
to have a full set of necessary glyphs? This would be ideal. But what
can we do to help such a software to recognize the problem?

- At the moment, we use the same name and the same UniqueID for the
  stripped font. We might use XUIDs to inform about the modifications
  we did to the font.

- We might not strip fonts at all (Is there such an option in the
  ps/pdfwriter?)

- Put our non-standard-conforming fonts into the
  %%BeginSetup/%%EndSetup part of the DSC.

Michael