|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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 ratherartificial 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