On Wed, Aug 15, 2012 at 7:11 AM, Raimund Steger <rs@xxxxxxxx> wrote:
> But why would it be so important to recognize a difference here?
Because something added by rules in target="pattern" might be an error
and may be not what they expected. propagating including them is
actually the side-effects to reflect something in the initial pattern
to the result. it will causes a trouble, particularly if one expects
to apply something for the certain conditions. for example, the
following rule expects to enable the embedded bitmap when matching the
font A. which is actually wrong usage and always enable it as long as
the font A is included in the pattern but the result:
<match target="pattern">
<test name="family">
<string>A</string>
</test>
<edit name="embeddedbitmap">
<bool>true</bool>
</edit>
</match>
We have no way to detect the kind of this error so far and if one do
test only what they expect, they will miss an opportunity to see their
mistake.
> 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
(1b) is out of the scope here since I added the user-defined objects
in target="pattern". it can be referred among rules. hmm, all of the
built-in objects may possibly be referred too though. but then, if we
are about to fix the above side-effects, I'm not quite sure if it's
really useful.
> 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.
Okay, so do you have any example for objects not listing in the
target="pattern" and you can't do it in target="font" ?
> 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.
I see the needs for such situation. as I mentioned the above, this
proposal is basically to avoid an error in the rule but to prevent
something added to the pattern by the users or applications.
having said that we might miss the way to test something from the rule
then. that looks like a trade-off really. but instead, we may get the
full-control with the initial pattern. i.e. no need to write rules,
might possibly do everything from fc-match.
FWIW I tend to feel odd to give a FcPattern to FcConfigSubstitute()
with mixing the expectation and the options for rendering. isn't it
better giving a separate FcPattern or new structure for the rendering
options to FcFontRenderPrepare() and/or FcFontMatch and so on? so we
can simply stop propagating the pattern to the result and apply the
rendering options to the result at the end.
--
Akira TAGOH
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig
