[Fontconfig] strict check for object modification

[Raimund Steger]

Akira TAGOH wrote:
> On Tue, Aug 14, 2012 at 9:38 AM, Raimund Steger <rs at mytum.de> wrote:
>> [...]
> [...]
> the result of FcFontMatch() in their code - actually it's hard to
> recognize what objects are added in the rules or the initial pattern.
> if we want to make obvious difference between target="pattern" and
> target="font", FcFontMatch() should returns FcPattern from the cache
> as is.

But why would it be so important to recognize a difference here? I guess 
I fail to see the point of it all. Is there any significant user 
confusion coming from this area at the moment? The current behavior is 
documented (and the pattern merge can be observed with 'FC_DEBUG=1 
fc-match -v foo'), and correctly ensures that no properties that are 
"wrong" in the context of the best match are present in the result.


> Well, I don't still see why it can't be done in target="font" rather
> than target="pattern". I was thinking possibly reasons that one wants
> to edit objects regardless of the matcher, may be to reflect some
> parameters in the initial pattern to the result. but as I said the
> above, that may be better doing it outside fontconfig.  So I totally
> lost the reason to allow editing all of objects in target="pattern".

To clarify, we're actually talking about two distinct questions:

(1) Whether fontconfig should restrict the properties that can be
     edited in patterns

   (1a) for builtin properties that are not used by the matcher

   (1b) for custom properties

(2) Whether fontconfig should propagate properties from the pattern
     to the font, in case they aren't already in the font.

I use (1b) extensively in my configuration to pass information between 
rules before the match. I'm surely not the only guy on the planet who 
does this. Now such properties don't necessarily need to be passed on to 
the result, but it makes testing the rules with fc-match easier, so I 
don't see the case for (2) either.

Restricting (2) also has the potential to make the implementation of 
FcFontRenderPrepare more complicated, because properties like
'pixelsize' will still need to be passed on. It also will make it 
impossible for the user to control things like the aforementioned 'rgba' 
from font descriptors, i. e. 'xterm -bg gray -fa mono:rgba=rgb' would be 
a thing of the past.

The only thing that wouldn't interfere with my current setup, or could 
at least be worked around by using font edits, is (1a), provided that 
nothing else changes, but as I said I don't see why I should be 
prevented from editing things in the pattern that applications can put 
there with FcPatternAdd. So to be sure you would have to examine all 
patterns passed into FcFontMatch as well, and return errors for the 
properties that aren't in _FcMatchers (which would then again break the 
above xterm example). This API would then change every time _FcMatchers 
changes.

Generally, every change we're talking about here would break 
compatibility with some existing configuration.

All of this for no apparent gain...

But well, if it's the consensus to implement these restrictions, then so 
be it. I've always regarded the current logic as pretty well 
thought-out, I hope this was not by accident!

Raimund

-- 
Worringer Str 31 Duesseldorf 40211 Germany +49-179-2981632 icq 16845346