Re: [Plplot-devel] Release issues related to unicode fonts

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

On 2005-01-28 14:03-0800 Alan W. Irwin wrote:

> + For Example 6 text the labels written with plptex seem to be positioned
> correctly, but the symbols written with plpoin are  positioned
> consistently too high.
>
> For the latter issue, I am wondering if there may simply be a positioning
> bug in the way that I have called the unicode array method for handling the
> symbol font change plus a single character in plhrsh.  I was sometimes
> guessing there, and somebody with a deeper understanding of PLplot
> positioning should review the plhrsh code. plhrsh is the routine called by
> plpoin.  For plptext, the setup of the unicode array method is done with
> entirely different code which appears to be correct as far as position
> information is concerned.
>
> A similar problem used to occur for plfreetype although the issue was
> complicated by plptex positioning problems as well which now seem perfectly
> fixed by Rafael's changes.  But as I recall, some of Rafael's fixes were
> specific to the plhrsh call in the sense that call was recognized by the
> font change plus one character being sent. If a bug is found in the way
> positions are set up in plhrsh so that the postscript positions come out
> right, then you may be able to simply strip out all those special "plhrsh"
> fixes in the plfreetype code, and have the png symbol positions come out
> right as well.  The current set of "plhrsh" plfreetype fixes need to be
> reviewed in any case, since the consistent symbol shift we used to have has
> now been turned into a symbol shift that is correct for upper case letters
> but which varies from character to character (compare "i" and "j") for lower
> case characters.

Here is some additional background to the vertical positioning problem for
symbols handled by plhrsh and plfreetype. In off-list discussions with
Andrew Roach prior to my FCI changes to plfreetype.c, he explained to me he
used a completely separate code path in plfreetype.c to deal with calls from
plhrsh.  That code path (the call to plD_render_freetype_sym from
plD_render_freetype_text) was triggered by args->unicode_array_len == 0.  I
bypassed plD_render_freetype_sym because I needed to communicate FCIs with
unicode_array even in the single-character case, and I assumed that
plD_render_freetype_sym could be mimicked by the normal code in
plD_render_freetype_text.  I haven't followed Rafael's changes in detail,
but I think all that has to be done for the plhrsh case (which should
probably be signalled in a flag in EscText rather than relying on the test

     if ((args->unicode_array_len == 2)
           && (args->unicode_array[0] == 0x10000004))

) is to follow what Andrew did for vertical positioning in
plD_render_freetype_sym.  Alternatively, plD_render_freetype_sym could be
made FCI aware.  Andrew (Roach) might follow that path eventually because he
was concerned about inefficiencies in the plD_render_freetype_text for
single characters, but if we can mimic plD_render_freetype_sym positioning
exactly in plD_render_freetype_text I would prefer to do that since it would
be nice (from the code maintainability POV) to eliminate
plD_render_freetype_sym altogether.

I have no more time to do any changes to plfreetype myself, but I thought I
had better give this background so those who are working out the remaining
unicode font issues are aware of why the currently unused
plD_render_freetype_sym is still in plfreetype.c as reference code and also
as the basis for a possible FCI enabled version in the future.

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
__________________________