Le vendredi 27 novembre 2009 à 13:46 -0500, Qianqian Fang a écrit : > Nicolas Mailhot wrote: > > This is about things like > > http://bugs.freedesktop.org/show_bug.cgi?id=20911 > > that should not exist at all if the config syntax was clearer for > human > > beings ("with X, ... I don't think it can do any harm at all." > famous > > last words of one of the commenters, if you knew how often I read > > something like that from a CJK packager word to see a new bug opened > a > > month later) > > > I see you are teasing me here. I thought on this issue, we > are on the same side. I hope we are :) As far as I'm concerned, it's not a Fedora vs Debian, there are only two distributions that try to push the fontconfig enveloppe right now, our approaches differ but not the objectives. > > Many many CJK fontconfig configuration bugs occur because lang (as a > rendering > > context) is confused with lang (as specific glyphs in a font) > look, isn't this the same (sort of) as I proposed in the > Comment#16 in the above bug? > > I apologize for causing issues when using the fontconfig > files I wrote for several CJK fonts. But I do want to remind you > that this is largely due to the complex nature of CJK, not by > others. I that was not clear I'm not blaming you or other CJK users. They're not worse than other font users, they just inherited more difficult requirements. I'm fairly sure that as Indic and Arabic fonts become more numerous, those other regions will experiment the same pains (since they also have the same glyph sharing problems) If I wrote this suite of messages on the fontconfig list it's also because we were talking past one another in the bug tracker, and if we both, after spending a fairly long time working with fontconfig, can not explain to one another what the correct sane syntax to use should be, we have a huge problem. I don't want a fontconfig syntax I barely understand for basic stuff like declaring a CJK font. I want a syntax which is simple enough I can understand it *and* explain to someone who never packaged a font for fontconfig before. Not a "use this bit of vodoo here just because" but "use this here because here is the general syntax model and see how we're just declining it for your use case". I need to be able to coach font packagers with little technical experience, very basic English skills, from cultures where you don't ask questions publicly when you don't understand, and besides which may be in a different timezone and never available for an online chat to clarify matters. Current fontconfig syntax, is not helping a lot. > Talking about syntax, I am sort of agree on both sides. > Yes, using prepend/prepend_first/postpend..., you can do most > things a specific language requires. Indeed, that's what > I used to do, but being blamed badly in the past [1]. In > Fedora's fontconfig guideline, the only "clean" syntax > for setting font orders is "<alias><prefer></prefer></alias>", > anything else, prepend/prepend_first with/wo strong binding, > will be treated as monsters. Note that they won't be treated as monsters, because they don't get the job done, they're treated as monsters, because they make it unsafe for other packagers to write other fontconfig rules. Without them you can assume a rule declared in a file with 64 prefix will take precedence over rules declares in a file > 64, with them all bets are of and rules priority does not map to fontconfig file prefix number anymore. > And yes, if <alias><prefer> support language tag inside, > it would make these rules looks a lot nicer, and of course, > help me get away from a lot of blames by using the > "fragile" constructs. > > So, in summary, I support to add the proposed syntax to > fontconfig; but if you do not get enough support to add this > to fontconfig, then please don't blame cjk people in the > future by using the low-level operations. I'm fairly sure you could do most of it with low-level operations today. I'm not sure the complexity of the low-level syntax makes it possible for people to easily agree on what the correct pattern should be. From my POW, getting fontconfig to work for CJK should be a priority, as that's unfortunately where a large proportion of current fontconfig problems lay today. And not because of a specific flaw in CJK packagers, but because of the inadequacy of the tools that exist to their needs. > Now back to the original thread, I personally don't > think it is much of a CJK issue. I think what was originally > asked is about the granularity of fontconfig: fontconfig > has font-level fallback and glyph-block (in terms of lang) > level fallback, but it does not seem to have glyph-level > fallback. CJK issue can be pretty much solved by the second > level, but glyph-level is a even finer one. I too think > this is something fontconfig developers need to think > of in the future. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=381311#c0 Regards, -- Nicolas Mailhot _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
