Re: [Plplot-devel] High cap missing

[Alan W. I. <ir...@be...>]

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
__________________________