Akira TAGOH wrote:
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>
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
forbidden here, the same happens for naive approaches to control other
properties like 'antialias' or 'file' by testing 'family', and these
_are_ used in the matcher. So maybe a tool like 'fc-lint' could help
such users better by simulating a few substitutions with their config
and checking if these edits apply to too many disparate patterns. But OK
that would be a lot more effort so maybe your approach is better :-)
Okay, so do you have any example for objects not listing in the
target="pattern" and you can't do it in target="font" ?
For the builtin properties that aren't used in the matcher you're right,
I can use them in target="font". (What I don't like too much is that I'd
have to rewrite a lot of the config of my Solaris boxes, but well, we
all have to make some sacrifices..)
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.
Maybe. Well I think introducing new, specialized data types for the
various stages of the selection process will not make the whole thing
easier to understand. OK a separate user-provided FcPattern passed into
FcFontMatch which is then used as the source pattern in
FcFontRenderPrepare might sound useful, and it could even be introduced
without breaking existing API.
[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.
Raimund
--
Worringer Str 31 Duesseldorf 40211 Germany +49-179-2981632 icq 16845346
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig
