Akira TAGOH wrote:
On Tue, Aug 14, 2012 at 9:38 AM, Raimund Steger <rs@xxxxxxxx> 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
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig
