#1676 Handle full Unicode (>U+FFFF) for pointtype
As discussed in comp.graphics.apps.gnuplot last few days, currently Unicode is only partially handled for plots using pointype.
For example this should produce a line of cats (in version above 5!):
gnuplot -p -e 'plot sin(x) w p pointtype "🐱";'
Instead it shows as "blank" in some terminals and three broken characters in others.
It might be triggering buffer overflow...
On Tuesday, September 29, 2015 at 9:35:14 AM UTC+9, Ethan A Merritt wrote:
The structure that holds line and point characteristics reserves
one unsigned long (4 bytes on most machines) to hold the UTF-8 byte
stream representing the character. Currently it is handled internally
as a C language string, which means that the 4th byte is required
to be \0, leaving three bytes for the UTF-8 representation.
That is sufficient for Unicode code points up to U+FFFF, which covers
the "Basic Multilingual Plane" a.k.a "plane 0". It is not sufficient
for code points higher than that like your CAT FACE at U+1F431.The entire set of Unicode planes could be handled either by
enlarging the lp_style_type->p_char field or by revising the code
that uses it to treat it explicitly as 4 bytes rather than as
a generic string. Certainly possible, but I don't think it is
very high priority change. As you found, using those higher-plane
Unicode characters in labels and other text strings works fine.
It is only use as a point type that is limited.
Fixed in 5.1