On 2015-03-20 08:46-0400 Hazen Babcock wrote: > 5. Use a library (Freetype?) for rendering text instead of delegating > this to the driver? The driver would instead be responsible for the > display of the resulting bitmaps. This would finally solve the problem > of the text looking slightly different on all the drivers. It would also > make writing new drivers easier as text handling is far and away the > most difficult thing to implement correctly. Maybe this would not work > so well with pdf and postscript drivers, so we'd need to preserve the > driver rendered text option?
This text rendering approach is too simplified and not what we want at all. Here is why. Rendering text properly (e.g., for complex text layout languages like Arabic, Hindi, and Hebrew) is an extremely difficult job that has taken years of development for the Qt, pango/cairo, and wxwidgets software libraries to get right. And similarly for the SVG rendering libraries used by SVG viewers. But as a result of these external efforts we have near perfect text rendering for, e.g., example 24 for our qt, cairo, wxwidgets, and psttf (which depends on libLASi which in turn depends on pango/cairo) device drivers, and also our svg device driver (when those results are viewed by an SVG viewer). As a result, people throughout the world can use those device drivers with confidence that they will not mess up their text no matter what language and script that text is being expressed in, and that is a great internationalization accomplishment we can all be proud of. But there is no way we could develop software to render complex text layout languages ourselves so the status quo for all the above device drivers is what we want. That said, I do like the idea of using the plfreetype approach for the rest of our devices assuming we make one fundamental change to plfreetype which is to automate the glyph selection using fontconfig. The reason this change is necessary is that the current plfreetype glyph selection frankly sucks because the user is forced to select in advance the exact font that they want (by directory and filename) for each of the 30 generic possibilities (appropriate combinations of sans, serif, monotype, script, symbol, bold, italic, oblique, etc.), and they are SOL if they want to change fonts in the middle of a string (for the common case when a glyph is missing for the font they selected). Constrast this current lame plfreetype glyph selection approach with what happens with fontconfig where that library automatically searchs all system unicode fonts (for the specified generic font family) for the best choice of glyph for the specified unicode code point. Note that with fontconfig "best" can be configured by the user, but usually they don't do that because the default fontconfig definition of "best" is usually completely satisfactory. Even though freetype and fontconfig are available on all platforms some users will still prefer not to install those (soft) prerequisites for PLplot in which case PLplot must fall back to using the Hershey font approach. But in most cases users will want to make the effort to build or install freetype and fontconfig since the glyphs look better and there are many more of them compared to the Hershey font approach. The drawback of using either the plfreetype or the Hershey font approach is the text layout will be a simple left-to-right approach and therefore give completely incorrect results for complex text layout languages. But that is OK if that limitation is clearly stated up front for devices that use either of these approaches. Finally, there is the question of the wingcc device which currently uses the unmodified plfreetype approach. Clearly, the modified plfreetype approach would be a nice improvement for that device, but my understanding is that Windows platforms now do provide proper complex text layout rendering so eventually someone will likely want to convert the wingcc device from the (modified) plfreetype approach to Windows complex text layout in order to internationalize that device. 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 __________________________ ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
