Hi Andrew
I've just found a moment to work out how to build the examples - I hadn't done it before.
 
I've just run example x01c and x01 using the wxWidgets DC driver and the postscript driver as selected from the menu. I don't see any problems.
 
Before I start searching through code trying to work out why mine is different to yours, I sent out a second version of the patch - are you definitely using this and not the first version?
 
If you're using the correct version then I will check I haven't got something odd going on on my machine, perhaps some change I made to my copy of the code didn't end up in the patch for some reason.

Phil
 
From: Andrew Ross <andrewross@users.sourceforge.net>
To: phil rosenberg <philip_rosenberg@yahoo.com>
Cc: "plplot-devel@lists.sourceforge.net" <plplot-devel@lists.sourceforge.net>
Sent: Monday, 13 August 2012, 23:07
Subject: Re: [Plplot-devel] Fw: wxWidgets driver and line breaks (fwd)


Phil,

Sorry for the delay but I've (finally) got round to testing your patch.

There seem to be some issues at the moment. At least on my Ubuntu system
I see a number issues with plot titles being incorrectly centred for the
standard C examples. This doesn't seem entirely consistent. For example
with the 4 subfigures in x01c, the top two are fine, but the bottom two
have the titles way off to the right.

Do you see this behaviour? Everything works fine without the patch.

Regards

Andrew

On Mon, Jul 16, 2012 at 01:44:23PM -0700, phil rosenberg wrote:
> Hi All.
> I recently discovered some inconsistencies with newlines in the wxWidgets driver. These include:
> The wxDC backend ignores newlines completely, as does the?wxAGG backend when using FreeType
> The wxAGG backend without FreeType renders newlines as a star-like?glyph
> The wxGraphicsContext backend has some support for newlines, however alignments are not dealt with correctly and if the text includes sub/super script as well as newlines?then the rendering goes very wrong.
> Presumably other drivers using FreeType or?lacking their own?text rendering?lack newline support.
> ?
> After some discussion with Alan I've generated a patch to provide newline support for wxGraphicsContext, WxDC and FreeType, attached. I've tested this with, slanted text, and with super/subscript. The line spacing is hardcoded simply to a value that I thought looked okay for each Backend. Extra line spacing is added for super/subscript.
> i don't know if anyone else on this list would like to take the patch and test it or if this patch is okay to go into the trunk version of plplot?
> ?
> Adding newline support to the wxAGG backend requires modifications to the plsym file and will also give newline support to any other drivers which use the plplot core capabilities to render text. I wrote most of this patch but then realised that to deal with text styles and sub/super script that spans multiple lines requires the current style, scale and offset to be recorded between each line. This would mean additions to the plstream structure. It already required adding the justification as an argument to the plstr function.
> ?
> Before I go any further with this patch I wanted to see if such changes would be acceptable to the devs?
> ?
> Any thoughts most welcome and I hope the patch as it stands to date is usefull
> ?
> All the best
> ?
> Phil
> ?

> ----- Forwarded Message -----
> From: phil rosenberg <philip_rosenberg@yahoo.com>
> To: Alan W. Irwin <irwin@beluga.phys.uvic.ca>
> Cc: Andrew Ross <andrewross@users.sourceforge.net>
> Sent: Saturday, 14 July 2012, 17:58
> Subject: Re: [Plplot-devel] wxWidgets driver and line breaks (fwd)

>
> Hi again
> Unfortunately I found a problem with the patch whereby sub/superscript, changes in font etc were not being carried over newlines. I have fixed this bug in the wxWidgets and freetype files. However, it is a bit more tricky to fix in plsym, because the plstrl function always assumes that the character height at the start of the line can be determined by plgetchr, which is not the case if subs/superscript traverse newlines causing incorrect alignment. Of course it is possible to account for this, but I'm sure that large changes to the core files are not enacted lightly so I thought that I'd check it was worth my time to fix this before I did anything further.
> ?
> A new patch replacing the one I submitted previously is attached which gives correct behaviour for wxWidgets DC and Graphics Context and freetype.
> ?
> By the way Alan, I've looked quite a bit into Pango/Cairo for Windows. the .configure script is rather too complex for me to convert into a CMake file - I just don't have the knowledge of CMake to do it and there are a lot of header files used that are gcc specific and not available to MSVC++ users.?Anyway the upshot is that unless someone wants to use wxWidgets then?for Windows users AGG/FreeType seems to?give the best potential for high quality rasterised graphics.?On this basis I can see some value in keeping it maintained and would be happy to take it on if you'd like.
> ?
> All the best
> ?
> Phil

