Re: [Plplot-devel] Revised plot metafiles and changes to plbuf

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

On 2015-03-02 09:50-0500 Jim Dishaw wrote:

>
>> On Mar 2, 2015, at 4:55 AM, Alan W. Irwin <ir...@be...> wrote:
>>
>>> On 2015-03-02 02:01-0500 Jim Dishaw wrote:
>>>
>>> Attached is a patch for testing, I don't recommend pushing it to
>> master yet.  It comes very close to rendering a metafile "identically"
>> (modulo rounding differences).  The main problem is that plot symbols
>> are missing.  I should be able to fix that on Monday.
>>
>> Hi Jim:
>>
>> I have argued in my just previous post that no special processing of
>> unicode or alt_unicode should be necessary at all by plmeta or
>> plrender/plbuf code since the PLplot core library code and individual
>> device code know how to do that special processing already.
>>
>> To make that argument more concrete, explore what happens if you test
>> that hypothesis by setting pls->dev_unicode = 0 in plmeta.c for the
>> NEW_METAFILE case. In that case the core stores a pointer to the raw
>> (i.e. completely untransformed) input char array in args->string and
>> the new plmeta code outputs that null-terminated char array to the
>> plmeta file.  That is the correct thing to do in all cases if you
>> agree with my further assumption below.
>>
>> For the above to work those raw char arrays also must receive no
>> special plrender or plbuf processing.  Instead, they should just be
>> sent off to the plcore using a plP_text call which then should
>> initiate normal text processing for whichever device has been
>> specified by the user using the -dev option for plrender.  So I assume
>> such a plP_text should be possible based on the data stored in the
>> plmeta file.  If you agree with that assumption, then it follows this
>> method should drastically simplify text handling for plmeta and
>> plrender modes (since in the plmeta case you can drop all unicode and
>> alt_unicode code and similarly for plrender/plbuf, and I hope you
>> would be willing to modify your patch accordingly.
>

> Fortunately what you describe is almost how things are implemented.
I can't rely on null terminated strings because if real Unicode
strings are passed, they can can contain null bytes. That will require
the use of string lengths to make metafiles agnostic.

Let's deliberately use the term byte count to represent the number of
bytes to the first null in the char array (what is determined by the
most primitive form of strlen function whose input is a char array)
since "length" is confusing terminology which could be misintepreted
as the number of Unicode glyphs represented by the data.

There is no explicit byte count associated with our raw input char
arrays (e.g., see the plmtex and plptex API) so that the byte count
must be described by the null termination.  Thus, any null in the
middle of something longer that was supplied by the user should simply
lead to PLplot using the first part of the raw char array up to the
first null.

Note, a null byte by definition does not have the 8th bit set so it
cannot be part of a multi-byte UTF-8 sequence or anything like that. 
So in practice the constraint that our users must not stick a null in
the middle of their UTF-8 is virtually no constraint on them whatever
and probably seems entirely natural to them (just like it already is
for the pure ascii subset of UTF-8).

In sum, you will likely want to calculate (using strlen in plmeta),
store and use the byte count (following the usual convention of
ignoring the null terminator in the byte count just like strlen
delivers) of the raw input char array in the plmeta file format, but
the raw input char array that is stored should include that
terminating null byte since that terminator is assumed when the core
and some device jointly process that raw char array.

> I will take a look at xcairo and see if I can fix it.  It is a good test case for the work I'm doing with the metafiles.

I like the sound of a good test case, and that work would be
intrinsically valuable since I don't think anyone likes the resizing
result delivered by xcairo now.  However, I hope to see the
greatly simplified (raw char arrays only) plmeta/plrender first
since that should be an outstanding way to test plbuf.

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
__________________________