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(a)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.