I am slightly late to the show here, but I have fought with all three
text implimentations for the different wxWidgets backends and have
some thoughts.
i) Fontconfig is nearly impossible to build on native Windows. We have
had these discussions before. GIMP does appear to use it, but they
have no doubt had considerably more development person-hours than us
to work out how on earth to get it to build.
ii) A lot of the duplicate code from the three wxWidgets drivers was
layout( super/subscripting, newlines splitting for under/overlining
and transformations for 3d text). I believe that PLplot should go
farther than including a tokenizer, it should contain its own (or make
use or some other (harfbuzz?)) layout engine. Then a driver should
simply be asked what the dimensions of chunks of text are, then it
should be provided with those chuncks of text and an affine transform
for rendering. Each of those chunks would be a single style, (font
size (which would be a function of superscript level), font style,
etc) and contain no newlines, and based on the dimensions provided by
the driver PLplot would determine where to place them. I think this is
the closest we can get to consistent rendering on all drivers, and I
think it also strongly abides by the principle I mentioned in an
earlier email the PLplot takes plotting instructions and converts them
into simpler drawing instructions.
iii) The problem with ii) is what happens if a driver cannot provide
the dimensions for a text chunk. I don't know which drivers this might
affect. Can the non-interactive drivers do this? I imagine not. Then
we either need to just throw them Hershey text or have a middle road
where they use their own layout engine.
Phil
On 23 March 2015 at 14:38, Hazen Babcock <hbabc...@mac.com> wrote:
> On 03/21/2015 05:51 PM, Jim Dishaw wrote:
>>
>>> On Mar 21, 2015, at 1:48 PM, Hazen Babcock <hbabc...@mac.com> wrote:
>>>
>>> On 03/20/2015 05:35 PM, Jim Dishaw wrote:
>>>>>
>>>>> In sum, the technical choice is between the alt approach which
>>>>> requires already implemented code in the core with simpler code in the
>>>>> unicode-aware drivers and the original approach which allows us to
>>>>> drop core code at the expense of more duplicated and more complex text
>>>>> processing code in the unicode-aware drivers. And you can use cairo.c
>>>>> as a prototype to estimate the driver code savings/simplifications
>>>>> that would appear for the non-cairo devices in the alt case.
>>>>
>>>> I'm actually a fan of both approaches and don't see a pressing need to
>>>> remove either one. The biggest change I would make is to unify the string
>>>> tokenizer. Some cleanup is needed in the Cairo driver because there is a
>>>> lot of unnecessary overhead when handling strings.
>>>
>>> Sorry, I'm not sure what you mean when you say "unify the string
>>> tokenizer". Do you mean in PLplot core? The drivers should all use a common
>>> string tokenizer? Or something else? I was trying to create what I thought
>>> of as a common string tokenizer with the alt_unicode text pathway, but I
>>> don't think that it worked out that well. I'd like to understand better
>>> what you propose.
>>>
>>
>> Both Unicode paths have duplicated the code that converts format strings
>> (e.g. Escape characters) to Unicode. I think it would be more maintainable
>> if we could have one function that does the conversion. I'm trying to think
>> of a good way to call the appropriate escape functions.
>>
>
> How about we replace the alt_unicode path with a "de-tokenizer"? The
> drivers could still parse the string as they do now, but to make the
> text processing logic easier core could provide a function like:
>
> int stringGetNextChar(PLStream *pls, char *a_char, short *is_escape)
>
> which a driver would use like this:
>
> char a_char;
> short is_escape;
>
> while(stringGetNextChar(pls, &a_char, &is_escape)){
> if(is_escape){
> do something with escape a_char;
> }
> else{
> do something with a_char;
> }
> }
>
> This would simplify the proc_str logic in all the drivers and remove a
> lot of unnecessary duplication, which was the goal of the alt_unicode
> path. After constructing the string, core would update pls with the
> necessary information for stringGetNextChar to work.
>
> -Hazen
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
