> 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. > best, > -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
