Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
Summary: Droid Sans overrides default Japanese desktop font
https://bugzilla.redhat.com/show_bug.cgi?id=517789
Summary: Droid Sans overrides default Japanese desktop font Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: google-droid-fonts AssignedTo: nicolas.mailhot@laposte.net ReportedBy: petersen@redhat.com QAContact: extras-qa@fedoraproject.org CC: nicolas.mailhot@laposte.net, fedora-fonts-bugs-list@redhat.com, fedora-i18n-bugs@redhat.com Estimated Hours: 0.0 Classification: Fedora Target Release: ---
Description of problem: I was just testing a f12alpha spin and discovered that Droid Sans seems to override the default Japanese desktop font.
How reproducible: every time
Steps to Reproduce: 1. yum install google-droid-sans-fonts 2. login to gnome desktop 3. run gucharmap
Actual results: Most kanji glyphs are shown with Droid Sans.
Expected results: Default Japanese IPA font to be used for Japanese characters.
Additional info: Not sure why the Droid fonts were pulled into the spin.
This affects whole Japanese desktop and gdm, etc.
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 #1 from Jens Petersen petersen@redhat.com 2009-08-17 04:20:40 EDT --- This also affects Korean desktop but not Chinese apparently.
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
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |473303(F12Blocker)
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
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mclasen@redhat.com
--- Comment #2 from Jens Petersen petersen@redhat.com 2009-08-19 08:33:41 EDT --- (In reply to comment #0)
Not sure why the Droid fonts were pulled into the spin.
Nevermind, Matthias told me it is from fedora-livecd-desktop.ks.
If we're going to install them by default I think it should be done in @fonts not just for Desktop Live.
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 #3 from Jens Petersen petersen@redhat.com 2009-08-31 04:05:47 EDT --- (In reply to comment #2)
If we're going to install them by default I think it should be done in @fonts not just for Desktop Live.
I filed bug 520361 for this.
65-google-droid-sans.conf: <!-- CJK users should check this actually works for them --> <match target="scan"> <test name="lang"> <string>ja-jp</string> </test> <test name="family"> <string>Droid Sans Japanese</string> : :
I guess the answer for ja is no. ;)
$ fc-match "lang=ja-JP" DroidSansFallback.ttf: "Droid Sans" "Regular"
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
Matthias Clasen mclasen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |520361
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
Nicolas Mailhot nicolas.mailhot@laposte.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?(besfahbo@redhat.c | |om)
--- Comment #4 from Nicolas Mailhot nicolas.mailhot@laposte.net 2009-09-05 11:19:27 EDT --- Droid packaging has not changed for months, I guess this is fallout from all the CJK rules restructuring in fontconfig (I did ask people to check droid too :()
Behdad: do you have an idea on how to restrict this rule properly to Droid Sans and Japanese ? It's not supposed to change the font for non-japanese and non-droid sans
(unless the desktop spin people did set the default font to droid sans, in which case all bets are off)
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
Behdad Esfahbod besfahbo@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |besfahbo@redhat.com Flag|needinfo?(besfahbo@redhat.c | |om) |
--- Comment #5 from Behdad Esfahbod besfahbo@redhat.com 2009-09-05 20:07:28 EDT --- Nicolas, can you summarize what's going on? I'm clueless.
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 #6 from Matthias Clasen mclasen@redhat.com 2009-09-05 22:20:45 EDT --- Droid fonts are included on the desktop spin. They are not the default.
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 #7 from Behdad Esfahbod besfahbo@redhat.com 2009-09-05 23:16:19 EDT --- So, we do want them in the default install? Why?
Nicolas, you can't match language on target="scan". Lemme check your conf file and get back to you.
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 #8 from Nicolas Mailhot nicolas.mailhot@laposte.net 2009-09-06 04:04:47 EDT --- (In reply to comment #5)
Nicolas, can you summarize what's going on? I'm clueless.
Droid is now installed on more systems and CJK users complain it replaces their default non-latin fonts. But the intent of droid's fontconfig rules is not to set those fonts as default. They should only select droid sans japanese if the font is droid sans and the language japanese, and only use droid sans fallback if the font is droid sans and the language something else.
So something is not working as expected
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 #9 from Jens Petersen petersen@redhat.com 2009-09-06 22:28:42 EDT --- (In reply to comment #7)
Nicolas, you can't match language on target="scan". Lemme check your conf file and get back to you.
Thanks I think that summarizes the problem well then.
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 #10 from Jens Petersen petersen@redhat.com 2009-09-06 22:29:52 EDT --- (I might add that for ja desktop Droid replaces even Deja Vu.;)
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 #11 from Behdad Esfahbod besfahbo@redhat.com 2009-09-06 22:41:38 EDT --- This is what I wrote to Nicolas in email:
Hey,
Ok, lets see. A few issues:
1. Why the seemingly random numbers for the conf files?
2. Should I add Droid fonts to default fontconfig config? At least just the aliasing to/from generics?
3. You should also alias back "Droid Sans Japanese" and "Droid Sans Fallback" to "Droid Sans" now that we are renaming those.
4. You use "prefer", while you really should use "accept". That's perhaps why the default Japanese font is affected.
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.
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. 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.
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?
Cheers, behdad
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 #12 from Behdad Esfahbod besfahbo@redhat.com 2009-09-06 22:42:26 EDT --- Created an attachment (id=359939) --> (https://bugzilla.redhat.com/attachment.cgi?id=359939) WIP sans conf
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@laposte.net 2009-09-07 01:53:23 EDT --- (In reply to comment #11)
- 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)
- 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)
- 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
- 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)
- 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?
- 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
- 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.
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 #14 from Nicolas Mailhot nicolas.mailhot@laposte.net 2009-09-07 07:19:37 EDT --- (In reply to comment #13)
(In reply to comment #11)
- Should I add Droid fonts to default fontconfig config? At least just the
aliasing to/from generics?
I'd rather not
However, now that I think of it, users requested several times that we do a very similar thing for Arial (use Arial Unicode to extend Arial, transform Arial Narrow and Arial Black in proper sub-styles of Arial), and this should be included in fontconfig's default rules since the fonts themselves are user (not distro) installed
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 #15 from Behdad Esfahbod besfahbo@redhat.com 2009-09-07 14:26:54 EDT --- (In reply to comment #14)
(In reply to comment #13)
(In reply to comment #11)
- Should I add Droid fonts to default fontconfig config? At least just the
aliasing to/from generics?
I'd rather not
However, now that I think of it, users requested several times that we do a very similar thing for Arial (use Arial Unicode to extend Arial, transform Arial Narrow and Arial Black in proper sub-styles of Arial), and this should be included in fontconfig's default rules since the fonts themselves are user (not distro) installed
The Vista version of those fonts should work since I assume they have WWS names too.
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 #16 from Nicolas Mailhot nicolas.mailhot@laposte.net 2009-09-07 14:32:36 EDT --- (In reply to comment #15)
(In reply to comment #14)
(In reply to comment #13)
However, now that I think of it, users requested several times that we do a very similar thing for Arial (use Arial Unicode to extend Arial, transform Arial Narrow and Arial Black in proper sub-styles of Arial), and this should be included in fontconfig's default rules since the fonts themselves are user (not distro) installed
The Vista version of those fonts should work since I assume they have WWS names too.
Sure but there are quite a lot of users that still use the previous versions that do not have the fixed naming metadata
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
Nicolas Mailhot nicolas.mailhot@laposte.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |521697
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 #17 from Nicolas Mailhot nicolas.mailhot@laposte.net 2009-09-07 15:28:58 EDT --- (In reply to comment #13)
- 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
Sorry I confused it with scriptlets, the fc-query part is Panu-side indeed. Filled bug #521697 to track the rpm part
However, if I understand the logic correctly, you want to replace fc-query with fc-scan to take into account fontconfig rules. That's a great idea *except* the package fontconfig files won't be installed in the build root at this time !
So if that's really the intention, fc-scan needs to grow an argument so we can pass it a set of additional fontconfig files (or a directory containing fontconfig files) explicitely
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 #18 from Nicolas Mailhot nicolas.mailhot@laposte.net 2009-09-07 18:15:03 EDT --- Anyway I pushed https://koji.fedoraproject.org/koji/buildinfo?buildID=130936
it should have all the fixes that do not depend on changes in rpm (that only matter at package resolution time, not once it's installed)
CJK users: please test it does the correct thing for you
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
Nicolas Mailhot nicolas.mailhot@laposte.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?(besfahbo@redhat.c | |om)
--- Comment #19 from Nicolas Mailhot nicolas.mailhot@laposte.net 2009-09-08 14:54:16 EDT --- (In reply to comment #13)
(In reply to comment #11)
- 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
BTW we use two different patterns for aliasing right now:
1. "use font Y to complete font X" (for a font which is installed bug with limited coverage):
<alias> <family>X</family> <default> <family>Y</family> </default> </alias>
2. "use font Y when asked for font X" (for fonts that may not be installed)
<alias binding="same"> <family>X</family> <accept> <family>Y</family> </accept> </alias>
Which pattern is more appropriate for this case?
Also, can we use the same logic to fixup at fontconfig level fonts with bad naming metadata (all the stuff that fails WWS and takes ages to be fixed in the font files upstream)? For example would the following pattern be something that could be generalised? Or do you have objections/better ideas?
<match target="scan"> <test name="family"> <string>Letters Laughing</string> </test> <test name="style"> <string>at their Execution</string> </test> <edit name="family"> <string>Letters Laughing at their Execution</string> </edit> <edit name="style"> <string>Regular</string> </edit> </match>
<alias> <family>Letters Laughing at their Execution</family> <default> <family>Fantasy</family> </default> </alias>
<!-- Not sure at all about this but something is needed for backwards compat --> <alias> <family>Letters Laughing</family> <style>at their Execution</family> <default> <family>Letters Laughing at their Execution</family> <style>Regular<style> </default> </alias>
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
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED
--- Comment #20 from Jens Petersen petersen@redhat.com 2009-09-09 06:05:18 EDT --- (In reply to comment #18)
CJK users: please test it does the correct thing for you
I tested google-droid-fonts-20090906-2.fc12 in rawhide and still overriding Japanese fonts.
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 #21 from Nicolas Mailhot nicolas.mailhot@laposte.net 2009-09-09 06:45:13 EDT --- Jens, when you say "overriding Japanese fonts" what do you mean? What is your testing protocol? Does the behaviour change if your remove the droid fontconfig symlink in /etc/fonts/conf.d?
The original post mentions gucharmap, but I don't think it's the right application to test the CJK language-specific overrides we do in fontconfig rules. You need an app that displays complete text (not just some individual glyphs) and sets the japanese language (tests under the en_US locale are not valid)
Droid itself does not even try to do something specific for japanese anymore
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
Behdad Esfahbod besfahbo@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo?(besfahbo@redhat.c | |om) |
--- Comment #22 from Behdad Esfahbod besfahbo@redhat.com 2009-09-10 11:31:37 EDT --- (In reply to comment #19)
(In reply to comment #13)
(In reply to comment #11)
- 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
BTW we use two different patterns for aliasing right now:
- "use font Y to complete font X" (for a font which is installed bug with
limited coverage):
<alias> <family>X</family> <default> <family>Y</family> </default> </alias>
- "use font Y when asked for font X" (for fonts that may not be installed)
<alias binding="same"> <family>X</family> <accept> <family>Y</family> </accept> </alias>
Which pattern is more appropriate for this case?
The latter.
Also, can we use the same logic to fixup at fontconfig level fonts with bad naming metadata (all the stuff that fails WWS and takes ages to be fixed in the font files upstream)? For example would the following pattern be something that could be generalised? Or do you have objections/better ideas?
<match target="scan"> <test name="family"> <string>Letters Laughing</string> </test> <test name="style"> <string>at their Execution</string> </test> <edit name="family"> <string>Letters Laughing at their Execution</string> </edit> <edit name="style"> <string>Regular</string> </edit> </match>
<alias> <family>Letters Laughing at their Execution</family> <default> <family>Fantasy</family> </default> </alias>
This is a good idea, yes.
<!-- Not sure at all about this but something is needed for backwards compat -->
<alias> <family>Letters Laughing</family> <style>at their Execution</family> <default> <family>Letters Laughing at their Execution</family> <style>Regular<style> </default> </alias>
I wouldn't bother about the style part here.
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 #23 from Nicolas Mailhot nicolas.mailhot@laposte.net 2009-09-10 14:42:40 EDT --- (In reply to comment #22)
(In reply to comment #19)
(In reply to comment #13)
(In reply to comment #11)
- 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
BTW we use two different patterns for aliasing right now:
- "use font Y to complete font X" (for a font which is installed bug with
limited coverage):
<alias> <family>X</family> <default> <family>Y</family> </default> </alias>
- "use font Y when asked for font X" (for fonts that may not be installed)
<alias binding="same"> <family>X</family> <accept> <family>Y</family> </accept> </alias>
Which pattern is more appropriate for this case?
The latter.
Also, can we use the same logic to fixup at fontconfig level fonts with bad naming metadata
This is a good idea, yes.
Thank you for the opinion!
<!-- Not sure at all about this but something is needed for backwards compat -->
<alias> <family>Letters Laughing</family> <style>at their Execution</family> <default> <family>Letters Laughing at their Execution</family> <style>Regular<style> </default> </alias>
I wouldn't bother about the style part here.
Well I certainly need to specify the style of the font to be remapped (since there are other "Letters Laughing" weird styles that need to be mapped at different font families). In that particular case, since "Letters Laughing at their Execution" will have a single style, I guess I could pass on the target style. But what about when you try to remap fonts from the "4 styles" area which have been needlessly split into separate families ? Say, you have an A. font set with R,B,I,BI and an A. Narrow font set also with R,B,I,BI If you write
<alias> <family>A. Narrow</family> <style>Bold</family> <default> <family>A.</family> </default> </alias>
won't that clobber A. Bold? Surely you do need to specify the target style in that case
<alias> <family>A. Narrow</family> <style>Bold</family> <default> <family>A.</family> <style>Narrow Bold</family> </default> </alias>
(too lazy to check how the WWS spec says the "Narrow" qualifier should be written nowadays)
Actually what I was not sure about is that
<default> <family>A.</family> <style>Narrow Bold</family> </default>
will be treated as a single font, not a list but I suppose a list in this context would be stupid, so surely fontconfig will treat it as a single-font pattern, right?
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
Nicolas Mailhot nicolas.mailhot@laposte.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?(besfahbo@redhat.c | |om)
--- Comment #24 from Nicolas Mailhot nicolas.mailhot@laposte.net 2009-09-13 15:35:30 EDT --- Well, I tried it in an actual package and fontconfig errors on the style lines
Fontconfig warning: "/etc/fonts/conf.d/65-senamirmir-washra.conf", line 43: unknown element "style" Fontconfig warning: "/etc/fonts/conf.d/65-senamirmir-washra.conf", line 46: unknown element "style"
<alias binding="same"> <family>Ethiopic WashRa SemiBold</family> <style>Bold</style> ⇐ 43 <accept> <family>Ethiopic WashRa</family> <style>DemiBold</style> ⇐ 46 </accept> </alias>
Behdad: how is one supposed to alias a specific style in fontconfig?
In the meanwhile I also pushed a tweaked droid package that takes Behdad's latest advice into account. I'd be surprised if it had any effect on japanese priority, but who knows.
http://koji.fedoraproject.org/koji/buildinfo?buildID=131757
Someone please test on a CJK system (and report back, detailing the test he used if it does not work)
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 #25 from Jens Petersen petersen@redhat.com 2009-09-14 04:18:14 EDT --- (In reply to comment #24)
google-droid-fonts-20090906-4.fc12
Someone please test on a CJK system
I just tried and no change unfortunately.
(and report back, detailing the test he used if it does not work)
Test: 1) LC_CTYPE=ja_JP.UTF-8 gucharmap 2) search for '和'
Cases: A) with google-droid-sans-fonts installed B) without google-droid-sans-fonts
Results: A) glyph rendered in Droid Sans B) glyph rendered in IPAPGothic
(Of course if you are running a running a japanese desktop (or use LANG instead of LC_CTYPE) you will see whole desktop (application) change too.)
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 #26 from Jens Petersen petersen@redhat.com 2009-09-14 04:34:29 EDT --- A simpler test is probably just:
$ LANG=ja_JP.UTF-8 fc-match lang=ja DroidSansJapanese.ttf: "Droid Sans" "Regular"
So at least it is using DroidSansJapanese now for Japanese, but we don't want to make it the default font for Japanese.
$ LANG=ja_JP.UTF-8 fc-match sans:lang=ja DroidSansJapanese.ttf: "Droid Sans" "Regular" $ LANG=zh_CN.UTF-8 fc-match sans:lang=ja DroidSansJapanese.ttf: "Droid Sans" "Regular" $ LANG=ja_JP.UTF-8 fc-match sans:lang=zh uming.ttc: "AR PL UMing HK" "Light" $ LANG=zh_CN.UTF-8 fc-match sans:lang=zh uming.ttc: "AR PL UMing HK" "Light" $ LANG=zh_CN.UTF-8 fc-match lang=zh DroidSansFallback.ttf: "Droid Sans" "Regular"
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 #27 from Nicolas Mailhot nicolas.mailhot@laposte.net 2009-09-14 05:06:09 EDT --- Well, assuming you have no other fontconfig file referencing droid on-system, I guess that it all a fontconfig problem for Behdad. The droid package does not declare any japanese-specific rule, so the "if japanese, use me first" rules in the ipa packages should take precedence (didn't check they were actually there, I just know they're not in droid)
Does it change if you try LANG=ja_JP.UTF-8 fc-match lang=ja_JP or LANG=ja_JP.UTF-8 fc-match lang=ja-JP ?
I don't think ja is a complete fontconfig locale, and fontconfig does not allow matching on a partial locale sanely (ie it matches any substring, does not really parse the format, so would trip on en-ja or jas-foo etc)
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 #28 from Jens Petersen petersen@redhat.com 2009-09-14 20:25:26 EDT --- (In reply to comment #27)
Does it change if you try LANG=ja_JP.UTF-8 fc-match lang=ja_JP or LANG=ja_JP.UTF-8 fc-match lang=ja-JP ?
No, they also give: DroidSansJapanese.ttf: "Droid Sans" "Regular"
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
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks|473303(F12Blocker) |473302(F12Target)
--- Comment #29 from Jens Petersen petersen@redhat.com 2009-09-24 22:35:45 EDT --- I have commented out google-droid-*-fonts from Desktop Live .ks and moving this to F12Target.
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
Nicolas Mailhot nicolas.mailhot@laposte.net changed:
What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|nicolas.mailhot@laposte.net |besfahbo@redhat.com
--- Comment #30 from Nicolas Mailhot nicolas.mailhot@laposte.net 2009-09-26 06:27:48 EDT --- Reassigning to Behdad, since any progress on this bug depends on him (I'll happily take the bug back once he tells us how to make the fontconfig rules work as expected)
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
Behdad Esfahbod besfahbo@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo?(besfahbo@redhat.c | |om) |
--- Comment #31 from Behdad Esfahbod besfahbo@redhat.com 2009-09-28 14:48:18 EDT --- Lets get back to this after f12...
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
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|besfahbo@redhat.com |nicolas.mailhot@laposte.net
--- Comment #32 from Jens Petersen petersen@redhat.com 2010-02-03 19:37:55 EST --- Shouldn't we have lang="zh" for Droid Sans Fallback and lang="ja" for Droid Sans Japanese in the font .conf?
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 #33 from Jens Petersen petersen@redhat.com 2010-02-03 19:38:56 EST --- or ja-JP etc...
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 #34 from Nicolas Mailhot nicolas.mailhot@laposte.net 2010-02-04 06:13:22 EST --- (In reply to comment #32)
Shouldn't we have lang="zh" for Droid Sans Fallback and lang="ja" for Droid Sans Japanese in the font .conf?
They are not exposed as-is, they're merged in a single "Droid Sans" from the user POW. The problem is that it messes the priority of the CJK bits (we need to distinguish the name exposed to the user and the priorities assigned to each bit that is used to compose the synthetic font)
Can probably be fixed by splitting instructions in separate files with different priorities, but this is not-obvious to do and I need to find the time to play with it some more.
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
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |MODIFIED
--- Comment #36 from Jens Petersen petersen@redhat.com 2010-05-06 04:42:49 EDT --- (Just noticed the discussion about Droid on fedora desktop list...)
This looks fixed to me in F13 with all the fonts .conf locale fixes we have done, including's dropping binding="same".
Maybe someone else could also verify?
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 #37 from Akira TAGOH tagoh@redhat.com 2010-05-10 04:47:42 EDT --- confirmed. this issue however has just been hidden with the renaming the config file to 65-0- thing. this change could be required for Chinese fonts as well, and others perhaps since both are put in the same priority 65 and Droid Sans appears prior to wqy-*-fonts because of the alphabetical order. this is still not good since wqy-zenhei-fonts is the default font for Simplified Chinese.
FWIW having the enough coverage would be nice. but why don't you change the priority to 66 or the lower priority than 65? the priority thing affects how to determine the default font for languages. before giving the higher priority we should have discussion and have agreements for that in the community IMHO. it could be fixed in other fonts, but want to avoid chasing on the priority without the right thing. this is why I want to see more restrict priority policy but anyway.
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
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?(tagoh@redhat.com)
--- Comment #38 from Jens Petersen petersen@redhat.com 2010-07-22 01:54:41 EDT --- Can we close this?
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 #39 from Nicolas Mailhot nicolas.mailhot@laposte.net 2010-09-23 13:44:53 EDT --- (In reply to comment #38)
Can we close this?
Please keep it open, I do not despair of finding a way to conditionalise Droid Sans CJK someday (I try it every other month, so far no luck)
I hope that now Behdad's working for Google it will be easier to coax him in making Droid work perfectly :)
As you noted, the worst side-effect has been hidden by the fontconfig cleanups in other packages
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
Akira TAGOH tagoh@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|MODIFIED |ASSIGNED Flag|needinfo?(tagoh@redhat.com) |
--- Comment #40 from Akira TAGOH tagoh@redhat.com 2010-11-12 03:00:50 EST --- +1 to nim-nim's comment. if we can have the certain solution on this issue, that would be nice rather than just closing by hiding the issue. guess moving back the status may be good.
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
Bug 517789 depends on bug 521697, which changed state.
Bug 521697 Summary: Change rpm autodeps command from fc-query to fc-scan https://bugzilla.redhat.com/show_bug.cgi?id=521697
What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |WONTFIX Status|NEW |CLOSED Resolution|WONTFIX | Status|CLOSED |ASSIGNED
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
Akira TAGOH tagoh@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |FutureFeature Version|13 |rawhide
--- Comment #41 from Akira TAGOH tagoh@redhat.com 2011-05-24 08:38:18 EDT --- We should added a FutureFeature tag to avoid auto-closing by the Bug Zapper accidentally. moving back to rawhide again.
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
Fedora Admin XMLRPC Client fedora-admin-xmlrpc@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|nicolas.mailhot@laposte.net |hobbes1069@gmail.com
--- Comment #42 from Fedora Admin XMLRPC Client fedora-admin-xmlrpc@redhat.com 2011-06-20 17:54:40 EDT --- This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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 #43 from Richard Shaw hobbes1069@gmail.com 2011-06-20 19:54:22 EDT --- Hello everyone. I wanted to introduce myself as I'm the new maintainer for this package.
I'm a relatively new packager but I've been using linux since RH6. I mainly took this package because it's needed by some MythTV themes, so unfortunately I don't have a lot of linux font experience so I may need some direction.
If someone could update me to the current situation for this bug I'd appreciate it.
Thanks, Richard
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
Fedora Admin XMLRPC Client fedora-admin-xmlrpc@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|hobbes1069@gmail.com |nicolas.mailhot@laposte.net
--- Comment #44 from Fedora Admin XMLRPC Client fedora-admin-xmlrpc@redhat.com 2011-06-23 17:08:20 EDT --- This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
https://bugzilla.redhat.com/show_bug.cgi?id=517789
Mike FABIAN mfabian@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mfabian@redhat.com
--- Comment #45 from Mike FABIAN mfabian@redhat.com --- (In reply to comment #26)
A simpler test is probably just:
$ LANG=ja_JP.UTF-8 fc-match lang=ja DroidSansJapanese.ttf: "Droid Sans" "Regular"
I think there is a colon missing in front of “lang=ja”. On Fedora 17 I get:
$ LC_ALL=ja_JP.UTF-8 fc-match DroidSansJapanese.ttf: "Droid Sans" "Regular"
I.e. I still see the problem on Fedora 17. Adding the “lang=ja” changes nothing because of the missing colon:
$ LC_ALL=ja_JP.UTF-8 fc-match lang=ja DroidSansJapanese.ttf: "Droid Sans" "Regular"
But when using “:lang=ja” “VL PGothic” is selected, no matter what the locale is:
$ LC_ALL=ja_JP.UTF-8 fc-match :lang=ja VL-PGothic-Regular.ttf: "VL PGothic" "regular"
$ LC_ALL=en_GB.UTF-8 fc-match :lang=ja VL-PGothic-Regular.ttf: "VL PGothic" "regular"
$ fc-match :lang=ja VL-PGothic-Regular.ttf: "VL PGothic" "regular"
So at least it is using DroidSansJapanese now for Japanese, but we don't want to make it the default font for Japanese.
$ LANG=ja_JP.UTF-8 fc-match sans:lang=ja DroidSansJapanese.ttf: "Droid Sans" "Regular" $ LANG=zh_CN.UTF-8 fc-match sans:lang=ja DroidSansJapanese.ttf: "Droid Sans" "Regular" $ LANG=ja_JP.UTF-8 fc-match sans:lang=zh uming.ttc: "AR PL UMing HK" "Light" $ LANG=zh_CN.UTF-8 fc-match sans:lang=zh uming.ttc: "AR PL UMing HK" "Light" $ LANG=zh_CN.UTF-8 fc-match lang=zh DroidSansFallback.ttf: "Droid Sans" "Regular"
i18n-bugs@lists.fedoraproject.org
-
Red Hat Bugzilla