[Bug 485566] Fontconfig should select DejaVu font for rendering English, even in Japanese locale.

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=485566





--- Comment #8 from Nicolas Mailhot <nicolas.mailhot at laposte.net>  2009-07-14 06:46:39 EDT ---
(In reply to comment #7)
> (In reply to comment #5)
> > The correct fix is either to get upstream to drop latin glyphs from VLGothic,
> 
> I'm opposed to this idea. nothing wrong in VLGothic and it introduces another
> bug in applications using any other rendering/multilingual framework libraries
> doesn't supports a fallback fonts. like Bug #434753.

Anything that does not use fontconfig nowadays with its built-in font
substitution is a bug period. We barely have the energy to get our main font
system sort of working without having to work with others.

> (In reply to comment #6)
> > Also, apart from those local fixes, the core of the problem is pango has
> > usually no idea what language you're trying to type, and tries to guess from
> > what you're typing.
> 
> Does it? though Pango sets a default PangoLanguage from current locale when
> it's starting. why doesn't Pango just has a priority to pick up the font
> according to that?

Because there is no strict equivalence between the language of your desktop
(the locale) and the language you are typing (what pango needs to process). It
is very common to type in a foreign language, and anyway in lots of regions
people use the en_US locale because theirs is not available or the translations
are incomplete or bad

> > To put an end to this class of bugs (which are not limited to VLGothic or
> > Japanese) you need a language switcher applet that, in addition to managing
> > input methods, tells explicitely apps what's being typed.  
> 
> If we want any framework other than locale system to determine the input
> language etc, I think it may be better adding a kind of feature to the input
> method right rather than having new one and IM running at the same time.  

That assumes there is one true IM system that works for all languages. So far
that hasn't been the case. And even if there was one system, you need to
distinguish between the input method selection and the language selection
because there is no 1:1 relashionship between them (any latin layout will be
able to type English even if it's not an English layout, that's probably also
true for russian and cyrillic layouts, etc)

Accurate language selection gets you more accurate text rendering, correct
spellchecker selection, etc

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.