Bug 476459 - move 66-vlgothic-gothic.conf to 65-1-vlgothic-gothic.conf
move 66-vlgothic-gothic.conf to 65-1-vlgothic-gothic.conf
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: vlgothic-fonts (Show other bugs)
rawhide
All Linux
high Severity medium
: ---
: ---
Assigned To: Akira TAGOH
Fedora Extras Quality Assurance
: Reopened
Depends On: 554911
Blocks: F13Blocker/F13FinalBlocker
  Show dependency treegraph
 
Reported: 2008-12-14 19:20 EST by Warren Togami
Modified: 2014-01-21 18:03 EST (History)
9 users (show)

See Also:
Fixed In Version: vlgothic-fonts-20100126-1.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-01 20:10:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
fc-match-4.output.bz2 (48.95 KB, application/x-bzip)
2009-02-15 21:34 EST, Jens Petersen
no flags Details
add fedora fontconfig for zh (2.06 KB, patch)
2009-12-06 22:32 EST, Jens Petersen
no flags Details | Diff
fedora .conf file for zh (1.47 KB, application/octet-stream)
2009-12-06 22:34 EST, Jens Petersen
no flags Details

  None (edit)
Description Warren Togami 2008-12-14 19:20:50 EST
Make wqy-zenhei-fonts default in the chinese-support group.

Make sure it does not take over as default desktop font (unless desired).
Comment 1 Jens Petersen 2009-01-28 19:58:34 EST
Qianqian, any idea how to do this: I think currently installing zenhei makes it take over the Chinese desktop overriding cjkuni-fonts?
Comment 2 Jens Petersen 2009-02-09 00:10:46 EST
Can we soften the font config so that wqy-zenhei-fonts can be installed by default by Chinese without taking over the whole desktop? :)
Comment 3 Qianqian Fang 2009-02-09 00:29:56 EST
hi Jens

I am not entirely sure if I understood "setting as default" and "not overriding", maybe you can explain it a little bit more?

As you know, Uming is a Song/Mincho style font, therefore, it is close to "serif" alias, and wqy-zenhei is a Hei/Gothic font with sans-serif styled glyphs for both proportional and monospaced faces (in a single ttc). On Ubuntu, uming is used as the default serif and wqy-zenhei as the default sans-serif for zh locales. is this what you intend to achieve?
Comment 4 Jens Petersen 2009-02-09 01:37:59 EST
(In reply to comment #3)
> I am not entirely sure if I understood "setting as default" and "not
> overriding", maybe you can explain it a little bit more?

I wrote "install as default", ie meaning install the package by default.

Overriding means that installation should not override other default desktop fonts, like dejavu-fonts and cjkuni-fonts

> As you know, Uming is a Song/Mincho style font, therefore, it is close to
> "serif" alias, and wqy-zenhei is a Hei/Gothic font with sans-serif styled
> glyphs for both proportional and monospaced faces (in a single ttc). On Ubuntu,
> uming is used as the default serif and wqy-zenhei as the default sans-serif for
> zh locales. is this what you intend to achieve?

Eventually maybe. :)  What about Ukai?

Last I tested wqy-zenhei was still too aggressive in priority to coexist with cjkuni-fonts.

Thanks for the information about ubuntu's defaults.
Comment 5 Qianqian Fang 2009-02-09 10:44:26 EST
(In reply to comment #4)
> 
> I wrote "install as default", ie meaning install the package by default.
> 
> Overriding means that installation should not override other default desktop
> fonts, like dejavu-fonts and cjkuni-fonts

ok, that's fine (zenhei had never overrode dejavu), I will change the settings when I update the fontconfig file to follow the new guideline (I am still not able to compile due to %{_fontdir} definition #478891). However, I would like to remind that this basically means Uming will "override" sans-serif and monospace and all Chinese will be displayed as bitmaps. Also there is no way to use Dejavu and zenhei together anymore.

> 
> Eventually maybe. :)  What about Ukai?
> 

