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. > Actually, it should have been something like: > > <alias> > <font> > <family>[genericname]</family> > <langrequest>[loc]</langrequest> > <langcover>[loc]</langcover> > </font> > <prefer> > <font> > <family>[fontname]</family> > </font> > </prefer> > </alias> > > ... > > 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. Most non-CJK languages don't have the z(shape)-variant problems as in CJK; and they also don't need to embed bitmaps to make their glyph readable. So, the reason you see more complains about CJK is rather a reflection to the insufficiency to handle these unique problems in the current font rendering pipeline (I know most of you hate bitmaps). 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. 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. 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 _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