>
> ________________________________
>  From: phil rosenberg <philip_rosenberg@yahoo.com>
> To: Alan W. Irwin <irwin@beluga.phys.uvic.ca>
> Cc: Andrew Ross <andrewross@users.sourceforge.net>
> Sent: Sunday, 8 July 2012, 23:28
> Subject: Re: [Plplot-devel] wxWidgets driver and line breaks (fwd)

>
> Hi Alan and Andrew
> I've just finished checking the patch to correctly parse newlines in the various wxWidgets drivers. In addition, in order to allow the AGG driver to deal with newlines without FreeType I've added similar parsing ability to the plstr function in plsym. I've tried to minimise changes in the core code, however, to allow plsym to deal correctly with differently aligned text I've had to add the justification as an input. It should be that is you don't want the core code to be modified then this bit of the patch is self-contained.
> ?
> You can see an example attached using each of the four different wxWidget drivers. The? slight italic look of the text in the two AGG examples is because of the stretching caused by the bug mentioned previously. I think the larger size might be relatedto this too.
> ?
> As you can see from the examples the functionality includes maintaining alignment, adding extra space for subscript and superscript and rotated text. The line spacing is fixed and has been set empirically by me to something that looks about right - it probably isn't consistent between backends, but neither is the font rendering so I guess that's okay. I'm not entirely sure how well it will cope with changes in font mid string if the new font renders at a slightly different height to the starting font.
> ?
> I've checked it as well as I know how with changes in alignment, rotation and sub/super scripts?- you may have some further ideas how to put it through it's paces though.
> ?
> Cheers
> ?
> Phil

>
> ________________________________
>  From: Alan W. Irwin <irwin@beluga.phys.uvic.ca>
> To: phil rosenberg <philip_rosenberg@yahoo.com>
> Cc: Andrew Ross <andrewross@users.sourceforge.net>
> Sent: Tuesday, 1 May 2012, 20:02
> Subject: Re: [Plplot-devel] wxWidgets driver and line breaks (fwd)

