stripplot - boxplot not appearing - Stata 14 for Mac

[jpsanders]

Hi,
When I include the boxplot option when using the stripplot command, the boxplot doesn't show up:

sysuse auto, clear
stripplot mpg, over(rep78) box(barw(0.8) blcolor(ltblue)) centre vertical cumul cumpr mc(orange) scheme(s1color) yla(, ang(h))

Looks like a Stata for Mac issue as I had 2 colleagues try and the one on a PC sees the boxplot and the one on a Mac does not. Any insight on how to resolve?
Thanks,
James

[Marcos Almeida]

Hello "jpsanders",

Welcome to the Stata Forum/Statalist.

First, I just wish to underline that - stripplot - is a SCC, whose author is Nick Cox.

Second, I kindly ask you to re-register with full name.

Third, I recommend to share command and data under CODE delimiters or by installing the SSC datatex.

All these 3 remarks are underlined in the FAQ.

Thank you in advance.

[Nick Cox]

As Marcos mentions stripplot is a program of mine on SSC.

I just checked your example and it runs fine on Windows. The box plot is visible. Try varying the colour away from ltblue. Also confirm that everyone is setting the scheme to s1color

[William Lisowski]

If you and your Mac colleague are running Stata in full screen mode, you may have been bitten by the bug described in this thread.

http://www.statalist.org/forums/foru...the-same-issue

[James Sanders]

Thank you for your helpful responses.

Marcos,
I have re-registered with my full name and I will incorporate the other best practices included in the FAQ into future posts.

Nick,
I have confirmed that each person has specified the s1color scheme option. I tried several different color options including black and red to no avail. Pasting a copy of the Windows graph and Mac graph below for comparison.

Windows

Mac

William,
Thanks for the idea but I am able to get at least some of the graph elements to render. I confirmed graphs do not render at all when I am in full screen mode but I believe the issue here is different.

Sincerely,
James

[Marcos Almeida]

Thank you for re-registering, James. Also, thanks for having taken a look at FAQ. There are interesting tips concerning graphs which may interest you. If in doubt on how to apply some of them, you may use on the Sand Box so as "test" your commands as well.

[Nick Cox]

I can confirm that there is no code in stripplot that differs by operating system. Thus this is a Macintosh-specific problem with graph code. I'd recommend testing directly with twoway rbar code.

[James Sanders]

Thank you. As shown below, the twoway rbar command produces equivalent graphs on Windows and Mac. This may just be a Stata for Mac quirk/bug. I'll let them know.

sysuse sp500, clear
twoway rbar high low date, barwidth(.6) color(gs7) || line close date || in 1/57

Windows

Mac

[eric_a_booth]

Nick Cox Thanks for this update to -stripplot- on SSC, this program is very helpful for my daily work.

James Sanders issue, I toyed with the adofile and found that if I indiscriminately replaced all instances of these options for the rbar plots :

bcolor(none) blcolor(black) barw(0.4)

(there are 6 instances, not always written in this order though)

with this:

barw(0.4) lwidth(medium) bcolor(none) blcolor(black)

then running the OP code:

discard //because I saved a new version of stripplot
sysuse auto, clear
set scheme s1color
stripplot mpg, over(rep78) box(barw(0.8) blcolor(ltblue)) centre vertical cumul cumpr mc(orange) scheme(s1color) yla(, ang(h))

creates the graph attached. I dont actually know what's going on in terms of why this would be different on a Mac, but my method was to try the other rbar 'lookofbar' options until one worked -- by adding in the lwidth() option this seems to do what the barwidth() option isnt doing in this case.


I'm running updated Stata 13.1 on Mac osx 10.12.3 with -stripplot- updated today.

[Nick Cox]

Eric: That's interesting. Perhaps there is a small difference in how the twoway code is implemented in a Mac nearer to machine level. I would say it, but there is no OS-dependent code in my program.

[James Sanders]

