[metapost] problem with drawoptions and fake Euro symbol

[Stephan Hennig]

Dan Luecking schrieb:
> At 02:38 PM 11/13/2007, you wrote:
>>
>>I'm trying to use Euro symbols in MetaPost source code that is generated
>>by gnuplot's mp terminal.  The code makes heavy use of the drawoptions
>>macro and this seems to interfere with fonts.
> 
> I wrote a lot of the code for the gnuplot mp terminal. I quit
> supporting it when they began:
>   1. Changing the MP code in ways I didn't agree with (without
>      consulting me) and
>   2. Changing the terminal interface without adequate (IMO)
>      specifications for terminal authors.
> 
> This is one of those things that was discussed and for which I
> suggested a correction (to someone). The suggestion was to rewrite
> the macro that adds text so that it uses "addto currentpicture also"
> instead of "draw" (thereby not invoking drawoptions). The correction
> somehow never made it into the code. This bug can cause fraction bars
> in TeX math to become dotted!

There are several items in gnuplot I would like to see changed:
* boxes aren't closed strokes,
* a hook to provide a user-defined LaTeX preamble or MetaPost code
  is missing,
* the font issue discussed here.

Could you please point me to some place where gnupot and mp terminal
related stuff is best discussed?  Even though, what you wrote sounds not
so enthusiastic.


>>drawoptions and (virtual) fonts to interfere.
> 
> DVI commands that draw a line (which is presumably what the virtual
> font produces) are translated by dvitomp into line drawing commands
> in the mpx file. These are added to a (temporary) picture _p. Then a
> draw command (used directly or through label()) will add the drawoptions.
> Then paths in that picture are subject to those options.

Thank you and Hartmut for the explanation!

In mpman I found this in section 8.6 (or 9.6 for the upcoming release):

> and text appearing in the <picture expression> argument to draw
> <picture expression> statement is only affected by the withcolor
> <color expression> option. For all other combinations of drawing
> statements and options, there is some effect. An option applied to a
> draw <picture expression> statement will in general affect some parts
> of the picture but not others. For instance, a dashed or withpen
> option will affect all the lines in the picture but none of the
> labels.

So characters should not be affected by a withpen option.  I guess the
problem is, in a picture saved in a picture variable MetaPost cannot
distinguish between rules that have formerly been part of a btex..etex
sequence and paths that have not.


> When I wrote gnuplot's MP code I wasn't aware of this, implicitly
> assuming that once a picture was defined drawoptions would not affect
> its path components.

With Hartmut's last question I think we are three that find the current
behaviour---pictures are affected by drawoptions---not intuitive.  Or
more to the point, I would find it intuitive if picture expressions are
only affected by withcolor drawoptions.  And withpen and dashed options
only if they are directly applied to a draw operation.  But that would
of course be an incompatible change.


>>I can think of two causes for the problem:
>>[...]
> 
> Not really either of these. Rules in the dvi become paths in a picture
> and then draw <picture> applies drawoptions to paths in that picture.

Would it be difficult to mark paths originating from makempx (if that's
correct?) as immune to withpen or dashed drawoptions?


> Note that "label" is defined to mean "draw thelabel". To avoid
> that invokation of draw, try:
>    def addlabel = addto currentpicture also thelabel enddef;
> then
>    addlabel (btex 1000\euro etex, (50,0));

Thanks!  But it's difficult to apply that since gnuplot doesn't provide
hooks to inject such code.  I have a script driven process to do that
anyway, so for me it /does/ works (redefining label directly).  Thanks!

Best regards,
Stephan Hennig