[tex-k] Fwd: Re: [metapost] problem with 'dvips mproof'

[Stephan Hennig]

Hi,

this is an issue with dvips and embedding MetaPost graphics that contain 
text labels originally posted on the metapost list.  I'm moving the 
issue here because the conclusion (by others) is, that it's a bug in 
dvips.  I'm fully quoting my original bug report and some relevant answers.

Best regards,
Stephan Hennig

-------- Original-Nachricht --------
Betreff: Re: [metapost] problem with 'dvips mproof'

Am 10.10.2010 17:32, schrieb Taco Hoekwater:
> On 10/10/2010 12:26 PM, Stephan Hennig wrote:
>> Am 10.10.2010 02:52, schrieb Reinhard Kotucha:
>>> On 9 October 2010 Stephan Hennig wrote:
>>>
>>>> when processing a file s.mp containing the lines
>>>>
>>>> prologues := 3;
>>>> beginfig(1);
>>>>    label("test", origin);
>>>> endfig;
>>>> end
>>>>
>>>> as
>>>>
>>>>    mpost s
>>>>    tex mproof s.1
>>>>    dvips mproof
>>>>
>>>> I have difficulties watching the resulting file mproof.ps in GSview or
>>>> PS_View (remember, this is dvips output).  Symptoms are different for
>>>> different values of variable prologues.
>>>>
>>>>
>>>> PS_View
>>>>
>>>>    0   -   The files looks fine with text "test" probably rendered in
>>>>            CMR.
>>>>
>>>>    1   -   Fine again.  But at closer inspection the kerning between
>>>>            letters changes slightly in comparison to prologues:=0.
>>>>
>>>>    2   -   Exactly the same as with prologues:=1.
>>>>
>>>>    3   -   The text is visible, but rendered with something else than
>>>>            CMR (probably Courier).
>>>>
>>>> Results with GSview are similar, with one notable exception.  With
>>>> prologues:=1, the text "test" is not rendered at all.  With
>>>> prologues:=3, "test" is also rendered in Courier.  Due to slow redrawing
>>>> in GSview I cannot see if kerning changes between prologues=0 and 2.
>>>>
>>>> As an additional observation that is possibly related, if TeX output is
>>>> converted to pdf via
>>>>
>>>>    dvipdfm mproof
>>>>
>>>> dvipdfm ends with a message
>>>>
>>>> > ** WARNING ** 6 memory objects still allocated
>>>> if prologues is set to 2 or 3.
>>>>
>>>> Since this is not about previewing MetaPost output, but PostScript
>>>> generated by dvips, I had expected no issues other that differences in
>>>> file size for varying values of prologues possibly.  Is this a bug in
>>>> mpost or dvips or is it expected behaviour?
>>>>
>>>>
>>>> System:
>>>>
>>>> standard TL 2010 (updated) on Windows 7
>>>> GSview uses TL's gs
>>>> [gsview32.ini]
>>>> > GhostscriptDLL=F:\texlive\2010\tlpkg\tlgs\bin\gsdll32.dll
>>>> > GhostscriptInclude=F:\texlive\2010\tlpkg\tlgs\bin;F:\texlive\2010\tlpkg\tlgs\fonts
>>>
 >>> [...]
>>> BTW, the prologues variable might be confusing because you have to
>>> remember what all the values are good for. But it's probably
>>> helpful to know that Metapost was designed to support dvips in the
>>> first place, hence you don't have to set prologues at all for dvips.
>>
>> My understanding up until now was like your (possibly unintentional)
>> conclusion in the last sentence: you don't have to set prologues to
>> values >0 for dvips, but it doesn't hurt to do so. I'm seldom using
>> dvips, but prefer pdftex, where prologues is much less relevant, but do
>> I understand you correctly that setting prologues to 0 is /mandatory/
>> when using dvips or dvipdfm as a post-processor for MetaPost files?
 >
> Apparently. The problem is that dvips subsets its own fonts without
> adding a proper subset prefix to the font name, so that the embedded
> font that results from prologues:=3 is actually not used.
>
> (almost) All PostScript type1 fonts begin with a bit of special
> PostScript that attempts to reuse an already defined font by the
> same name, to preserve printer memory.
>
> This works just fine if the predefined name is in fact the full
> font, but it fails if (as is the case of dvips) the predefined
> font is actually a subset of the font (in this particluar case only
> the page number, '1', is included). This is also why Adobe is recommends
> adding a subset prefix to subsetted fonts. But dvips does not do that,
> even though Metapost does: that is why the font in s.1 is named
> "ORMKKB-CMR10" instead of just "CMR10".
>
> So, the cause of the problem is a flaw in dvips.