this is up to you and the Chinese i18n. I rarely see people use Ukai as desktop fonts despite that fontconfig default settings giving it high priority, as it is designed mostly for printing, and it look very blurry on screen.
Comment 6 Jens Petersen 2009-02-09 18:21:17 EST
Okay I think if you restrict wqy-zenhei-fonts to just zh, which has similarly been done to fedora cjkuni-fonts and baekmuk-ttf-fonts recently with font conf directives to restrict to one language (to avoid unihan issues, etc) then we can start to think about this seriously.
Comment 7 Jens Petersen 2009-02-09 18:24:09 EST
Though better in the long term would be to get the font included in fontconfig's /etc/fonts/conf.d/65-nonlatin.conf file like dejavu, cjkuni, etc.
Comment 8 Qianqian Fang 2009-02-09 18:37:47 EST
(In reply to comment #7)
> Though better in the long term would be to get the font included in
> fontconfig's /etc/fonts/conf.d/65-nonlatin.conf file like dejavu, cjkuni, etc.

Certainly. I heard the fontconfig developers were re-working on the default font priorities last year, but then, nothing has happened.
Comment 9 Qianqian Fang 2009-02-10 14:34:49 EST
here I have a problem: in 44-wqy-zenhei.conf, I used alias sections to set the preferences, I remember this is the recommended way of setting the priorities, however, if I want to use lang tags, I may have to write this whole section using match and prepend, or kill the whole section. 

Jens, is this what you want to do?

----------------------------------------------------

        <alias>
                <family>serif</family>
                <prefer>
                        <family>Bitstream Vera Serif</family>
                        <family>DejaVu Serif</family>
                        <family>WenQuanYi Zen Hei</family>
                </prefer>
        </alias>
        <alias>
                <family>sans-serif</family>
                <prefer>
                        <family>Bitstream Vera Sans</family>
                        <family>DejaVu Sans</family>
                        <family>WenQuanYi Zen Hei</family>
                </prefer>
        </alias>
        <alias>
                <family>monospace</family>
                <prefer>
                        <family>Bitstream Vera Sans Mono</family>
                        <family>DejaVu Sans Mono</family>
                        <family>WenQuanYi Zen Hei Mono</family>
                </prefer>
        </alias>
Comment 10 Qianqian Fang 2009-02-11 19:12:48 EST
ok, I just killed the alias sections in 44-wqy-zenhei.conf. Basically, this means users have to manually select this font to use in their desktop or browsers; if they want to use dejavu and zenhei together, they have to code up their conf file, or wish one day the ancient font orders in 65-nonlatin get updated.

Jens, let me know if this is good, thanks
Comment 11 Qianqian Fang 2009-02-12 00:33:28 EST
new package was built in rawhide.
Comment 12 Jens Petersen 2009-02-13 00:22:46 EST
(In reply to comment #10)
> ok, I just killed the alias sections in 44-wqy-zenhei.conf. Basically, this
> means users have to manually select this font to use in their desktop or
> browsers; if they want to use dejavu and zenhei together, they have to code up
> their conf file, or wish one day the ancient font orders in 65-nonlatin get
> updated.

You could still include the old config file in avail.d/.

> Jens, let me know if this is good, thanks

I tried wqy-zenhei-fonts-0.8.34-2.20081027cvs.fc11 and it still behaves the same way for me on a Japanese desktop, overriding the default Japanese font.
Comment 13 Qianqian Fang 2009-02-13 10:14:20 EST
Was your desktop font set as "sans"? and your lang=ja? Can you attach the 44-wqy-zenhei.conf file and the debug output:
  FC_DEBUG=4 fc-match -s "sans:lang=ja"
Comment 14 Nicolas Mailhot 2009-02-14 07:53:43 EST
Will all the font changes in rawhide it would probably not be total waste if people with CJK knowledge did install all the rawhide font packages and check we do the right thing for sans/serif/monospace for CJK languages.
Comment 15 Jens Petersen 2009-02-15 21:32:59 EST
(In reply to comment #13)
> Was your desktop font set as "sans"? and your lang=ja?

Yes it is a default Japanese rawhide install.

> Can you attach the 44-wqy-zenhei.conf file

You mean it works for you in a japanese desktop session? ;-)

35f7bdfcc512ac6cb03a520e702a0c45  /etc/fonts/conf.d/44-wqy-zenhei.conf

(I am not excluding a fontconfig bug: at least the behaviour seems have changed...)
Comment 16 Jens Petersen 2009-02-15 21:34:26 EST
Created attachment 331999 [details]
fc-match-4.output.bz2

output for

> FC_DEBUG=4 fc-match -s "sans:lang=ja"
Comment 17 Qianqian Fang 2009-04-15 23:07:56 EDT
hi Jens

are you sure you are using the rawhide version of wqy-zenhei-fonts (0.8.38-2.f11)? in Feb. I already removed all the font preference from 44-wqy-zenhei.conf (see my reply earlier), so if the font order are not right, I don't think it has to do with the configuration files of for wqy-zenhei-fonts.

Let me know what you find out.
Comment 18 Jens Petersen 2009-04-16 03:08:42 EDT
I am using the latest package in rawhide (devel).

Then perhaps it is 65-nonlatin.conf? :-/
Comment 19 Qianqian Fang 2009-04-16 23:41:37 EDT
if 65-nonlatin has not been changed from F10 to F11, then I don't think it caused this problem either (while, it did cause difficulties for CJK font selections as I described in the upstream bug, but that was already taken care of by the past revisions of all the 3rd party font config hacks, such as those for wqy-zenhei and wqy-bitmap-song, the only thing we can do better is to incorporate these hacks into fontconfig upstream, but, this is a different problem).

I still give my biggest suspicion to cairo.
Comment 20 Qianqian Fang 2009-04-16 23:53:25 EDT
(In reply to comment #19)
> I still give my biggest suspicion to cairo.  

sorry, this comment was actually talking about Bug#492510.

> FC_DEBUG=4 fc-match -s "sans:lang=ja"  

Which Japanese font did you expect to be selected as the first? From your fc-match output, I can't find any specific settings that gives higher priority for a Japanese font. Does a japanese-specific fontconfig setting exist? 

(by the way, I really think fedora should have a language-selector-%locale% type of configurations for each cjk language, like in Ubuntu, that can save a lot of troubles).
Comment 21 Jens Petersen 2009-04-17 02:07:29 EDT
(In reply to comment #20)
> > FC_DEBUG=4 fc-match -s "sans:lang=ja"  
> 
> Which Japanese font did you expect to be selected as the first?

VL Gothic

> Does a japanese-specific fontconfig setting exist? 

Yes, vlgothic-fonts should have font .conf.

> (by the way, I really think fedora should have a language-selector-%locale%
> type of configurations for each cjk language, like in Ubuntu, that can save a
> lot of troubles).  

Do you have a URL?  I would like to look at it.
Comment 22 Akira TAGOH 2009-04-17 06:52:22 EDT
(In reply to comment #18)
> I am using the latest package in rawhide (devel).
> 
> Then perhaps it is 65-nonlatin.conf? :-/  

Probably it is. I don't see any fault in the config for wqy-zenhei-fonts except the numeral prefix maybe?
Anyway it should be a separate issue.
Comment 23 Qianqian Fang 2009-04-19 15:10:49 EDT
just for the record, I posted my diagnosis to this problem as the comment to Bug#492510.
Comment 24 Jens Petersen 2009-04-30 03:15:10 EDT
Let's separate the discussion on bitmap-song and zenhei properly.

from bug 492510:

> Actually, I think the font order in the current 65-nonlatin.conf is fine: as it
> does not assume specific language, I believe it is a good idea to put
> large-coverage fonts in front of small ones (see
> https://bugs.freedesktop.org/show_bug.cgi?id=20911). The only problem is, there
> is no Japanese specific font priority settings to boost VL Gothic for ja
> locale!

Right, 66-vlgothic-fonts.conf comes after..

> Here is Ubuntu's way to solve this: a list of language specific (CJK only)
> fontconfig settings are stored in conf.avail, named with
> "{29,69,99}-language-selector-xxxx.conf" where xxxx include zh-cn, zh-hk,
> zh-..., ja-jp and ko-kr. For a given desktop locale, it will link the
> corresponding conf file to conf.d. Although it is a little bit messy, but I
> think it serves the purpose well: 65-nonlatin is the default font order without
> assuming any specific lang, if you want to overwrite that for a specific
> locale, you have to add a lang-specific conf file.

I tested language-selector - it actually has a problem currently: eg its settings will override CJK fonts even when other CJK locale for app is specified.

> If we are short of time for F11, I can temporarily add a xx-wqy-zenhei.conf and
> set VL Gothic in front of ZenHei when lang=ja

That doesn't sound like the right fix IMHO but perhaps I am missing something.
Comment 25 Akira TAGOH 2009-04-30 03:41:30 EDT
(In reply to comment #24)
> > If we are short of time for F11, I can temporarily add a xx-wqy-zenhei.conf and
> > set VL Gothic in front of ZenHei when lang=ja
> 
> That doesn't sound like the right fix IMHO but perhaps I am missing something.  

I agree with this. why don't we just restrict to apply ZenHei for only Chinese? adding something not-owned by the package looks ugly and isn't the right thing to do.
Comment 26 Akira TAGOH 2009-05-07 23:04:00 EDT
From Bug #492510:
(In reply to comment #51)
> Indeed, I don't mind taking wqy-bitmap-fonts out from the default Chinese font
> list, and replaced by wqy-zenhei-fonts instead, since zenhei already embedded
> all the bitmaps and is smaller in size (disabled by default).
> 
> Then the key question is how to fix the overwritten problem between wqy-zenhei
> and vlgothic config files.  

As the suspicious was pointed out the above, I've confirmed getting rid of WenQuanYi ZenHei from 65-nonlatin.conf fixes this issue.
Comment 27 Qianqian Fang 2009-05-08 01:32:31 EDT
(In reply to comment #26)
> As the suspicious was pointed out the above, I've confirmed getting rid of
> WenQuanYi ZenHei from 65-nonlatin.conf fixes this issue.  

This id definitely not a right fix. Rename your 66-vlgothic config files to 44 or other numbers will also fix it. But as I said, the only solution is to coordinate between our config files, not to eliminate the other.
Comment 28 Akira TAGOH 2009-05-08 03:13:05 EDT
(In reply to comment #27)
> (In reply to comment #26)
> > As the suspicious was pointed out the above, I've confirmed getting rid of
> > WenQuanYi ZenHei from 65-nonlatin.conf fixes this issue.  
> 
> This id definitely not a right fix. Rename your 66-vlgothic config files to 44
> or other numbers will also fix it. But as I said, the only solution is to
> coordinate between our config files, not to eliminate the other.  

No. remember that vlgothic fonts' fontconfig rule is only applied when lang == ja now. if I get rid of it, this numeral prefix race will breaks Chinese rendering. it doesn't solve ANYTHING. furthermore as you suggested the above, the language-selector idea also applies the rules at the same priority for CJK. I thought we have agreed that the difference is it's done by inside fontconfig or outside.  if you're right, that would also means that idea won't solve anything then. I don't think so. and actually it works properly if it's gone from 65-nonlatin.conf.

What's the issue you mind when it's gone from 65-nonlatin.conf?
Comment 29 Qianqian Fang 2009-05-08 15:28:25 EDT
(In reply to comment #28)
> What's the issue you mind when it's gone from 65-nonlatin.conf?  

Because it is going completely to the other direction as what I was proposing: I hope to centralize all CJK font order settings into 1) 65-nonlatin and 2) a set of language-specific files. Removing font settings from theses centralized places and scatter these settings into multiple font packages will only increase the chance of conflict.

Indeed, I tested my proposal and things are working perfectly. You can find my latest proposal at https://bugzilla.redhat.com/show_bug.cgi?id=499902 and I love to know what you think.
Comment 30 Akira TAGOH 2009-05-11 22:38:51 EDT
that idea is hard to maintain the rule. as you are aware, even current rule is outdated. maintaining it in the font packages with the accurate policy would rather be better than centralized management. aside from that, it just reflects your favorite someone may not likes. one could do modify it any time, but it may breaks after updating or causes the unwanted file creation on the packaging management system. applying the necessary rules with installing the package would be easier and intuitive.
Comment 31 Qianqian Fang 2009-05-12 00:32:42 EDT
(In reply to comment #30)
> that idea is hard to maintain the rule. as you are aware, even current rule is
> outdated. maintaining it in the font packages with the accurate policy would
> rather be better than centralized management. 

I don't think so. I am not saying this must be included in fontconfig upstream (which get updated slowly), we can certainly create a new package which only include these CJK specific config files. Even fontconfig have similar files, we can still ship something to override if it gets updated. But the key idea is not to let individual font to do this. Functional-wise, they are completely equivalent.


> aside from that, it just reflects
> your favorite someone may not likes. one could do modify it any time, but it
> may breaks after updating or causes the unwanted file creation on the packaging
> management system. applying the necessary rules with installing the package
> would be easier and intuitive.  

Either way does not prevent people from customizing their own list. As I said, they are simply equivalent.
Comment 32 Akira TAGOH 2009-05-12 00:55:36 EDT
(In reply to comment #31)
> I don't think so. I am not saying this must be included in fontconfig upstream
> (which get updated slowly), we can certainly create a new package which only
> include these CJK specific config files. Even fontconfig have similar files, we
> can still ship something to override if it gets updated. But the key idea is
> not to let individual font to do this. Functional-wise, they are completely
> equivalent.

I have never been saying about fontconfig upstream but the centralized management is painful to maintain.

> Either way does not prevent people from customizing their own list. As I said,
> they are simply equivalent.  

Sure. so how is it better than applying it with the package installation then?
Comment 33 Qianqian Fang 2009-05-12 01:09:12 EDT
(In reply to comment #32)
> Sure. so how is it better than applying it with the package installation then?  

To activate rules when installing font package is still possible with centralized approach. Just check out how WenQuanYi Bitmap Song is configured in Bug#499902.
Comment 34 Akira TAGOH 2009-05-12 03:25:57 EDT
(In reply to comment #33)
> (In reply to comment #32)
> > Sure. so how is it better than applying it with the package installation then?  
> 
> To activate rules when installing font package is still possible with
> centralized approach. Just check out how WenQuanYi Bitmap Song is configured in
> Bug#499902.  

It just works for your desired packages. but not for someone's. that's not a neutral solution. we can suggest the default font in comps. but someone may not likes that. the centralized management for the rule would prevents to use the preferred font packages for users. I'm afraid you can't maintain/update it without painful for you and everyone nor without any notice from the font package maintainers.


The point I'm saying is:

* Do not make any changes that affects to the other font packages.
  -> this can be solved to apply the rule for the specific language.

* Do not make any changes that depends on the other font packages. otherwise it must has certain dependencies in the package.

* Maintaining all of the font packages available on Fedora at the centralized fontconfig rule isn't realistic. as fontconfig is capable to read the rule from each fonts, maintaining it in each font packages with the certain policy would works enough.

  Right now some font packages doesn't follow even current policy. we have to mass-file a bug for them in F-12.
Comment 35 Qianqian Fang 2009-05-12 10:43:46 EDT
(In reply to comment #34)
> It just works for your desired packages. but not for someone's. that's not a
> neutral solution. 

But you do realize, in the end, there only exists one font order, no matter which way you set it. It is impossible for two fonts to be both preferred if they are both installed. If you want to control the orders by the presence of fonts, you can do exactly the same thing with a centralized conf file. The only difference is that a single config file gives you a master fallback list, and what you suggested determines this list ad-hoc, which is more difficult to predict and debug.

> we can suggest the default font in comps. but someone may not
> likes that. the centralized management for the rule would prevents to use the
> preferred font packages for users. I'm afraid you can't maintain/update it
> without painful for you and everyone nor without any notice from the font
> package maintainers.
> 
> 
> The point I'm saying is:
> 
> * Do not make any changes that affects to the other font packages.
>   -> this can be solved to apply the rule for the specific language.

IMHO, this is impossible. If you set <prefer> or use prepend/prepend_first, you ARE affecting other font packages. Indeed, that's how fontconfig works. Again, for a given system state, there is only one priority list for each language, no matter you set it from a single file, or by a bunch of font-specific files.

> 
> * Do not make any changes that depends on the other font packages. otherwise it
> must has certain dependencies in the package.

It's not dependency, it is fallback relationship. If you set priority as A>B>C and some of them do not present, fontconfig will pick up the next one with the highest priority. I think that's how fontconfig was designed.

> 
> * Maintaining all of the font packages available on Fedora at the centralized
> fontconfig rule isn't realistic. as fontconfig is capable to read the rule from
> each fonts, maintaining it in each font packages with the certain policy would
> works enough.

If you check my old posts, I used to be a supporter to font-specific config files, because I know the fonts I maintained are good, but other high priority fonts prevent the use of these good one but I have no control (for exp. 65-nonlatin). I endured a lot of troubles in order to set my own list. Now I am suggesting to get things right from the very beginning, and save time of the font maintainers. In you really want to insist, you can still do what you have been doing, but having a up-to-date default language-specific font list will greatly reduce the amount of work you need to do.

> 
>   Right now some font packages doesn't follow even current policy. we have to
> mass-file a bug for them in F-12.
Comment 36 Akira TAGOH 2009-05-12 22:27:01 EDT
(In reply to comment #35)
> But you do realize, in the end, there only exists one font order, no matter
> which way you set it. It is impossible for two fonts to be both preferred if
> they are both installed. If you want to control the orders by the presence of
> fonts, you can do exactly the same thing with a centralized conf file. The only
> difference is that a single config file gives you a master fallback list, and
> what you suggested determines this list ad-hoc, which is more difficult to
> predict and debug.

That's the policy to not mess up.

> IMHO, this is impossible. If you set <prefer> or use prepend/prepend_first, you
> ARE affecting other font packages. Indeed, that's how fontconfig works. Again,
> for a given system state, there is only one priority list for each language, no
> matter you set it from a single file, or by a bunch of font-specific files.

Right. I meant language, but not font packages. sorry.

> It's not dependency, it is fallback relationship. If you set priority as A>B>C
> and some of them do not present, fontconfig will pick up the next one with the
> highest priority. I think that's how fontconfig was designed.

At least you should do as long as you expect them to get it working. otherwise you just leave it to outside your rule.
If you have a dependency in the package, the referred font package owner or that package owner can realizes any attentions is needed when something is changed. you can prevent the font naming issue you've faced in wqy-bitmap-fonts say.

> If you check my old posts, I used to be a supporter to font-specific config
> files, because I know the fonts I maintained are good, but other high priority
> fonts prevent the use of these good one but I have no control (for exp.
> 65-nonlatin). I endured a lot of troubles in order to set my own list. Now I am
> suggesting to get things right from the very beginning, and save time of the
> font maintainers. In you really want to insist, you can still do what you have
> been doing, but having a up-to-date default language-specific font list will
> greatly reduce the amount of work you need to do.

Yes, but what you are suggesting is actually the same thing what fontconfig does because both are centralized management. why you feel it's comfortable is, you're about to get an control of it. it's not necessarily a happy solution for everyone.
Comment 37 Bill Nottingham 2009-05-15 15:11:46 EDT
This font is no longer installed by default, so removing from the blocker list.
Comment 38 Bill Nottingham 2009-05-15 15:12:27 EDT
Whoops, wrong bug.
Comment 39 Bug Zapper 2009-06-09 06:16:28 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 40 Jens Petersen 2009-12-06 21:45:31 EST
We need a .conf file in fedora to make this only apply for zh
like we do for other CJK fonts.
Comment 41 Jens Petersen 2009-12-06 22:32:49 EST
Created attachment 376560 [details]
add fedora fontconfig for zh

This adds the following .conf file to the package and works well for me.

Any objections to commiting this to package cvs?
Comment 42 Jens Petersen 2009-12-06 22:34:49 EST
Created attachment 376561 [details]
fedora .conf file for zh

Based on the vlgothic .conf files and
/usr/share/fontconfig/templates/l10n-font-template.conf.
Comment 43 Jens Petersen 2009-12-07 02:49:13 EST
I am changing comps-f13 to make wqy-zenhei-fonts the default
Chinese default font.
Comment 44 Jens Petersen 2009-12-07 03:23:30 EST
Not sure how TC users feel about zenhei so it may make
sense to have zenhei as default SC font and uming (though serif)
as TC font still perhaps, but let's test a little in rawhide first.
Comment 45 Jens Petersen 2009-12-20 19:36:13 EST
F13 rawhide is now using comps-f13 and zenhei is not overriding
ja so going ahead with the above change.
Comment 46 Jens Petersen 2009-12-20 20:18:06 EST
Actually I think we should do this for f12 and f11 too.
Comment 47 Jens Petersen 2009-12-21 04:24:09 EST
However the 65-wqy-zenhei.conf is not enough. :-(

I think we need to get rid of 65-nonlatin.conf!
or at least prune it (of fedora fonts).
Comment 48 fujiwara 2010-01-21 21:48:20 EST
How about using prepend_first instead of prepend ?
In my test, prepend_first could fix this problem.

If you like wqy-zenhei for zh, you also may need to change 64-ttf-arphic-uming.conf .

BTW, I recommend to use compare="contains" attribute in lang tag.
Currently :lang=ja-jp works fine but :lang=ja doesn't work while Red Hat doesn't provide the short locale names.

        <test name="lang" compare="contains">
            <string>ja</string>
        </test>
Comment 49 Jens Petersen 2010-02-02 03:19:17 EST
Maybe binding="strong" for vlgothic is a better workaround?
Comment 50 Jens Petersen 2010-02-22 23:52:16 EST
Replacing the "65" priority with "65-0", etc in Fedora fonts packages
with lang tags should help according to Behdad.

Need to test to verify this, but it sounds a reasonable solution.
Comment 51 Jens Petersen 2010-02-24 00:15:37 EST
Moving this to vlgothic since we can fix it there easily.

Other fonts packages should also follow: so maybe we should have a tracking bug?
Comment 52 Jens Petersen 2010-02-24 00:17:31 EST
(Similarly 65-vlgothic-pgothic.conf should move to
65-0-vlgothic-pgothic.conf of course.)
Comment 53 Akira TAGOH 2010-03-01 02:45:07 EST
fixed in vlgothic-fonts-20100126-1.fc14.
Comment 54 Fedora Update System 2010-03-01 03:28:04 EST
vlgothic-fonts-20100126-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/vlgothic-fonts-20100126-1.fc13
Comment 55 Fedora Update System 2010-03-01 03:44:38 EST
vlgothic-fonts-20100126-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/vlgothic-fonts-20100126-1.fc12
Comment 56 Fedora Update System 2010-03-01 03:59:46 EST
vlgothic-fonts-20100126-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/vlgothic-fonts-20100126-1.fc11
Comment 57 Fedora Update System 2010-03-01 19:51:39 EST
vlgothic-fonts-20100126-1.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 58 Fedora Update System 2010-03-01 19:53:43 EST
vlgothic-fonts-20100126-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 59 Fedora Update System 2010-03-01 20:09:58 EST
vlgothic-fonts-20100126-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.