[Bug 517789] Droid Sans overrides default Japanese desktop font

[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=517789





--- Comment #13 from Nicolas Mailhot <nicolas.mailhot at laposte.net>  2009-09-07 01:53:23 EDT ---
(In reply to comment #11)

> 1. Why the seemingly random numbers for the conf files?

They're not random, droid sans is at 65 because of its wide coverage & CJK
otherwise it would have a lower number since it is a high visibility font. If
you have a better ordering suggestion I'm all ears. It's not easy to check font
priorities, the system is a bit of a blackbox (fc-match is supposed to do it,
but no font packager really understands it and it only prints the order for the
fonts fond on system hiding the font names that may be defined in the conf
files but are not available)

> 2. Should I add Droid fonts to default fontconfig config?  At least just the
> aliasing to/from generics?

I'd rather not, it's a complex font to configure and it'd be easier if droid
changes are kept in a single package (that can be updated in previous releases
if i18n wants it without involving the fontconfig package)

> 3. You should also alias back "Droid Sans Japanese" and "Droid Sans Fallback"
> to "Droid Sans" now that we are renaming those.

That's a really good idea, I don't know why I didn't before, I probably was
just afraid of the whole thing

> 4. You use "prefer", while you really should use "accept".  That's perhaps why
> the default Japanese font is affected.

That's because we use prefer for the other fonts too. I could change it but I'd
rather limit the drift from the patterns used elsewhere (or else please confirm
accept is sufficient and safe for the other fonts too)

> 5. Lets understand what target="scan" is: It is applied to patterns scanned
> from the font (that is, what fc-query returns), and can modify it.  So any lang
> you match there is the languages found in the font, not the user-specified
> language.

The problem is we want to change the name found in the font. Is there a way to
match the user-specified language and change the name in the font?

> 6. The renaming is easy.  The reordering harder, since now we have three fonts
> all named "Droid Sans" and we don't have any way to address them separately. I
> checked the coverages, Fallback and Sans overlap a bit.

That's expected Fallback is just a bunch of medium-quality glyphs to fill holes
(I suspect a generic Ascender pile of Glyphs thy also use for other fonts). BTW
google did an update to the japanese and fallback files those past days, I just
pushed it.

> If we could just
> delete the lang="ja" from Fallback's coverage, we were mostly done.  But that's
> currently not possible for a stupid reason.  I filed a bug about that.
> 
> In the mean time, this is the solution I came up with: we force a fixed order
> on the three, by modifying their version tag.  So, Japanese gets the highest
> version number, 3, and Sans gets 2, finally Fallback gets 1.  This means, when
> Fontconfig is matching Droid Sans, it tries Japanese first, if the language
> coverage is enough (ie, we are looking for Japanese), it's matched, otherwise
> Sans is tried, and finally Fallback.  Voila.  Attached config file for that. A
> bit hacky to override the version tag, but I can't think of a better solution
> right now.

Thanks! I'll look at it in the evening

> 7. Given this scheme, and for RPM font tagging to work correctly (that is, to
> tag with "Droid Sans" instead of "Droid Sans Japanese"), we need to switch the
> RPM hook from calling fc-query to call fc-scan instead. The arguments are the
> same, the latter also applies the configuration rules.  That should do it,
> except for a but that I just fixed, so next fontconfig release will have it.
> Can you communicate the change with Panu?

That's not a problem the part that defines the hook is in fontpackages-devel I
can change it at any time without involving Panu. Though the same hook will be
called for every font not just Droid. Also, is it something you want to push to
pre-rawhide releases? (will only affect rebuilt packages)

BTW there is an interesting aspect I forgot to mention in my mail: we repaint
the three fonts as droid sans, and droid sans is in the generic "sans" priority
stack. Will that affect the priority of "droid sans japanese" and "droid sans
fallback" in this stack too? I'm not quite sure what the correct behaviour
would be.

-- 
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.