[NTG-context] metapost dashpattern (on 1) not shown in Mountain Lion Preview
mojca.miklavec.lists at gmail.com
Tue Sep 25 10:45:25 CEST 2012
On Tue, Sep 25, 2012 at 7:28 AM, Xiao-Yong Jin wrote:
> Dear all,
> I just upgrade to Mountain Lion and found out that "dashed dashpattern (on
> 1)" no longer shows any line in Preview. The attached file is a snapshot of
> the Preview window showing the pdf file generated by the following code.
> draw unitsquare scaled 4cm dashed dashpattern (on 1cm off 1cm) ;
> draw unitsquare scaled 4cm shifted (5cm,0) dashed dashpattern (on 1cm) ;
> draw unitsquare scaled 4cm shifted (10cm,0) dashed dashpattern (off 1cm) ;
> setbounds currentpicture to boundingbox currentpicture enlarged 0.1cm ;
> You can see, from the attached file, that the unitsquare which was
> supposed to appear in the middle does not show up in the Preview window.
> However the same file is displayed correctly in Acrobat Reader.
Just curious: what do you get if you try to draw the same plots with
PostScript terminal in gnuplot?
> I am not sure whether it is a context problem, or it is just a bug in
> Mountain Lion. I found out this issue when I saw that all the pdf files I
> previously generated with gnuplot context term are showing up incorrectly
> under the Preview after upgrading to Mountain Lion. I had to change the
> dash pattern in file "metapost/context/third/gnuplot/mp-gnuplot.mp", so the
> pdf generated by gnuplot context term can be viewed correctly with Preview
> under Mountain Lion.
What modifications did you do exactly?
It seems that "(on 1cm)" generates
[28.34645 0 ] 0 setdash
and "(off 1cm)" generates
 0 setdash
in PostScript file.
What I had in mind when I was writing the code was for "(on 1cm)" to generate
 0 setdash
meaning a solid line. The other pattern "(off 1cm)" for linetype -3 is
described in gnuplot's README as follows:
An lt of -3 is solid and drawn with xor (for temporary interactive
and I actually had no idea what to draw since PostScript cannot draw
XORed lines - I was most probably hoping to get an invisible line ;)
Thinking again about it, different transparency models in PDF are
actually able to do some weird transformations (color subtraction
etc.), but I'm not sure if I could get what I want.
Now, according to specification, the pattern
[28.34645 0 ] 0 setdash
should actually draw almost "a solid line", or, to be mathematically
precise, a line composed of 1cm long segments with zero-width gaps.
The difference might be evident when drawing semi-transparent lines
and linecaps might overlap. If you ask me, it's definitely a bug in
Mountain Lion's renderer if it doesn't draw the line. On the other
hand, it probably makes sense to patch MetaPost to generate " 0
setdash" instead of "[<x> 0 ] 0 setdash" in case when it gets "(on
<x>)" as an argument. But then again, the original code should
probably call dashpattern() without any argument to get solid lines.
The argument "(off 1cm)" is weird anyway (my "bug") and honestly I'm
not sure what would be the most appropriate behaviour in the eyes of
metapost. Maybe not drawing anything at all? Throwing an error?
Inserting "(on 0pt)" would be wrong as that actually draws dots. When
using "(off 1cm on 0cm)" it works as it should - it draws dots (when
using round linecaps).
I believe the best course of actions would be:
- Filing a bug to Apple with a minimal EPS example. (I can try to
prepare one.) But that won't help anyway. I've filed several bug
reports and the only time when they replied was with asking if it was
fixed when it wasn't. And 4 years have passed since, nothing happened.
- I will replace "dashpattern(on 1cm)" with "dashpattern()" for
linetype 0 and -2 in mp-gnuplot.mp. Can you please confirm if that
- After ConTeXt Meeting/EuroTeX is over, we could discuss with Taco
what MetaPost should do when it gets "(on 1cm)" or "(off 1cm)" as an
argument. If nothing else, the manual should clearly describe the
behaviour. Are you willing to open a ticket at
More information about the ntg-context