Menu
▾
▴
plplot-devel
|
From: <he...@co...> - 2015-05-13 18:21:44
|
Jim,<br><br>That sounds like a good place to start.<br><br>Would you mind posting it? Or maybe it's in an early branch of the code?<br><br>Thanks,<br><br>Aaron.<br><br><br>Sent from XFINITY Connect Mobile App<br>-----Original Message-----<br><br>From: ji...@di...<br>To: ir...@be...<br>Cc: Plp...@li...,he...@co...<br>Sent: 2015-05-13 13:03:32 GMT<br>Subject: Re: [Plplot-devel] Using Window's raw API for shapes and text<br><br>I still have the revised windows driver that I can blow the dust off and offer as a possible replacement. <br><br><br><br>> On May 13, 2015, at 1:59 PM, Alan W. Irwin <ir...@be...> wrote:<br>> <br>> Hi Aaron:<br>> <br>> I am putting this further discussion on the plplot-devel mailing list<br>> since some developers there have more device expertise than I do (and<br>> also a lot more Windows expertise) and therefore will likely want to<br>> contribute to the discussion.<br>> <br>>> On 2015-05-13 07:37-0500 Aaron Hexamer wrote:<br>>> <br>>> [....] I've been wondering is if it<br>>> would be feasible to make a driver that uses more of Window's raw API for<br>>> shapes and text, thus avoiding the need for libs like Qt, Cairo-Pango, etc.<br>>> - one would still get portability through other drivers on other platforms.<br>>> It looks like wingcc is somewhat like that, but preferred to use Freetype.<br>>> I gather from looking at the history that text rendering is challenging,<br>>> especially around vertical alignment topics.<br>> <br>> For your information, the plfreetype approach is strongly deprecated. <br>> The primary reason for this is the user can only control the selection<br>> of the needed font files at cmake time or else at run-time via<br>> environment variables which is a very clumsy approach. A secondary<br>> reason is the plfreetype approach only works for simple text layout<br>> (left-to-right) languages. Instead, our preferred approach is to rely<br>> on external libraries such as pango/cairo/fontconfig, Qt, or wxwidgets<br>> to automatically select the best system font (of the sans, serif,<br>> normal weight, bold, etc., generic classes of fonts that PLplot<br>> supports) to render each unicode glyph encountered (which<br>> automatically allows multi-language plots such as example 24) and to<br>> do the required (complex) text layout.<br>> <br>> Thus, I agree that the plfreetype approach used by wingcc (the last<br>> device driver that still uses that approach) should be completely<br>> replaced by calling the appropriate native Windows API for selecting<br>> the best system font to render each unicode glyph that is encountered<br>> and to do the text layout.<br>> <br>> I think in the past that Arjen Markus has commented this approach<br>> should be possible, but he has not had time to pursue it further.<br>> Also, my understanding is that Jim Dishaw has worked on implementing a<br>> Windows device driver. I am not sure what the status of that project<br>> is, but he might have some comments also about the feasibility of<br>> modifying wingcc this way.<br>> <br>> Anyhow, if you feel such modification of wingcc is possible, I would<br>> encourage you to give it a try following, say, the broad outline of<br>> the alt_unicode text handling that is done in drivers/cairo.c.<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>> <br>> ------------------------------------------------------------------------------<br>> One dashboard for servers and applications across Physical-Virtual-Cloud <br>> Widest out-of-the-box monitoring support with 50+ applications<br>> Performance metrics, stats and reports that give you Actionable Insights<br>> Deep dive visibility with transaction tracing using APM Insight.<br>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y<br>> _______________________________________________<br>> Plplot-devel mailing list<br>> Plp...@li...<br>> https://lists.sourceforge.net/lists/listinfo/plplot-devel<br> |
|
From: <he...@co...> - 2015-05-14 15:51:39
|
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 application still using XP. I can't tell without some more research, but I think Windows 10 even supports GDI/GDI+.<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 detected OS is > WinXP?<br><br>Thanks,<br><br>Aaron.<br><br>Sent from XFINITY Connect Mobile App<br>-----Original Message-----<br><br>From: ir...@be...<br>To: he...@co...<br>Cc: Plp...@li...<br>Sent: 2015-05-13 23:11:24 GMT<br>Subject: RE: [Plplot-devel] Using Window's raw API for shapes and text<br><br>On 2015-05-13 21:44-0500 Aaron Hexamer wrote:<br><br>> Would it be developed using the GDI? If so, then maybe wingdi?<br><br>Hi Aaron:<br><br>To respond to your first question even though I am not<br>that familiar with Windows, I did look up the article at<br><http://en.wikipedia.org/wiki/Graphics_Device_Interface>, and it<br>appears that is an old API that has been replaced with the Direct2D<br><http://en.wikipedia.org/wiki/Direct2D> API.<br>I then followed up with some google<br>searching to find<br><https://msdn.microsoft.com/en-us/library/windows/desktop/ff729481(v=vs.85).aspx><br>which implies you can use gdi for graphics and DirectWrite for text or<br>Direct2D for graphics and DirectWrite for text. Furthermore,<br><http://en.wikipedia.org/wiki/DirectWrite> says one of the features is<br><br>"Comprehensive support for Unicode, with over 20 scripts providing<br>layout and rendering of every language supported in Windows."<br><br>So that superficially sounds like exactly what we want to use (in<br>combination with either GDI or Direct2D), but remember my Windows<br>knowledge is quite limited and this research just took me a few<br>minutes of google searching so if our Windows developers have a<br>different preference for the Windows API that is used to render<br>unicode text, then we should adopt that preference.<br><br>@Aaron: I do think your general idea of the win+API name is better<br>than winwidgets. So I would be happy to use wingdi or windirect2d<br>depending on the decision about which one is used in conjunction with<br>DirectWrite.<br><br>@Jim, Arjen, and Phil:<br><br>As our most active Windows developers please chime in about what<br>Windows API you think we should use to render unicode text, and the<br>name you would like to see for what is currently called the wingcc<br>device driver.<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> |
|
From: Jim D. <ji...@di...> - 2015-05-14 15:57:36
|
The code that I currently have uses GDI, so we can start from there. > On May 14, 2015, at 11:51 AM, he...@co... 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+. > > 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? > > Thanks, > > Aaron. > > Sent from XFINITY Connect Mobile App > -----Original Message----- > > From: ir...@be... > To: he...@co... > Cc: Plp...@li... > Sent: 2015-05-13 23:11:24 GMT > Subject: RE: [Plplot-devel] Using Window's raw API for shapes and text > > On 2015-05-13 21:44-0500 Aaron Hexamer wrote: > > > Would it be developed using the GDI? If so, then maybe wingdi? > > Hi Aaron: > > To respond to your first question even though I am not > that familiar with Windows, I did look up the article at > , and it > appears that is an old API that has been replaced with the Direct2D > API. > I then followed up with some google > searching to find > > which implies you can use gdi for graphics and DirectWrite for text or > Direct2D for graphics and DirectWrite for text. Furthermore, > says one of the features is > > "Comprehensive support for Unicode, with over 20 scripts providing > layout and rendering of every language supported in Windows." > > So that superficially sounds like exactly what we want to use (in > combination with either GDI or Direct2D), but remember my Windows > knowledge is quite limited and this research just took me a few > minutes of google searching so if our Windows developers have a > different preference for the Windows API that is used to render > unicode text, then we should adopt that preference. > > @Aaron: I do think your general idea of the win+API name is better > than winwidgets. So I would be happy to use wingdi or windirect2d > depending on the decision about which one is used in conjunction with > DirectWrite. > > @Jim, Arjen, and Phil: > > As our most active Windows developers please chime in about what > Windows API you think we should use to render unicode text, and the > name you would like to see for what is currently called the wingcc > device driver. > > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
|
From: Alan W. I. <ir...@be...> - 2015-05-14 18:42:14
|
On 2015-05-14 11:57-0400 Jim Dishaw wrote: > The code that I currently have uses GDI, so we can start from there. Sounds good. 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 __________________________ |
|
From: Alan W. I. <ir...@be...> - 2015-05-14 20:00:26
|
On 2015-05-14 15:51-0000 he...@co... 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 __________________________ |
|
From: <he...@co...> - 2015-05-14 20:35:14
|
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> |
|
From: Phil R. <p.d...@gm...> - 2015-05-21 22:39:15
|
Hi Jim, Alan et al Some (rather late) input into all this. GDI is the oldest windows rendering API in use. Its major disadvantage is that it does not support antialiasing so the out put is not very good, however it does support hardware acceleration. GDI+ was the successor. It gives you antialiasing but does not support hardware acceleration. Direct2D is I think a split off from DirectX. if I am not mistaken then a significant portion of that functionality is available within DirectX9 which was probably available on XP, but I am now pushing the limits of my knowledge. DirectX (and by extension Direct2D) supports hardware acceleration. I think antialiasing is supported in Direct2D, but not in older versions of DirectX. I know most of this stuff because on Windows wxWidgets uses GDI for its wxPaintDC, but GDI+ for its wxGraphicsContext - which was the difference between the wxDC and wxGraphicsContext backends of PLPlot. I've never used either directly. I have used DirectX9 once (actually by mistake, I should really have used a more modern version). If you want to go down this route you need to get your head around the COM model - which is basically object oriented C. If you are interested let me know (this model might be useful for PLPlot memory management). I then used a bit of Direct2D, which was neither easier nor harder than DirectX and there are come crossover functions needed I think so you end up learning both. I actually started writing a wxDirect2DFrame class that allowed rendering to a wxWindow with Direct2D, but once I got it good enough for that project I never finished it off. Regarding text, uniscribe has as noted earlier been superseded by directText, but I don't know how far back such compatibility goes. I do have some code that I once wrote intending to push into PLplot (but again never finished) that took uniscribe as a layout engine and then used FreeType for the actual glyph rendering. It should be noted that we are a little unfair to FreeType. FreeType is not a layout engine it is a rendering engine - it just renders the glyphs it is told to from the font files you tell it. The layout engine needs to do things like decide text direction. My concept was that if we had the Uniscribe layout engine on Windows and Harfbuzz on Linux then Freetype could do the rendering on both to give the same style. Anyway if that code is any good to you then let me know and I'll send it over. In terms of what we "should" do. I agree that we probably should still support XP. However, that is probably like us trying to support Ubuntu 5. Maybe a more modern system would be more beneficial in the long run. Perhaps we could leave the wingcc for legacy use, but develop using Direct2D for the new system (call it wind2d or something) rather than deliberately choosing to use a system that is becoming depreciated. Phil Phil On 14 May 2015 at 21:35, <he...@co...> wrote: > Alan, > > 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. > > Thanks, > > Aaron. > > > Sent from XFINITY Connect Mobile App > -----Original Message----- > > From: ir...@be... > To: he...@co...,ji...@di... > Cc: Plp...@li... > Sent: 2015-05-14 15:00:20 GMT > Subject: RE: [Plplot-devel] Using Window's raw API for shapes and text > > On 2015-05-14 15:51-0000 he...@co... 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 > . > > 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 > . > > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
|
From: Alan W. I. <ir...@be...> - 2015-05-22 02:21:20
|
On 2015-05-21 23:39+0100 Phil Rosenberg wrote: > Regarding text, uniscribe has as noted earlier been superseded by > directText, but I don't know how far back such compatibility goes. I > do have some code that I once wrote intending to push into PLplot (but > again never finished) that took uniscribe as a layout engine and then > used FreeType for the actual glyph rendering. It should be noted that > we are a little unfair to FreeType. FreeType is not a layout engine it > is a rendering engine - it just renders the glyphs it is told to from > the font files you tell it. The layout engine needs to do things like > decide text direction. My concept was that if we had the Uniscribe > layout engine on Windows and Harfbuzz on Linux then Freetype could do > the rendering on both to give the same style. Anyway if that code is > any good to you then let me know and I'll send it over. Hi Phil: My two objections to the current plfreetype approach are its clunky selection of fonts (by file name rather than by generic sans, serif, etc., font type search for the best system font with the desired generic characteristic to render a single unicode glyph) and its inability to deal with complex text layout. However, it sounds like those two objections are answered by the concept you describe above if working indirectly through an improved plfreetype is the approach Jim and Aaron decide to take with the wingcc upgrade. And an improved plfreetype with the above objections answered would certainly give a huge boost to the gd device driver (also dependent on plfreetype) back from its current course toward complete retirement. 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 __________________________ |
|
From: Jim D. <ji...@di...> - 2015-05-13 20:15:36
|
I never sent it up. I'm away foe my machine, so I will send it in a few days. > On May 13, 2015, at 2:21 PM, he...@co... wrote: > > Jim, > > That sounds like a good place to start. > > Would you mind posting it? Or maybe it's in an early branch of the code? > > Thanks, > > Aaron. > > > Sent from XFINITY Connect Mobile App > -----Original Message----- > > From: ji...@di... > To: ir...@be... > Cc: Plp...@li...,he...@co... > Sent: 2015-05-13 13:03:32 GMT > Subject: Re: [Plplot-devel] Using Window's raw API for shapes and text > > I still have the revised windows driver that I can blow the dust off and offer as a possible replacement. > > > > > On May 13, 2015, at 1:59 PM, Alan W. Irwin wrote: > > > > Hi Aaron: > > > > I am putting this further discussion on the plplot-devel mailing list > > since some developers there have more device expertise than I do (and > > also a lot more Windows expertise) and therefore will likely want to > > contribute to the discussion. > > > >> On 2015-05-13 07:37-0500 Aaron Hexamer wrote: > >> > >> [....] I've been wondering is if it > >> would be feasible to make a driver that uses more of Window's raw API for > >> shapes and text, thus avoiding the need for libs like Qt, Cairo-Pango, etc. > >> - one would still get portability through other drivers on other platforms. > >> It looks like wingcc is somewhat like that, but preferred to use Freetype. > >> I gather from looking at the history that text rendering is challenging, > >> especially around vertical alignment topics. > > > > For your information, the plfreetype approach is strongly deprecated. > > The primary reason for this is the user can only control the selection > > of the needed font files at cmake time or else at run-time via > > environment variables which is a very clumsy approach. A secondary > > reason is the plfreetype approach only works for simple text layout > > (left-to-right) languages. Instead, our preferred approach is to rely > > on external libraries such as pango/cairo/fontconfig, Qt, or wxwidgets > > to automatically select the best system font (of the sans, serif, > > normal weight, bold, etc., generic classes of fonts that PLplot > > supports) to render each unicode glyph encountered (which > > automatically allows multi-language plots such as example 24) and to > > do the required (complex) text layout. > > > > Thus, I agree that the plfreetype approach used by wingcc (the last > > device driver that still uses that approach) should be completely > > replaced by calling the appropriate native Windows API for selecting > > the best system font to render each unicode glyph that is encountered > > and to do the text layout. > > > > I think in the past that Arjen Markus has commented this approach > > should be possible, but he has not had time to pursue it further. > > Also, my understanding is that Jim Dishaw has worked on implementing a > > Windows device driver. I am not sure what the status of that project > > is, but he might have some comments also about the feasibility of > > modifying wingcc this way. > > > > Anyhow, if you feel such modification of wingcc is possible, I would > > encourage you to give it a try following, say, the broad outline of > > the alt_unicode text handling that is done in drivers/cairo.c. > > > > 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 > > Plp...@li... > > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X