Re: strict check for object modification

[Akira TAGOH <akira@xxxxxxxxx>]

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