Thank you Nick and Eric for your insights. I edited the .ado file per Eric's instructions and the graph now renders with boxplots included.

discard //because I saved a new version of stripplot
sysuse auto, clear
set scheme s1color
stripplot mpg, over(rep78) box(barw(0.8) blcolor(ltblue)) centre vertical cumul cumpr mc(orange) scheme(s1color) yla(, ang(h))

Output:

For what it is worth, I received the following information from one of Stata's technical service analysts:

I've actually seen this once before with -stripplot- on a Mac. The issue has to do with the width of the lines contained in the bars/boxes- the lines are too thin in pixels to appear correctly on the screen.

[Nick Cox]

That's sounds like progress except that I note that the default line width in stripplot is just the default line width for bars! Perhaps what is happening is that the default bar fill color is none, so that you will fail to see boxes unless you colour them in.

As for changing stripplot.ado on your machine, it's your machine and your copy of the file! But if I update stripplot and you want to update, then you may have a small problem.

[eric_a_booth]

When I was testing the rbar options in -stripplot- to see if I could get the bars/boxes to appear, the coloring options did nothing for me. The only solution I found was including the lwidth() option on the Mac OSX version of Stata.
I suspect that Nick's suggestion about treatment of linewidths nearer the machine level in Mac OS is correct, but I think the difference here is that the Mac OSX version is completely ignoring bwidth() for rbar and looking for lwidth().
( Importantly, I've included lwidth() in the rbar option of my -stripplot- and I'm keeping it as a seperate local version (called -stripplotrbar-) to avoid future update issues. )

However, I disagree with the Stata technical service input that the width of the lines are too thin to be seen; this is assuming they are talking about the lwidth or bwidth options, I've tested these options at the thinnest setting and they are still barely visible. The issue here, as Nick notes, is not -stripplot-, so I've included some code below to show how the bwidth and lwidth options operate using -tw rbar- on a Mac OSX (13.1). You can see how lwidth, even at it's thinnest, works but bwidth() seems to be ignored for Mac OSX (helping explain the OS difference observed for -stripplot- ).

For example/option 2, if I include the bwidth() option at very thin (<.1) or thicker (>.6) widths or if I leave it out all together it makes not difference for that graph on the Mac OS X machine. For any of these examples if I set bwidth() different from 'medium' the line thickness changes accordingly.

The attached pictures should upload in order of the examples, but if not you can see the matching titles.

**lwidth only
 sysuse auto, clear
set scheme s1color
bys rep78: egen x = mean(mpg)
tw (scatter mpg rep78) ///
    (rbar mpg x rep78, bcolor(none) lwidth(medium)) , title(lwidth option only)
    graph export opt1.png, as(png) replace
    
**lwidth and barwidth
 sysuse auto, clear
set scheme s1color
bys rep78: egen x = mean(mpg)
tw (scatter mpg rep78) ///
    (rbar mpg x rep78, bcolor(none) lwidth(medium) barw(0.4)), title(lwidth and barwidth options )
    graph export opt2.png, as(png) replace

**
 sysuse auto, clear
set scheme s1color
bys rep78: egen x = mean(mpg)
tw (scatter mpg rep78) ///
    (rbar mpg x rep78, bcolor(none) lwidth(vvthin) barw(0.7)), title(lwidth set to very very thin and bwidth set thicker than default)
    graph export opt3.png, as(png) replace

    
**barw only - no boxes**
 sysuse auto, clear
set scheme s1color
bys rep78: egen x = mean(mpg)
tw (scatter mpg rep78) ///
    (rbar mpg x rep78, barw(0.4) bcolor(none)  ), title( barwidth option only - similar to stripplot )
    graph export opt5.png, as(png) replace

[Chinh Nguyen (StataCorp)]

The short answer:

The box plots are being rendered with extremely thin lines (.0017 inches thin). The defaults are too thin and only look good on the screen in Windows.

The long answer:

