Re: 2.0.1 bug situation, esp. wrt ZVT

[Havoc Pennington <hp redhat com>]

Steve Swales <Steve Swales sun com> writes:
> FYI: From Sun's point of view, i18n is not a feature, it is a hard
> requirement, which is why Toshi is working so hard to get this stuff
> working.  Generally speaking, Sun's GNOME 2.0 distribution must be i18n
> compliant, or will not ship.  We will make those changes in our child
> tree if we are unable to integrate the changes to the public one in time
> for the 2.0.x distribution, though we would prefer the fixes to be in
> the public source.
> 

I have a memory of someone claiming you guys were going to use dtterm
for an i18n terminal and that's why libzvt bugs weren't getting more
attention. I don't know who said that or when but it got in my head
somehow. I tried to get people to fix libzvt quite some time ago:

  http://mail.gnome.org/archives/desktop-devel-list/2002-March/msg00171.html

I was also planning to do these fixes myself for Red Hat if required
(by forward-porting the bad multibyte hack patch from 1.4.x), but
thankfully got out of it.

Toshi - a couple comments on the i18n patch:

 - I would not use PangoLayout, it's going to be slow and slightly
   wrong in terms of what it does to text. you probably want to use
   Xft directly or close the GTK 2.2 API bug to add a simple "draw
   string" kind of API to pango

 - you are going to need to handle non-monospaced fonts, because 
   gnome-terminal has no way to filter things so the user can 
   only select monospace, at least not yet

 - max_logical_extent on pango fonts is going to tend to be too big
   for Western locales due to fontsetting

Havoc