[vtkusers] bug 0009618 and UTF 8 text rendering fix question

[Sean McBride]

On Tue, 7 Dec 2010 15:27:03 -0500, Marcus D. Hanwell said:

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

Agreed.

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

I agree here too, but such a change would appear to break binary
compatibility.  Today's vtkTextActor::SetInput() expects ISO-8859-1 (at
least on my system), if we change it to expect UTF8 we break existing
clients of VTK.

In any case, API that take char* should document which encoding they
expect.  Consider the tiny attached patch.

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

Sounds great.

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

vtkTextActor appears to be in need of vtkUnicodeString support...

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/octet-stream
Size: 821 bytes
Desc: not available
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20101207/ae75a71c/attachment.obj>