Stata for Mac and Unix both support antialiasing to draw smooth lines and curves and can simulate thin lines by drawing them in lighter colors. Stata for Windows does not support antialiasing so a .0017 inch thin line still renders at a full pixel width. A Stata for Windows user can create graphs that look fine in Windows (and probably even MS Word) but don't look very good when exported to EPS or PDF or rendered on other operating systems. If you were to export the graphs above to PDF and viewed them in a PDF viewer, you'd see the extremely thin lines and I don't think it's the result you're looking for.

So why is Stata for Mac not displaying anything when it should be rendering thin lines? It's due to a problem when rendering adjoining polygons with antialiasing. On the Mac, Stata has to ignore line widths below a certain size (which include .0017 inches) and not render them otherwise you could see heavy artifacting due to colors bleeding through the antialiasing. You can see this artifacting by creating a contour plot on any platform, exporting the contour plot to EPS or PDF and then opening the exported file in a viewer (such as Adobe Acrobat).

For example, I entered

gr_example sandstone: twoway contour depth northing easting

then exported the graph as an EPS file* and opened up the file in a viewer. I then zoomed in on the graph. Look at the following screenshot of the graph opened in the viewer and you'll notice the artifacting around the red area. That's a result of the yellow polygons being drawn over the red area and the red leaking through due to a shortcoming of antialiasing. You might see different results depending on the zoom factor and how big your window is. If a user saw this result in Stata, they would assume it's a bug in Stata, not because of some limitation in the graphics renderer of the operating system. So Stata tries to prevent this from happening on the screen (and the following example isn't so bad... I've seen much worse). Note that printing is not affected because antialiasing only happens on the screen.

As far as the bwidth and lwidth options go, Stata for Mac's graph renderer doesn't know anything about them. Stata's graph renderer is working at such a low level that it doesn't know what kind of graph it's rendering (e.g. a box plot), only that it's been told to draw a polygon with a really thin line. Stata knows there's the potential for the output to look bad due to artifacting so Stata can either go ahead and render it as is or take steps to avoid the artifacting. Stata chooses to attempt to avoid the artifacting by not rendering extremely thin lines. The side effect of this decision is that some polygons in other kinds of graphs may not be visible but Stata for Mac is OK with that because you probably really didn't mean to render an extremely thin line.

Stata for Windows will one day support antialiased graphics too and will most likely encounter similar issues and have similar workarounds.

* Stata for Mac uses native PDF renderer on Mac so what you see on the screen is what is exported to disk. Windows and Unix use software-based PDF renderer so what you see on the screen may differ slightly from what is exported to disk. I exported to EPS instead because Stata uses its own EPS renderer across all platforms and I wanted to eliminate as many platform specific differences as possible.

[Chinh Nguyen (StataCorp)]

I'm now back at my office and have had a chance to look at the code. What I wrote previously doesn't completely apply in this case because the box plots are just drawn with rectangles, not polygons.

What it boils down to is that the line width is much too thin to be visible (it's set to vvv.thin) on the Mac. For the first example, the line width Stata's rendering engine was told to draw the box plot at was 0.000004 of a pixel at my graph's current window size and for rectangles, Stata uses whatever line width is given. It's visible in the Unix GUI because we imposed a minimum line width of 0.5 pixels (any less and the line isn't rendered by the Unix graphics renderer). We didn't impose a minimum on the Mac but I just determined it's about 0.1 pixels before no line is visible. It's visible in Windows because Windows will always render at least a pixel width. I would expect that in PDF and EPS viewers such as Adobe Acrobat, they're doing something similar and using a minimum line width too. The reason you may want to impose a minimum line width is that for a graph with intentionally thin lines that are visible when the graph is large, you don't want the lines to disappear if you resize the graph to a smaller size.

stripplot may need to set its own default line width and not rely on Stata's. I'll ask the graph scheme's author why he chose vvv.thin.

And FWIW, I just checked and the graphics engine Stata uses in Windows will render a line with a width of 0 as a solid line.