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

[André W. <wo...@us...>]

Hi Michael,

Am 18.02.2012 um 11:41 schrieb Michael SCHINDLER:
> 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.

You're absolutely right (and I somehow missed it in the earlier discussion, that this is an unacceptable situation. eps files created by PyX should work with dvips properly, and they currently do not do that.

However, it is interesting to note, that this is a rather new issue. To my understanding it is related to recent changes in the type1 computer modern fonts I observed elsewhere (see http://sourceforge.net/mailarchive/forum.php?thread_name=4E95F322.70505%40users.sourceforge.net&forum_name=pyx-devel).

>> 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?

Yeah, I would say so. Otherwise this statement, that such a resource is included (incomplete) is rather pointless.

>> 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.

To my mind it doesn't matter at all. It is not a DSC issue at all.

> So, you propose to keep the old version?

Yes, we do not need any DSC entries. The problem is completely independent of that. Let me give you two examples, why this whole discussion leads us into the wrong direction (to my mind).

1. Consider this kind of minimal example:

    from pyx import *

    c = canvas.canvas()
    c.text(0,0,"a")
    c.writeEPSfile("fig")

and then the following latex file:

    \documentclass{article}
    \usepackage{graphicx}
    \begin{document}
    \includegraphics{fig}
    b
    \end{document}

When you use latex and dvips on this later file and you have the new versions of the computer modern type1 fonts installed, the glyph a is not displayed in the output even though it is contained in the postscript file. There is something wrong in the postscript file, and it has nothing to do with the DSCs. (You can remove all DSCs and the problem remains.) Your DSC commands will result in the embedding of full font (without stripping) by dvips. This is not needed and not correct.

2. Consider the case that you use a font in the figure, which you do not use in the document. Inserting the DSCs you suggested will result in the full embedding of the font in the "outside" document for no valid reason at all. This is due to the fact that dvips "thinks" that those font informations you mark in the DSCs are "DocumentNeededFonts"-entries. This is wrong, we properly embed all the fonts.

> I strongly disagree, as these
> problems occur far too often.

You're right (as I wrote in the beginning of this email already). We can not ignore this issue. As I said I was not aware of its generic nature. Still the real reason is that the new versions of the computer modern type1 fonts do some fancy search for a font with the same UniqueID being already defined and dvips failing to remove the UniqueID when stripping the font (which is clearly a bug).

We basically do have two options to address this bug directly.

1. We could clear all font information in the beginning of the PyX Postscript files by the following small code: "(*) {undefinefont} 128 string /Font resourceforall" – as I suggested in July last year already. But that time I suggested it as a patch to dvips (in special.pro). However, we could move it on top of your PyX Postscript output too. This is rather trivial to do. Just insert this line prior to the font resources in the eps files of the figures (for example immediately after the %%BeginProlog DSC) and the whole issue goes away.

2. We could remove the fancy search for a font with the same UniqueID from the fonts we embed in our Postscript output. Not difficult either. I suggest to go for the second option. See changeset 3242 for the implementation.

Best,


André

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/