Re: [Plplot-devel] example 1 -save option does not work for xcairo

[Hazen B. <hba...@ma...>]

Alan W. Irwin wrote:
> On 2009-11-14 21:22-0500 Hazen Babcock wrote:
> 
>> This should be fixed in v10591. The problem was with the two different text 
>> rendering paths. The second text rendering path seemed like a good idea at 
>> the time, but now I'm sort of leaning towards reverting it. It doesn't really 
>> make driver text handling that much easier or cleaner to program and as long 
>> as we have two paths we are probably going to keep running into trouble like 
>> this.
> 
> Thanks, Hazen.  I verify that example 1 -save now produces a PostScript
> (-dev psc) file with text with -dev xcairo.  However, there is one obvious
> issue in that generated PostScript text that remains; the numbers that
> should be exponents are not superscripted at all.

It looks to me like all of the formatting is somehow removed. I'm still 
puzzling over how that happens as I don't think the new pathway touches 
the string created for the old pathway, though I guess it must somehow.

> Also, I didn't understand your explanation of the issue you found so would
> you be willing to expand it?
> 
> I assume you are not referring to the Hershey text rendering path (used by
> -dev xwin and some other device drivers at special option).  And you are
> probably not referring to the "ancient" plfreetype unicode text rendering
> path used by the gd device driver and still a few others.
> 
> That leaves the "modern" unicode text rendering path used by the cairo, qt,
> ps, psttf, and other devices that does not use plfreetype. If I recall
> correctly you may have added at least one centralized helper function for
> the modern unicode case which some devices (cairo?) use and others do not
> (yet).  Is that what you are referring to by the two different text
> rendering paths?  If so, and you would like to get rid of one of them, then
> it would be great to use more centralized unicode text processing for all
> modern unicode devices instead of the present situation with much duplicated
> code in the device drivers for processing unicode text.  But that should
> still leave intact the Hershey text rendering and the old plfreetype-based
> unicode text rendering.

Yes, this is what I was referring to. Does anyone else have an opinion 
on which path we should keep going forward? On the one hand we have the 
ubiquitous while loop. On the other we have four different functions, 
one called at the start of text, one called for new characters, one 
called for new esc characters and one called at the end of the text. The 
cairo driver currently has both approaches implemented if anyone is 
curious to compare the two.

Functions called for approach 1:
proc_str
ucs4_to_pango_markup_format

Functions called for approach 2:
text_begin_cairo
text_char_cairo
text_esc_cairo
text_end_cairo

-Hazen