On 2013-11-17 15:00-0000 Arjen Markus wrote: > Hi all, > > I just noticed that in example 33 the high cap is not being drawn. As this is > a fairly extensive > example with a lot of pages, I normally run it to get the PostScript output > for various languages only. > However, now I was running it interactively under Cygwin/Xwindow (on Windows > 7 to be complete) and > I noticed the missing high cap.
Hi Arjen: I am virtually positive the issue is the top cap is opaque black see and the background for the colorbar is semi-transparent black. See http://plplot.sourceforge.net/examples-data/demo33/x33.87.png, to see how this turns out for drivers that support alpha transparency. Also, please try c/x33c -dev svg -o test.svg -fam and then look at, for example, the eighth page, test.svg.8 with your best svg viewer (probably your browser). The top-cap is visible here on a semi-transparent background for the colourbar and should be for you as well. The opaque black on top of semitransparent black was a deliberate choice to show off the semi-transparent capabilities that are possible if the device driver supports an alpha transparency channel for the colours. But neither our PostScript driver psc nor the wingcc driver currently support alpha transparency so the result there opaque black cap on opaque black background and the top cap appears to disappear just like you have described. By the way, in general, converting a device to use the alpha channel is normally fairly straightforward if the format for the device supports alpha channel transparency. You can typically find the relevant code by just looking for any of .r, .g, .b, or .a in the device driver (while ignoring "e.g" strings just to keep it clean). Here are those results for svg. software@raven> grep -E '\.(r|g|g|a)' drivers/svg.c |grep -v e\.g if ( pls->curcolor.a < 0.99 ) write_hex( aStream->svgFile, pls->cmap1[i].r ); write_hex( aStream->svgFile, pls->cmap1[i].g ); fprintf( aStream->svgFile, "stop-opacity=\"%.3f\"/>\n", pls->cmap1[i].a ); write_hex( aStream->svgFile, pls->curcolor.r ); write_hex( aStream->svgFile, pls->curcolor.g ); fprintf( aStream->svgFile, "stroke-opacity=\"%f\"\n", pls->curcolor.a ); write_hex( aStream->svgFile, pls->curcolor.r ); write_hex( aStream->svgFile, pls->curcolor.g ); fprintf( aStream->svgFile, "fill-opacity=\"%f\"\n", pls->curcolor.a ); write_hex( aStream->svgFile, pls->cmap0[0].r ); write_hex( aStream->svgFile, pls->cmap0[0].g ); fprintf( aStream->svgFile, "fill-opacity=\"%f\"\n", pls->cmap0[0].a ); So the above tells you how to get alpha transparency information from the Plplot library (the easy part), and also how to supply that information appropriate to the format supplied by the device (easy here, but in general more difficult than the first part). For example, according to http://en.wikipedia.org/wiki/Transparency_(graphic)#Transparency_in_PostScript PostScript version 3 is the first version of that standard to supply full alpha support. So pscairo and epsqt results are semitransparent because they are written in PostScript version 3, but our psc device is not because it is written in PostScript version 2 format, and it presumably would be a big job and therefore not worth the effort to convert that result to PostScript version 3 since there are so many other PostScript devices that provide PostScript version 3. The -dev wingcc case is more interesting: software@raven> grep -E '\.(r|g|g|a)[^a-z]' drivers/wingcc.c |grep -v e\.g dev->oldcolour = SetBkColor( dev->hdc, RGB( pls->cmap0[0].r, pls->cmap0[0].g, pls->cmap0[0].b ) ); dev->oldcolour = SetBkColor( dev->hdc, RGB( pls->cmap0[0].r, pls->cmap0[0].g, pls->cmap0[0].b ) ); dev->colour = RGB( pls->curcolor.r, pls->curcolor.g, pls->curcolor.b ); dev->colour = RGB( pls->curcolor.r, pls->curcolor.g, pls->curcolor.b ); So clearly that device does not currently support alpha transparency, but if you look up that RGB macro (#defined in include/plfreetype.h) all it does is define a 24-bit integer with RGB bits in a particular pattern, and I am wondering if the Windows platform would automatically support a 32-bit integer with the alpha bits in the remaining 8 bits? My guess is yes, since there are other parts of that code that specifically goes out of its way to use an ETO_OPAQUE flag which I presume from the name is trying to tell Windows we are using the special case where we have deliberately turned off transparency. In sum, the top cap disappears if the device does not (currently) support alpha transparency, and I hope my speculation about the possibility of straightforwardly implementing alpha transparency for the wingcc device has given you some food for thought. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
