metapost dashpattern (on 1) not shown in Mountain Lion Preview
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. \starttext \startMPpage 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 ; \stopMPpage \stoptext 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. 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. Best, Xiaoyong
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.
\starttext \startMPpage
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 ; \stopMPpage \stoptext
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.
Awesome ;) 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 annotations). 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 works? - 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 http://tracker.luatex.org? Mojca
On Sep 25, 2012, at 5:45 PM, Mojca Miklavec
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.
\starttext \startMPpage
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 ; \stopMPpage \stoptext
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.
Awesome ;)
Just curious: what do you get if you try to draw the same plots with PostScript terminal in gnuplot?
The PostScript terminal in gnuplot works fine. However, if I wrap the metapost code in my previous message with begin/endfig and run it with "mpost" to generate postscript, Preview does not show lines with "dashpattern (on 1)" either.
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?
I simply changed "on" to "off" for line type -2 and 0.
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 annotations). 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.
Simply call dashpattern() works as expected.
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 works? - 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 http://tracker.luatex.org?
I'm not sure what to put in the ticket. I guess it is more appropriate if you can open a ticket, since you know the details of the matter. Best, Xiaoyong
Mojca ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
participants (2)
-
Mojca Miklavec
-
Xiao-Yong Jin