[vtkusers] bug 0009618 and UTF 8 text rendering fix question
Marcus D. Hanwell
marcus.hanwell at kitware.com
Tue Dec 7 15:27:03 EST 2010
On Tue, Dec 7, 2010 at 3:13 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> On Tue, Dec 7, 2010 at 11:42 AM, Sean McBride <sean at rogue-research.com>
> wrote:
>>
>> Marcus,
>>
>> Just to clarify, what encoding should be given to vtkTextActor::SetInput
>> ()? Last I tried, it seemed to expect ISO-8859-1. Certainly a step up
>> from ASCII! Is the long term plan for it to accept UTF8?
>
> I think it is best if VTK strings use the system default encoding, rather
> than utf-8. For unicode there is always vtkUnicodeString. More classes
> should be adapted to take vtkUnicodeString as input (but only, of course,
> if they are internally capable of using/rendering unicode).
>
> But I'm flexible. Really, I'm just pushing for VTK's string handling to be
> more similar to Python's. ;)
>
I am not too concerned about aligning with Python's string handling,
but agree with David - I think we should be adjusting existing classes
to deal with and take vtkUnicodeString, which can take UTF8 strings
for construction. It would probably be simplest to interpret all const
char* and vtkStdString as UTF8 when it came to rendering, as minimal
code/API changes would be required.
If you look at vtkContext2D and friends, where I have been prototyping
the UTF8 string handling and Unicode rendering, I have used
vtkUnicodeString as the function argument. There is vtkFreeTypeTools
that can take a unicode string, and render it accordingly, or the more
traditional string and render it as has been done for many years.
I certainly welcome people's thoughts on this. Working through the
relevant classes, and adding vtkUnicodeString API to them where and
when they can really render Unicode seems like a reasonable approach
to me.
Marcus
More information about the vtkusers
mailing list