Hi,
I just realized that modifying the object in the pattern on
target="pattern" also inherited to the pattern result of FcMatchFont.
for example, the following rule ends up to appear in the result of
FcMatchFont from FcFontMatch():
<match target="pattern">
<edit name="rgba"
mode="assign"><const>rgb</const></edit>
</match>
As fontconfig warns to edit the user-defined object for target="scan"
right now, I think it should warns for other cases so that that would
helps to write sane rules.
So I want to sort out what objects are allowed to edit and where the
target is it in. please let me know if something wrong and the
use-case why it needs. particularly for target="pattern". I''m
listing
as is so far. it''s what fontconfig is looking at the objects on
matching. and for target="scan", I put the same name to
target="pattern" because any objects not checking for
target="pattern"
isn''t needed to cache.
target="scan":
family
style
slant
weight
pixelsize
spacing
foundry
antialias
width
file
rasterizer
outline
charset
lang
fontversion
familylang
stylelang
fullnamelang
decorative
target="pattern":
family
style
slant
weight
pixelsize
spacing
foundry
antialias
width
file
rasterizer
outline
charset
lang
fontversion
familylang
stylelang
fullnamelang
decorative
user-defined objects
target="font":
antialias
hinting
hintstyle
verticallayout
autohint
globaladvance
rasterizer
outline
scalable
scale
dpi
rgba
minspace
embolden
embeddedbitmap
decorative
lcdfilter
charwidth
charheight
matrix
user-defined objects
Cheers,
--
Akira TAGOH
Akira TAGOH wrote:> [...] > So I want to sort out what objects are allowed to edit and where the > target is it in. please let me know if something wrong and the > use-case why it needs. particularly for target="pattern". I''m listingFor target="scan" and target="font", I agree that can make sense. However, for target="pattern", I think that all properties that can be specified by users/applications (which are basically _all_ properties), should also remain editable in the pattern through rules, even if they don''t take effect until after the match. For example, in environments where none of the 10-* config files are enabled by default, it is entirely possible that applications specify fonts like sans:rgba=rgb for some uses and sans:rgba=none for others. I think it would be irritating if patterns like these couldn''t fully be edited in the configuration. Now it''s true that such cases could still be sorted out after the match. It just seems a bit arbitrary to forbid such edits. Raimund -- Worringer Str 31 Duesseldorf 40211 Germany +49-179-2981632 icq 16845346
On Sat, Aug 11, 2012 at 8:07 PM, Raimund Steger <rs at mytum.de> wrote:> For example, in environments where none of the 10-* config files are enabled > by default, it is entirely possible that applications specify fonts like > > sans:rgba=rgb > > for some uses and > > sans:rgba=none > > for others.Is it expected that the pattern in the kind of the strong binding should be inherited to the result? or should the explicit patterns be inherited if it''s not the objects to be checked with the matcher?> > I think it would be irritating if patterns like these couldn''t fully be > edited in the configuration. > Now it''s true that such cases could still be sorted out after the match. It > just seems a bit arbitrary to forbid such edits. > > Raimund > > > > -- > Worringer Str 31 Duesseldorf 40211 Germany +49-179-2981632 icq 16845346-- Akira TAGOH
Akira TAGOH wrote:> [...] > Is it expected that the pattern in the kind of the strong binding > should be inherited to the result? or should the explicit patterns be > inherited if it''s not the objects to be checked with the matcher?It was my understanding (of FcFontRenderPrepare(3)) that exactly those properties are propagated from the pattern to the font that are _not_ already in the font, regardless of their binding or whether they are used in the match. For example, if I have Type 1 Helvetica installed, I can issue fc-match -v Helvetica:scalable=false all the way I like, it will _not_ be propagated and the resulting font will still have ''scalable'' set to "true", even though ''scalable'' isn''t used by the matcher. That''s because the property has the value "true" for the best result in the match which is the cache entry for Helvetica.pfa. However, I can assign any number of weak properties in my configuration, not only things like ''rgba'', but custom ones to group evaluation results or, from Solaris JDS default configuration, ''disable_pango_script'' and these _will_ be propagated. I wouldn''t want it any other way, actually... Raimund -- Worringer Str 31 Duesseldorf 40211 Germany +49-179-2981632 icq 16845346
On Tue, Aug 14, 2012 at 9:38 AM, Raimund Steger <rs at mytum.de> wrote:> all the way I like, it will _not_ be propagated and the resulting font will > still have ''scalable'' set to "true", even though ''scalable'' isn''t used by > the matcher. That''s because the property has the value "true" for the best > result in the match which is the cache entry for Helvetica.pfa.Yes, I like that too. they could add the sort of the boolean value to 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.> However, I can assign any number of weak properties in my configuration, not > only things like ''rgba'', but custom ones to group evaluation results or, > from Solaris JDS default configuration, ''disable_pango_script'' and these > _will_ be propagated. > > I wouldn''t want it any other way, actually...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". -- Akira TAGOH
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
On Wed, Aug 15, 2012 at 7:11 AM, Raimund Steger <rs at mytum.de> 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
Akira TAGOH wrote:> On Wed, Aug 15, 2012 at 7:11 AM, Raimund Steger <rs at mytum.de> 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
On Wed, Aug 15, 2012 at 10:40 PM, Raimund Steger <rs at mytum.de> wrote:> I see, yes this is a mistake that sometimes happens (which can often > be fixed with qual="first" as well), but even if embeddedbitmap wasBTW given that doing it in the user fonts.conf, if the pattern list is changed later, that won''t work as expected. this is highly likely that some rules are performed after 50-user.conf.> [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.Indeed. it''s just an idea yet. I think I could clarified in this discussion what we need to try in the future. so if there are any better solution to address it, we can go with it. -- Akira TAGOH
On 08/10/2012 05:42 AM, Akira TAGOH wrote:> Hi,Hi,> As fontconfig warns to edit the user-defined object for target="scan" > right now,Let me put this into perspective: the reason it warns right now is because those user-defined objects are NOT saved to the cache and lost, hence the warning. If you fix the cache, I''d say you should also remove the warning. As such, I don''t think you should take the warning so much as a design precedent here. For the rest of the proposal, I fully agree with everything that Raimund said. I''d rather not touch these things unless absolutely necessary. Cheers, behdad> I think it should warns for other cases so that that would > helps to write sane rules. > So I want to sort out what objects are allowed to edit and where the > target is it in. please let me know if something wrong and the > use-case why it needs. particularly for target="pattern". I''m listing > as is so far. it''s what fontconfig is looking at the objects on > matching. and for target="scan", I put the same name to > target="pattern" because any objects not checking for target="pattern" > isn''t needed to cache. > > target="scan": > family > style > slant > weight > pixelsize > spacing > foundry > antialias > width > file > rasterizer > outline > charset > lang > fontversion > familylang > stylelang > fullnamelang > decorative > > target="pattern": > family > style > slant > weight > pixelsize > spacing > foundry > antialias > width > file > rasterizer > outline > charset > lang > fontversion > familylang > stylelang > fullnamelang > decorative > user-defined objects > > target="font": > antialias > hinting > hintstyle > verticallayout > autohint > globaladvance > rasterizer > outline > scalable > scale > dpi > rgba > minspace > embolden > embeddedbitmap > decorative > lcdfilter > charwidth > charheight > matrix > user-defined objects > > Cheers,