Re: [Plplot-devel] Using Window's raw API for shapes and text

[<he...@co...>]

Alan, <br><br>That makes sense to me.  I can see how the configure/build time checks make sense to affect which support to attempt compile-in.  E.g. if one were building with an older compiler on an XP host, you wouldn't want to try to link in Direct2D support.  OTOH, what I actually had in mind was runtime detection to use the most effective version available on the target platform.<br><br>Thanks,<br><br>Aaron.<br><br><br>Sent from XFINITY Connect Mobile App<br>-----Original Message-----<br><br>From: ir...@be...<br>To: he...@co...,ji...@di...<br>Cc: Plp...@li...<br>Sent: 2015-05-14 15:00:20 GMT<br>Subject: RE: [Plplot-devel] Using Window's raw API for shapes and text<br><br>On 2015-05-14 15:51-0000 he...@co... wrote:<br><br>> Alan,<br>> <br>> One potential downside of the newer Direct2D/DirectWrite APIs is that they aren't supported on Windows XP. I know I have users of my<br>> application still using XP. I can't tell without some more research, but I think Windows 10 even supports GDI/GDI+.<br>><br><br>Hi Aaron:<br><br>Since Windows XP is an important requirement for you, then it appears<br>(again from my rather superficial google searching) that to render<br>unicode text with raw Windows API you must use GDI in combination with<br>the predecessor to DirectWrite which is Uniscribe<br><http://en.wikipedia.org/wiki/Uniscribe>.<br><br>Jim's later post in this thread said he would start with GDI so I<br>expect once he replaces the plfreetype approach for rendering unicode<br>text with raw Windows API for doing the same task he will be moving to<br>GDI/Uniscribe (if his reference to "GDI" did not actually<br>already mean GDI/Uniscribe).  And I am pretty sure from my reading that<br>GDI/Uniscribe is supported for Windows XP and all later Microsoft<br>versions.<br><br>> If the case for using Direct2D/DirectWrite is compelling enough, maybe they could be supported in addition to GDI and only used if the<br>> detected OS is > WinXP?<br><br>I think this is a good idea once it is confirmed that the GDI/Uniscribe<br>approach works fine. From my reading the advantages of<br>Direct2D/DirectWrite are considerable (e.g., vector graphics rather<br>than bitmapped).  And it should be straightforward to provide<br>CMake code to test whether Direct2D/DirectWrite is available, and<br>if so, provide the user the option to use Direct2D/DirectWrite<br>rather than GDI/Uniscribe.<br><br>But with regard to Jim's enhanced version of drivers/wingcc.c it<br>it seems to me the implementation order should be<br><br>1. GDI/plfreetype.  This approach will give the wrong glyph<br>order for the Arabic, Hebrew, and Hindi "peace" words<br>in example 24 and may have trouble finding the appropriate<br>fonts for all those languages, i.e., certain glyphs will<br>be missing.<br><br>2. GDI/Uniscribe (i.e., completely replace the use of the plfreetype<br>API with Uniscribe API).  Once implemented, the GDI/Uniscribe<br>combination should be tested by running example 24 and confirming that<br>it produces correct results (i.e., all Peace words present and having<br>the correct glyph order (i.e., as demonstrated at<br><http://plplot.sourceforge.net/examples.php?demo=24>.<br><br>3. Add the additional possibility (depending on a macro set by the<br>CMake logic referred to above) of using the Direct2D/DirectWrite API<br>instead of the GDI/Uniscribe API.  (Again with a check that example 24<br>works properly.)<br><br>Note, we want to get rid of all use of plfreetype so if Jim's<br>reference to his driver already using GDI actually referred to<br>GDI/Uniscribe, then he should ignore 1 and start with the example 24<br>test recommended in 2. above.<br><br>Alan<br>__________________________<br>Alan W. Irwin<br><br>Astronomical research affiliation with Department of Physics and Astronomy,<br>University of Victoria (astrowww.phys.uvic.ca).<br><br>Programming affiliations with the FreeEOS equation-of-state<br>implementation for stellar interiors (freeeos.sf.net); the Time<br>Ephemerides project (timeephem.sf.net); PLplot scientific plotting<br>software package (plplot.sf.net); the libLASi project<br>(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);<br>and the Linux Brochure Project (lbproject.sf.net).<br>__________________________<br><br>Linux-powered Science<br>__________________________<br>