[metapost] problem with drawoptions and fake Euro symbol
mailing_list at arcor.de
Wed Nov 14 23:38:17 CET 2007
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
* 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
>>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
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;
> 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!
More information about the metapost