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 ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ PyX-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pyx-devel
