[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Dia ChangeLog report for Tue Jan 29 08:23:01 2002 (UTC)



Le Tue, Jan 29, 2002, à 07:58:54PM +0900, Akira TAGOH a écrit:

> CC> It may be desireable to find a way to fall back on "<<" and ">>" (ie,
> CC> two-character ASCII representation) whenever the current local charset does
> CC> not feature the << and >> proper characters; this doesn't need to rely on
> CC> the gettext infrastructure, does it ?
> 
> I don't know whether can do that or not. but even if \xab
> and \xbb is valid characters for example, not sure whether
> those is really shown the glyph like '<<' and '>>' or not.

I think it is better to display what is encoded in Latin[19] as \xab and 
\xbb whenever the current locale support it, and to fall back to the ASCII
approximations only when there is no other way. The UTF-8 representation of
these characters I had put in the code you fixed is the right one, and
should either translate into something which indeed produces the right
glyphs when the locale supports it, or "somehow" fail.

I'm not very sure of the failure modes of our charset conversion routines
when confronted with a character the target charset lacks an encoding for.
Mmmmmm.... could you send me (privately) a very small sample of UTF-8
encoded Japanese text, so that I could investigate ?

> BTW about input and display, text object and UML object
> seems to work fine for UTF-8. I have tested as the
> following:
> 1. replaces gtk_advancement=initial to
>    gtk_advancement=dia_talks_utf8 in configure.in
> 2. build it.

This is very sweet !

	-- Cyrille

-- 
Grumpf.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] Mail converted by Mofo Magic and the Flying D

 
All trademarks and copyrights are the property of their respective owners.

Other Directory Sites: SeekWonder | Directory Owners Forum

GuideSMACK