Re: [Plplot-devel] Freetype "bug" in Debian packages

[Alan W. I. <ir...@be...>]

On 2004-12-12 02:28+0100 Rafael Laboissiere wrote:

> What I mean by "designing Unicode support directly into PLplot's core" would
> be something like this:
>
> 1) The text plotting functions will start accepting Unicode encoded strings.
>   This will allow for the multi-language support that you mentioned above.
>
> 2) Escaped sequences using "#" will be fully supported as they are today and
>   this will ensure backward compatibility.
>
> 3) For drivers who claim HAVE_TEXT, the code in plsym.c will translate the
>   non-ascii charaters in (1) and the escaped sequences in (2) into the
>   corresponding UCS code.
>
> Point (3) implies two things:
>
> a) It will not be possible anymore to pass just a string containing the text
>   to the driver when issuing a HAVE_TEXT command (this is currently done
>   through the char *string field of the EscTxt structure, see plplotP.h).
>   We have to use an array of uint32 or something of the sort.
>
> b) As a nice side effect, at the drivers side, no hacks will be needed to
>   both decode and translate Greek and mathematical symbols form #-escaped
>   sequences into Unicode.
>
> In sum, both the work that I already did for the greek characters in both
> the ps and gd drivers and the work that Andrew is doing right now for the
> #(nnn) sequences will be implemented directly into PLplot's core.  This
> means that all drivers supporting Unicode will work in a transparent way.
> Today, only gd is capable of that, but we could add the Unicode capability
> to the ps driver as well as to screen-oriented ones.  For instance, doing
> this with the gnome driver should be straightforward, thanks to the Pango
> library.
>
> What do the others think about this design?

Thanks for your thoughtful post.  Your point 3a is well taken. This is
obviously necessary since the result of translating a Hershey index to
unicode index is a 4-byte unsigned integer, and that result has to be
transmitted from the PLplot core (where I agree the translation should be
done) to the device drivers.  Of course, this eliminates the current hacks
for the devices that support HAVE_TEXT (benefit 3b).

I hope this centralized approach is how Andrew is thinking about
implementing his change to the #(nnnn) access method. I just checked src and
drivers and EscTxt is mentioned only in relatively few places so I presume
this is not going to require a large amount of programming to make the
change.

Rafael, the only thing I disagree with in your above post is putting issue 1
first.  I believe (1) is going to be difficult. That is why I would do it
last after the #g and #(nnnn) methods work (using the more centralized
method you have just discussed).

Andrew, you have probably thought hard about these implementation issues so
I am especially looking forward to your comments on Rafael's design.  In
particular if we ignore (1) for the time being, is the programming effort
fairly modest as I assumed above?

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

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); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________