Subject: Re: International support in Win98
From: Vlad Harchev (hvv@hippo.ru)
Date: Thu Dec 21 2000 - 13:18:27 CST
On Thu, 21 Dec 2000, Lukas Pietsch wrote:
> Mike Nordell wrote:
>
> > I fixed input locale switching just a few minutes after I got
> the > first forward of your post.
>
> Good! If you guys are always as quick as that, I'll start to like
> this project. :-)
>
> This encourages me to raise a few more issues about i18n:
>
> 1) There's a problem not just with the keyboard but also with the
> display. I finally managed to force-feed Abiword a few non-Latin
> characters (by manually editing an abw source text outside
> Abiword and then re-opening it.) Although Abiword is evidently
> handling the characters quite correctly as Unicode internally,
> they get displayed with the typical distortions that happen when
> a string undergoes "WideCharToMultibyte" (some characters
> replaced with "best-fit" Ansi ones, most others replaced with
> question marks.)
It seems this is due to the fact that these characters are missing in fonts
AW uses (all fonts shipped with it have only glyphs for cp1252). It seems
GDI is choosing "best fit" replacements.
> I'm sure this isn't by design, is it? I can see that the strings
> are internally "unsigned short UT_UCSChar", the drawing functions
> use "ExtTextOutW", and there's absolutely no
> "WideCharToMultibyte" lurking around anywhere in your code. So
> this ought not to be happening, right? :-(
>
> 2) Are there any plans to switch to the uniscribe rendering
> mechanism? You'd get some very pretty bidi support and complex
> script rendering for your application free of charge. Or are you
> planning to do that job yourselves?
Not more than 40 hours ago a patch for BIDI support was announced on this
list. Please see the archives.
> 3) Something entirely different: I noticed that Abiword is at a
> loss when saving Unicode characters in LaTex format. Most
> characters above 8bit are simply dropped. Of course, that's not
> Abiword's fault but LaTex's - Unicode support is simply not
> available in classical LaTex. But are you aware that there is now
Please try 0.7.12 - it won't loose any character as I remember (I've coded
it).
> an alternative: Omega? ( see
> http://omega-system.sourceforge.net ) Omega is a 16bit enhanced
> version of Tex which supports native Unicode input. Whenever a
> document contains non-8bit characters, you could just save the
> Latex files in UTF-8 and leave it to Omega to do all the rest.
> Unfortunately Omega is little known and there is precious little
> documentation for it. But it generally works with the same syntax
> as LaTex, so it shouldn't be a big step to adapt. (And documents
> containing only 8-bit could of course still be processed by
> classical LaTex too).
>
> 4) A very minor i18n bug: The Windows installation program
> assumes "C:\program files" to be the default installation path.
> This path name is localized in Win9x (and customizable too). I
> think the practice is to look up the value in the registry, under
> HKLM\Software\Microsoft\Windows\CurrentVersion,
> "ProgramFilesDir", and then use that as a default.
>
> Happy Christmas to all,
>
> Lukas
>
Thanks for your suggestions.
Best regards,
-Vlad
This archive was generated by hypermail 2b25 : Thu Dec 21 2000 - 13:57:31 CST