Re: 2.0.1 bug situation, esp. wrt ZVT

[Havoc Pennington <hp redhat com>]

HideToshi Tajima <hidetoshi tajima sun com> writes:
> I could understand it may make things slow, but I'm not really sure
> what you mean from
> "going to be slightly wrong"? Is this known issue of PangoLayout?

Terminals are grid-based. PangoLayout is not. So for example
PangoLayout might create ligatures (merge "fi" into a single glyph, or
equivalent in other languages), or may reorder characters, or 
the like. This would break the correspondence of glyphs to character
cells that you rely on in a terminal. It's possible this isn't an
issue for most languages. I'm not sure.

> I don't want to use Xft directly - at least don't want to make it an
> only option, so that it should work in the system not having
> Xft. Using a simple "draw string" API of pango may be a choice at
> 2.2, but I'm afraid it cannot be in 2.0.x.

You might have to do some #ifdef kind of stuff, or use Xft2 since any
system can install Xft2 (it isn't tied to the X version).

> (Above all, I understand using Pango is a way to handle text rendering
> and layout in
> GTK+2 and GNOME2. Is it not true specfically in gnome-terminal and
> terminal widget?)

Pango yes, PangoLayout no.

> Handling non-monospaced fonts would require massive code changes,
> which I'm afraid it cannot be done in next 4-6 weeks of 2.0.2
> timeframe.

Yes, well. This is the kind of thing that makes me say "VTE" ;-)
 
> How about having a way to filter some fonts to meet the above
> expectation? Is it possible to add it in gnome-terminal or somewhere
> else? How difficuilt could ie be?

Monospace fonts are not labeled. You have to iterate over every glyph
in the font, and see if they are all the same width. This could
probably be made efficient on the fontconfig level (see Keith's recent
post to gtk-devel-list IIRC), but it's not something Pango currently
offers.

> The patch is using pango_font_metrics_get_approximate_digit_width()
> so that it should decide column width from the width of ASCII digit
> characters, so it does not become way-big due to fontsetting or the
> current locale.

Ah, OK. 

Havoc