On 13-01-10 09:19 PM, Akira TAGOH wrote: > On Fri, Jan 11, 2013 at 7:31 AM, Behdad Esfahbod <behdad@xxxxxxxxxx > <mailto:behdad@xxxxxxxxxx>> wrote: > > Hi, > > I just pushed a change to Pango that allows one to enable OpenType font > features through fontconfig configs. For example: > > <match target="font"> > <edit name="pangofontfeatures" mode="append"> > <string>smcp</string> > <string>ss20</string> > </edit> > </match> > > But I figured this is probably of interest to more than just Pango. Shall we > upstream this? > > > Thanks. yes. I was working on it and have a somewhat incomplete patch to Pango > too, including pango markup support. it a bit got stuck because there are two > issues I should address and didn't have a time to do: > > 1) whether or not we should validate the given feature tag in config. it may > be relevant to what you questioned at GNOME bug in other mail. on other hand, > do we want to make another deps in fontconfig, i.e. harfbuzz for this purpose? > otherwise what we can do for this is to add the object type for this and I've > already done that in my repo: > http://cgit.freedesktop.org/~tagoh/fontconfig/commit/?h=bz50497 I don't think we should validate. Just pass data around. Should we call it OT_FEATURES or more generically FONT_FEATURES? If and when we add AAT support (or the existing Graphite support), those backends will use these same tags as far as HarfBuzz API is concerned. CSS calls them font-features, that's why I chose that. > 2) This isn't really a fontconfig side but needed further work to allow to > have multiple PangoAttribute at same time. if it's useful, I can send a patch > to you. anyway, just to share my efforts, Right. That's why I've been putting this off. I need to extend the PangoAttribute framework to allow "reducing" a set of attributes to a single value, in this case, add the lists of features together or something. > "pangoprgname", which pango sets to the output of g_get_prgname(). If you are > running gedit, it expands to gedit. It's useful for doing per-app > configuration. Any interest in upstreaming that? > > Yeah, when that discussion was brought up here, I thought it would be useful > if we can have similar thing in fontconfig. so users can manage the > app-specific rules in config without modifying any code in apps. Ok, I'll push it up. Any name preference? FC_PRGNAME is fine? Should DefaultSubstitute try to populate that using system-specific heuristics? (/proc/self/exe or something) behdad _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig