Hi Michael, Am 16.02.2012 um 18:51 schrieb Michael SCHINDLER: > On 16/02/12, André Wobst wrote: >> I didn't look into the details you're describing, but I wonder >> whether it is the same issue discussed in this thread. Please note >> that I summarized some possible solutions at the end. However, >> nothing happened after this discussion as is clearly is a dvips bug >> in the first place. > >> Could you please check whether this is the same issue here? Thanks a >> lot! > > I checked with the example from Axel (two figures containing only > text). As I include them in latex, they do not appear at all in my > ghostview. In the meanwhile, I checked in changeset 3239 which adds a > DSC to declare all fonts in the document. With this change, everything > works fine! -- both my minimal example and the one of Axel.
I just checked it myself now. Indeed. What happens here is that due to the DocumentFonts DSC the full CMR10 font (in this example) is included by dvips, not the stripped one. However, the original problem that dvips breaks the included font of the embedded eps file as I described in the old thread. Please see the full thread at http://sourceforge.net/mailarchive/forum.php?thread_name=C877F565-8AC5-4E7B-8D36-D7E32421B3F2%40users.sourceforge.net&forum_name=pyx-user Your DSC-comments is basically equivalent to the -j0 option for the fonts contained in the included eps file(s). 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. However and first of all, we should *not* write a DocumentSuppliedFonts DSC if we include a stripped version of a font only. 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. 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). Best, André -- by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim / \ \ / ) [email protected], http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ 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