> On 2012-05-01 04:32-0700 phil rosenberg wrote:
>
> > Hi Alan
> > I've just checked my code. Only AGG uses freetype, sorry please disregard the wxMemoryDC_freetype file. (I have a function in my own code
> > set which takes the driver number and a flag for freetype - I thought this flag was used for both AGG and wxDC drivers but I was wrong
> > it's only used for AGG - this meant the wxMemoryDC and wxMemoryDC_freetype files were rendered identically without freetype). All of them
> > are created with plplot.
>
> You should control all this with the -drvopt command-line option
> if you are not doing that already.
>
> Here is one method (on the Linux platform, you will have to translate
> for the Windows case) to find out all the driver options (assuming you
> configure PLplot with the
>  -DBUILD_TEST=ON cmake option, and assuming
> you have built the 24th standard example for c++ with either "make
> x24" or "make all":
>
> software@raven> examples/c++/x24 -dev wxwidgets -drvopt help
>
> *** PLPLOT WARNING ***
> Option 'help' not recognized.
>
> Recognized options for this driver are:
>
> freetype:? ? ?  Use FreeType library
> smooth: Turn text smoothing on (1) or off (0)
> hrshsym:? ? ? ? Use Hershey symbol set (hrshsym=0|1)
> backend:? ? ? ? Choose backend: (0) standard, (1) using AGG library,
> (2) using wxGraphicsContext
> text:?  Use own text routines (text=0|1)
> Program aborted
>
> Actually the above summary doesn't give all the details for freetype.
> freetype=1 uses the historical plfreetype approach (see explanation below)
> to set up the PLplot use of the freetype library.
>
> You actually set such options at run-time like
>  this.
>
> examples/c++/x24 -dev wxwidgets -drvopt freetype=1,backend=0
>
> (e.g., to obtain the wxDC variant of the device with the plfreetype
> approach).? Note, however, there are defaults for each case so if you
> set backend=0 it will automatically assume freetype=1 unless you
> specifically set freetype=0.? Also, the freetype flag is meaningless
> for backend=2 since wxGC doesn't use plfreetype or directly use
> freetype at all.
>
> > So, we have wxGraphicsContext which gives antialiased raster graphics and wxDC which gives various forms of non-antialiased raster
> > graphics and vector graphics. Both give unicode support. Is there much need for AGG or freetype at all with wxWidgets? It feels to me
> > that AGG and freetype should be part of a memory driver or a separate AGG driver, where a user (or another driver) provides an image
> > array and the plot is drawn onto this array in memory. The array owner can
>  then do what they will with it (blt it to a wxwidgets DC, save
> > it to a png, etc). I think this is basically what the wxwidgets AGG driver is doing. I just scanned the source and found a mem driver,
> > but it seems to uuse freetype but not AGG and I couldn't see any documentation. There is the GD driver as well which creates raster
> > graphics but I don't know how this works - again it seems to use freetype but not AGG.There are obviously reasons though why it's been
> > done this way (historical or present) so feel free to tell me if I've missed something. I guess time is the important thing - setting
> > something like this up probably requires a significant time input. There are no-doubt negatives of this model too.
>
> Historically plfreetype, PLplot software to help device drivers use
> the freetype library, was written to give our gd device the first
> PLplot utf8 capability. However, there turns out to be a number
>  of
> difficult issues with our gd device driver that nobody wanted to
> deal with so that device was deprecated as of 5.9.3 (see
> README.release).
>
> As a result of that bad gd experience with the plfreetype approach I
> have been admittedly prejudiced against any device driver (such as the
> wxDC and agg variants of wxwidgets) that used the plfreetype approach,
> but as of experiments I did this morning it appears I am now going to
> have to drop that prejudice.
>
> The png device (which is one of the gd devices) still gives
> bad utf8 results for example 24 in the sense that the Hebrew
> and Arabic "peace" words are reversed, and there is a screwup
> in the glyph order for Hindi as well (which is normally left to
> right, but with some notable exceptions which occur, for example,
> in the "peace" word written in Hindi.
>
> In sharp contrast to those bad results for "-dev png", "-dev wxwidgets
> -drvopt backend=0" and "-dev
>  wxwidgets -drvopt backend=1" (both of
> which use the plfreetype approach by default since freetype is not
> specified) render all "peace" words correctly in example 24!
>
> No internal part of PLplot (including plfreetype as shown by the -dev
> png example) does correct rendering of CTL (complex text layout)
> languages like Hebrew, Arabic, and Hindi.? So I have no clue why there
> is a rendering success for CTL languages with our wxDC and agg
> wxwidgets devices using plfreetype, but I will take it!
>
> For "-dev wxwidgets -drvopt backend=2" (e.g., the wxGC variant) for my
> wxwidgets platform there is no recognition of utf8 at all for example
> 24, but from the results you have reported before, that deficiency is
> now gone for the latest wxwidgets release.? So the summary appears to
> be there is utf8 support with correct rendering of CTL languages and
> scripts for all three variants of the wxwidgets device depending
>  on
> details of the wxwidgets platform.
>
> So to finish up the utf8 topic, I think all you have to do is to play
> with the agg variant to see whether you can get utf8 to work there as
> well as it does here or as well as it does for you for the other two
> variants. And all we have to do on the Linux side of things is wait
> for the latest wxwidgets release to be installed to get good utf8
> support for all three variants.
>
> > Moving back to the original topic about newlines. I've just found that newlines aren't as well behaved in wxGraphicsContext as I thought
> > due to the way the strings are parsed by plplot. The GetTextExtent() function returns the width of the widest line in a string with
> > multiline lines, rather than the width of the last string which is assumed when an escape character is found. Then plplot starts again
> > after the escape character at the starting yPos. Also any alignment other than left
>  aligned doesn't work properly. Attached is an example
> > of the problems that can occur. I took the previous example and made the word (English) superscript. The alignment is centred within the
> > box. You can see the obvious problems.
> > I guess the only way to get correct and consistent newline support is going to be to parse the strings at the plplot driver level. I've
> > started writing a patch and will let you know progress.
>
> I am not as expert as Andrew or Werner (also a core PLplot developer
> and the originator of wxwidgets although he has not been too active
> recently) on drivers.? However, I think you should look at
> src/plfreetype.c to see whether the wxDC and agg variants use of that
> code is affecting the newline handling.? Hopefully, that is not an
> issue, and in any case you will probably want to handle linefeeds the
> same way for each variant (especially if you want to bypass the
> results
>  for wcGC, the only variant that recognizes "\n" at the moment
> but with some deficiencies as you have just demonstrated.)
>
> Once you get your wxwidgets code changes finished you should present
> them to the plplot-devel list as a patch. Although Werner has been too
> busy with his job to say anything yet, I am pretty sure you will get
> some useful comments from him once you have some concrete code changes
> in the form of a patch to discuss on list.
>
> 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
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel