[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