Re: Unexpected font rendering with pango

[Owen Taylor <otaylor redhat com>]

On Fri, 2003-06-27 at 11:52, Pablo Saratxaga wrote:
> Kaixo!
> 
> On Fri, Jun 27, 2003 at 02:32:16PM +0100, Abigail Brady wrote:
> 
> > > Recently I have found an unusual behaviour in Chinese font rendering
> > > with Pango.Please have a look at the attached, little screenshots. The
> > > only difference between both is the setting of the locale before starting
> > > the application. The first one uses LC_ALL=en_US and the second one
> > > LC_ALL=zh_CN.GB2312. The font rendering is - despite the missing
> > > antialiasing - fine on the second pix, but not o.k. in the first
> > > case. It somehow uses a different size of fonts in just one string ...
> > > 
> > > Anyone out there who has an idea or a hint how to track this and/or to
> > > fix this ?
> > 
> > It's doing this because of the preference order of the fonts.  With
> > en_US its picking up a japanese or korean font first, and using that to
> > display any characters it has support for - and only then moving to the
> > chinese font.  When in the chinese locale, it knows to use chinese fonts
> > first...  So you'll need to fiddle with the config files.
> 
> The problem is that it is using a *non scalable* font at a *wrong size*.
> Imho pango (well, Xft actually I think) should first look at scalable fonts,
> and only if no scalable fonts are found ressort to non scalable ones,
> if that is already doable trough a config option, then I would be interested
> to know what option it is, in order to enable that by default.

I'm pretty sure that the Stephan is not using fontconfig/Xft. You'd
have to have a very exotic configuration (basically, no scalable CJK
fonts) to get those results with fontconfig/Xft.

> It is simply too bad that a single text get in mixed sizes, just because
> the first matching font is used, without checking it has the character 
> at the right size. Such an output is acceptable if the only other
> alternative would be to display an empty square, but that is not the case
> here.
> 
> Even worst: the first character of the paragraphe is a traditional chinese
> one, and taken from a traditional chinese font; imho in such case 
> pango should continue with the same font as long as possible, instead of
> switching to the default one for the next (for every?) character (that
> behaviour may not be wanted for latin/greek/cyrillic etc; but for CJK it
> makes sense to stick when the same font as long as possible; that is,
> if a given character was not on the default font, nor in the first CJK
> font ('ja' or 'ko' covering one in this case), and was on another CJK font,
> then it should stick with that one, as it is likely that other characters will
> be in the same case. Following that ordering will give a much better
> output in all cases of normal CJK text.

Unfortunately, you can't autodetect traditional vs. modern Chinese, so
I don't think we'll ever be able to do much better than supplied
language tag for that situation... if you have a section of text
that has only shared characters, it's going to get one or the other 
font arbitrarily.

For other languages, there is possibility of improvement - see
http://bugzilla.gnome.org/show_bug.cgi?id=112503.

For Stephan, there is a easy solution ... since the app knows the
language of the text it is displaying, it can explicitely set the
language tag, and override the language tag of the locale.

Regards,
					Owen