On 2012-04-26 22:27+0100 Andrew Ross wrote: > > Phil, > > Do you have a small test program to illustrate this? It would be useful to > check other drivers with. I suspect you are right in that this is on a > driver-by-driver basis. > > Actually, it's pretty trivial to make a quick check. I just tried putting > a \n into the label of the x00 plot. A very quick look at some common > drivers suggests that > > xcairo, epsqt, pscairo, jpgqt support line breaks. > xwin, qtwidget, wxwidgets, psc don't support line breaks but produce some > strange symbol instead. > > Note I think this is different to your experience with wxwidgets so it may > even be library version dependent. Can you confirm with my simple test and > the wxwidgets driver? I have wxwidgets 2.8 installed. > > So it looks like there is no consistency in approach at the moment. I > guess the first step is to decide what we think should happen.
To Phil and Andrew: I was curious about this issue so I made a simple test example called test_linebreak.py in examples/python (revision 12192). You can run and test this as follows in the build tree configured with -DBUILD_TEST=ON: make _plplotcmodule #to build python interface to PLplot make python_examples #to set up python environment in the build tree examples/python/test_linebreak.py -dev svg -o test.svg display test.svg The new test_linebreak.py example uses utf8 "Peace" strings from a variety of scripts followed by an identification of the language/script in English. The strings are output in groups of two which are delimited by an "\n" string between the two strings. So for Hebrew and Arabic as the second member of the group you have the interesting case of "\n" followed by utf8 for right-to-left scripts. Only the svg and cairo devices give what I think is the correct rendering result which is a second line which is _right_-justified for the right-to-left scripts. The qt devices render the whole second line as _left_-justified in this case which I think must be wrong for a string started with a right-to-left script. The other issue revealed by this script is a vertical text alignment problem (sigh) for cairo devices. I am pretty sure one of the other simple python test scripts illustrates that same issue. In reference to Andrew's last paragraph above, I don't think anything should happen for most of our old-fashioned devices (e.g., xwin) that don't understand utf8 since most of those devices are in minimal maintenance mode in any case. For modern utf8-aware device drivers like svg, psttf, cairo, and qt we also shouldn't do anything because generally (except for the possible bug mentioned above in how Qt4 handles justification for right-to-left scripts) they handle rendering of utf8 strings and CTL (complex text layout) language scripts (including "\n" characters) correctly. -dev wxwidgets is a special case. Right now for the wxGC version of this device driver (default for my Debian squeeze platform with wxwidgets 2.8.10.1-3+b1) there is no recognition of utf8 (or line feeds) at all. Personally, I think wxGC is the only way forward for this device since the other two versions of this device driver have some major rendering issues. For example, both the "AGG" and "DC" versions of the wxwidgets device use our own plfreetype approach for rending text which has been deprecated for years because its' font-handling capabilities are frankly awful (you must specify the exact file you want to use for the font rather than a more modern approach where you simply give "sans" or "serif" generic hints and the best appropriate glyph is found ). plfreetype is also deprecated because it doesn't render CTL language scripts correctly, and it takes a very large amount of work and expert knowledge to get that right. Anyhow, plfreetype is a dead-end and I think any code based on it (such as all versions of wxwidgets other than wxGC) is also a dead end. The most important issue at this time is our wxwidgets device driver has not been maintained for years in any of its 3 variants. I assume (those interested in the wxwidgets platform please correct me if this assumption is wrong) that the wxwidgets wxGC platform actually now does have the capability to render utf8 and "\n" characters for CTL languages correctly. (I would frankly be amazed if wxwidgets users would put up with such a deficiency in their platform this long after both cairo and Qt have essentially solved this rendering issue.) I further assume that our wxwidets device driver simply needs some maintenance to take advantage of the utf8, CTL capability for the wxwidgets wxGC platform. But we will need a volunteer who is interested in the wxwidgets wxGC platform to (a) verify my assumption and (b) if that assumption is correct update the wxwidgets device driver for the wxGC case appropriately. Of course, if investigation shows the wcGC platform does not handle utf8 (including "\n") or CTL correctly, then perhaps wxwidgets should just continue to be in low-maintenance mode. Phil, I would be interested in whether you could verify my assumption. 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 __________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
