On 2015-05-14 15:51-0000 hexa...@comcast.net wrote: > Alan, > > 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 > application still using XP. I can't tell without some more research, but I > think Windows 10 even supports GDI/GDI+. >
Hi Aaron: Since Windows XP is an important requirement for you, then it appears (again from my rather superficial google searching) that to render unicode text with raw Windows API you must use GDI in combination with the predecessor to DirectWrite which is Uniscribe <http://en.wikipedia.org/wiki/Uniscribe>. Jim's later post in this thread said he would start with GDI so I expect once he replaces the plfreetype approach for rendering unicode text with raw Windows API for doing the same task he will be moving to GDI/Uniscribe (if his reference to "GDI" did not actually already mean GDI/Uniscribe). And I am pretty sure from my reading that GDI/Uniscribe is supported for Windows XP and all later Microsoft versions. > If the case for using Direct2D/DirectWrite is compelling enough, maybe they > could be supported in addition to GDI and only used if the > detected OS is > WinXP? I think this is a good idea once it is confirmed that the GDI/Uniscribe approach works fine. From my reading the advantages of Direct2D/DirectWrite are considerable (e.g., vector graphics rather than bitmapped). And it should be straightforward to provide CMake code to test whether Direct2D/DirectWrite is available, and if so, provide the user the option to use Direct2D/DirectWrite rather than GDI/Uniscribe. But with regard to Jim's enhanced version of drivers/wingcc.c it it seems to me the implementation order should be 1. GDI/plfreetype. This approach will give the wrong glyph order for the Arabic, Hebrew, and Hindi "peace" words in example 24 and may have trouble finding the appropriate fonts for all those languages, i.e., certain glyphs will be missing. 2. GDI/Uniscribe (i.e., completely replace the use of the plfreetype API with Uniscribe API). Once implemented, the GDI/Uniscribe combination should be tested by running example 24 and confirming that it produces correct results (i.e., all Peace words present and having the correct glyph order (i.e., as demonstrated at <http://plplot.sourceforge.net/examples.php?demo=24>. 3. Add the additional possibility (depending on a macro set by the CMake logic referred to above) of using the Direct2D/DirectWrite API instead of the GDI/Uniscribe API. (Again with a check that example 24 works properly.) Note, we want to get rid of all use of plfreetype so if Jim's reference to his driver already using GDI actually referred to GDI/Uniscribe, then he should ignore 1 and start with the example 24 test recommended in 2. above. 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 __________________________ ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel