On Wed, Aug 15, 2012 at 10:40 PM, Raimund Steger <rs@xxxxxxxx> wrote: > I see, yes this is a mistake that sometimes happens (which can often > be fixed with qual="first" as well), but even if embeddedbitmap was BTW given that doing it in the user fonts.conf, if the pattern list is changed later, that won't work as expected. this is highly likely that some rules are performed after 50-user.conf. > [slightly OT] But actually I think that users normally *want* to mix > matcher and render options in the same pattern, because the distinction > isn't always so clear. A classic example is 'pixelsize' which is > sometimes necessary to select a font and sometimes it's just a render > option. Another example might someday even be 'family' which is now > mostly interesting in the match but might in the future just be a render > option of a larger font container format or whatever. At the same time, > the fontconfig matcher will certainly evolve in the future and drop > certain properties, introduce new ones etc. > > Splitting the pattern in two like that would appear as a rather > artificial thing to do which might only expose volatile white-box details of > fontconfig to the user. Indeed. it's just an idea yet. I think I could clarified in this discussion what we need to try in the future. so if there are any better solution to address it, we can go with it. -- Akira TAGOH _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
