Hi,
fontconfig will read the xml files according to the alphanumerical
ordering. one may expects that the earlier one would have a priority
than later one. actually this is true for "prepend",
"assign_replace"
and "append_last" too in some cases. but not for
"prepend_first",
"assign" and "append" due to its behavior. though
"prepend_first" may
be an exception here, because it''s a bit special case to use. also I
believe we are relying on this to apply the user configuration
effectively.
Anyway this may be one of reasons why it causes confusion and mess up
the config directory. so why does this happen? see:
<match>
<test
name="family"><string>blahblahblah</string></test>
<edit name="family" mode="append">
<string>A</string>
<string>B</string>
<string>C</string>
</edit>
</match>
This is a typical rule as known as what <accept> does. this ensure the
order of A/B/C fonts as substitute of blahblahblah there though,
similar rules reading later will overrides it. see:
Substitute match
pattern any family Equal(ignore blanks) "blahblahblah"
edit
Edit family Append "A" Comma "B" Comma
"C";
Append list before "blahblahblah"(s) [insert here]
Append list after "blahblahblah"(s) "A"(s) "B"(s)
"C"(s)
...
Substitute match
pattern any family Equal(ignore blanks) "blahblahblah"
edit
Edit family Append "D";
Append list before "blahblahblah"(s) [insert here] "A"(s)
"B"(s) "C"(s)
Append list after "blahblahblah"(s) "D"(s) "A"(s)
"B"(s) "C"(s)
Which isn''t expected behavior according to the above prioritization.
FWIW "append_last" doesn''t work in some cases, particularly
when other
rules takes effect to the list prior to the above last one.
Well, I''m wondering if we may need to change the data structure to
group according to the edit mode or so for long term solution. for
short term solution, the above case can be improved with the sort of
"hook" as the following. e.g. 30-metrics-alias.conf to:
30-0-metrics-alias.conf:
<match>
<test
name="family"><string>Arial</string></test>
<edit name="family" mode="append"
binding="same">
<string>metrics-alias-Arial</string>
</edit>
</match>
30-1-metrics-alias-arial.conf:
<match>
<test
name="family"><string>metrics-alias-Arial</string></test>
<edit name="family" mode="prepend"
binding="same">
<string>Liberation Sans</string>
</edit>
</match>
30-2-metrics-alias-arial.conf:
<match>
<test
name="family"><string>metrics-alias-Arial</string></test>
<edit name="family" mode="prepend"
binding="same">
<string>Albany</string>
</edit>
</match>
30-999-metrics-alias-arial.conf:
<!-- better cleanup perhaps? though it prevents to put similar rules
later and this enforces to have "30-n" numeric prefix then -->
<match>
<test
name="family"><string>metrics-alias-Arial</string></test>
<edit name="family" mode="delete" />
</match>
After this, no need to put rules prior to 30-metrics-alias.conf any
more. and it would looks clearer what kind of rules is in the config
directory. though there are still no way to do "assign"ing with the
same prioritization.
How does it look like?
Any feedback, comments or counterparts are welcome.
Regards,
--
Akira TAGOH
My first take is, if we''re ever going to change this considerably, we should go back and rethink the problem, possibly replace both the language and the API.... Ie. fontconfig2. b On 06/12/2012 10:56 PM, Akira TAGOH wrote:> Hi, > > fontconfig will read the xml files according to the alphanumerical > ordering. one may expects that the earlier one would have a priority > than later one. actually this is true for "prepend", "assign_replace" > and "append_last" too in some cases. but not for "prepend_first", > "assign" and "append" due to its behavior. though "prepend_first" may > be an exception here, because it''s a bit special case to use. also I > believe we are relying on this to apply the user configuration > effectively. > > Anyway this may be one of reasons why it causes confusion and mess up > the config directory. so why does this happen? see: > > <match> > <test name="family"><string>blahblahblah</string></test> > <edit name="family" mode="append"> > <string>A</string> > <string>B</string> > <string>C</string> > </edit> > </match> > > This is a typical rule as known as what <accept> does. this ensure the > order of A/B/C fonts as substitute of blahblahblah there though, > similar rules reading later will overrides it. see: > > Substitute match > pattern any family Equal(ignore blanks) "blahblahblah" > edit > Edit family Append "A" Comma "B" Comma "C"; > > Append list before "blahblahblah"(s) [insert here] > Append list after "blahblahblah"(s) "A"(s) "B"(s) "C"(s) > ... > Substitute match > pattern any family Equal(ignore blanks) "blahblahblah" > edit > Edit family Append "D"; > > Append list before "blahblahblah"(s) [insert here] "A"(s) "B"(s) "C"(s) > Append list after "blahblahblah"(s) "D"(s) "A"(s) "B"(s) "C"(s) > > Which isn''t expected behavior according to the above prioritization. > FWIW "append_last" doesn''t work in some cases, particularly when other > rules takes effect to the list prior to the above last one. > > Well, I''m wondering if we may need to change the data structure to > group according to the edit mode or so for long term solution. for > short term solution, the above case can be improved with the sort of > "hook" as the following. e.g. 30-metrics-alias.conf to: > > 30-0-metrics-alias.conf: > <match> > <test name="family"><string>Arial</string></test> > <edit name="family" mode="append" binding="same"> > <string>metrics-alias-Arial</string> > </edit> > </match> > > 30-1-metrics-alias-arial.conf: > <match> > <test name="family"><string>metrics-alias-Arial</string></test> > <edit name="family" mode="prepend" binding="same"> > <string>Liberation Sans</string> > </edit> > </match> > > 30-2-metrics-alias-arial.conf: > <match> > <test name="family"><string>metrics-alias-Arial</string></test> > <edit name="family" mode="prepend" binding="same"> > <string>Albany</string> > </edit> > </match> > > 30-999-metrics-alias-arial.conf: > <!-- better cleanup perhaps? though it prevents to put similar rules > later and this enforces to have "30-n" numeric prefix then --> > <match> > <test name="family"><string>metrics-alias-Arial</string></test> > <edit name="family" mode="delete" /> > </match> > > After this, no need to put rules prior to 30-metrics-alias.conf any > more. and it would looks clearer what kind of rules is in the config > directory. though there are still no way to do "assign"ing with the > same prioritization. > > How does it look like? > Any feedback, comments or counterparts are welcome. > > Regards,
Hi, Behdad Esfahbod wrote:> My first take is, if we''re ever going to change this considerably, we should > go back and rethink the problem, possibly replace both the language and the > API.... Ie. fontconfig2. > > b > > On 06/12/2012 10:56 PM, Akira TAGOH wrote: >> Hi, >> >> fontconfig will read the xml files according to the alphanumerical >> ordering. one may expects that the earlier one would have a priority >> than later one. actually this is true for "prepend", "assign_replace" >> and "append_last" too in some cases. but not for "prepend_first", >> [...]Coupling things like evaluation order of the rules, and where those rules are allowed to apply their edits (so that early rules can only prepend and later rules can only append) would seem like an awkward thing to do, I mean these are unrelated things after all.>> Well, I''m wondering if we may need to change the data structure to >> group according to the edit mode or so for long term solution. for >> short term solution, the above case can be improved with the sort of >> "hook" as the following. e.g. 30-metrics-alias.conf to: >> >> 30-0-metrics-alias.conf: >> <match> >> <test name="family"><string>Arial</string></test> >> <edit name="family" mode="append" binding="same"> >> <string>metrics-alias-Arial</string> >> </edit> >> </match> >> >> 30-1-metrics-alias-arial.conf: >> <match> >> <test name="family"><string>metrics-alias-Arial</string></test> >> <edit name="family" mode="prepend" binding="same"> >> <string>Liberation Sans</string> >> </edit> >> </match> >> [...]Wouldn''t this be exactly what a number of people on this list have already been suggesting, i. e. using additional generic family names (in this example ''metrics-alias-Arial'') for Helvetica-Lookalikes, Times-Lookalikes, Mincho-Lookalikes etc. so that candidates can substitute each other and fallbacks stay at the end of the group? And what''s already employed by some of the other configuration files? Other suggestions for this particular topic I''ve heard: (1) drop all such rules and rely on distributions or ISVs or font metadata; (2) introduce new syntax to specify family equivalence. I wouldn''t object any number of additional generic or ''marker'' families being introduced to keep fallbacks in their place, and for me they don''t even need to be deleted in the end, which would have the advantage that third parties could place their fonts around the generic names they deem the most fitting candidates as they drop their snippets into /etc/fonts/conf.d/. A possible over-engineered solution for family substitutes would be to promote fontconfig properties from list-valued to ordered-tree-valued, e. g. having family: sans--HelveticaClass--Helvetica | `---Arial +---LucidaClass-----Lucida Sans Unicode | `-------Lucida Grande `---PGothic---------HG-PGothicB-Sun `------------MS PGothic where nodes in the tree could be moved as unit, i. e. all the Sanses can stay together if an ''edit'' operates on that level, and edits can assign new parents and childs as additional modes. But I think that would mean, where we''ve avoided doctoring around imaginary problems in the past, here we''d be happily inviting it, particularly (1) because generic families achieve the same just fine, (2) when I thought the general tone on this list was in favor of not introducing new classification logic on fontconfig''s behalf, and its default rules were about to be stripped down... Apart from that I do wonder what a fontconfig2 could do better, other than fragment the landscape. The current one-pass forward-chaining rule engine design is simple enough and well-defined (and used everywhere else from procmail to iptables to Apache configuration etc.), and even if the API should someday be changed from A to B or a new way to prioritize fonts is introduced or whatever, there *should* always be the possibility for someone (who is not the superuser) to step in between any two rules and apply modifications right there. Raimund
On 06/13/2012 08:25 PM, Raimund Steger wrote:> A possible over-engineered solution for family substitutes would be to promote > fontconfig properties from list-valued to ordered-tree-valued, e. g. having > > family: sans--HelveticaClass--Helvetica > | `---Arial > +---LucidaClass-----Lucida Sans Unicode > | `-------Lucida Grande > `---PGothic---------HG-PGothicB-Sun > `------------MS PGothic > > where nodes in the tree could be moved as unit, i. e. all the Sanses can stay > together if an ''edit'' operates on that level, and edits can assign new parents > and childs as additional modes.I actually kinda like this. If we can find an expressive language that does not rely on rule orders, I think that is an improvement. behdad
On Thu, Jun 14, 2012 at 9:25 AM, Raimund Steger <rs at mytum.de> wrote:> Coupling things like evaluation order of the rules, and where those rules > are allowed to apply their edits (so that early rules can only prepend and > later rules can only append) would seem like an awkward thing to do, I mean > these are unrelated things after all.Right. so ideally the rules before 50-user.conf would be minimal and usually later rules after that wouldn''t be affected to the user configuration. but it looks like not at this moment.> Wouldn''t this be exactly what a number of people on this list have already > been suggesting, i. e. using additional generic family names (in this > example ''metrics-alias-Arial'') for Helvetica-Lookalikes, Times-Lookalikes, > Mincho-Lookalikes etc. so that candidates can substitute each other and > fallbacks stay at the end of the group? And what''s already employed by some > of the other configuration files?Maybe. I have no idea who takes this way though.> Other suggestions for this particular topic I''ve heard: (1) drop all such > rules and rely on distributions or ISVs or font metadata; (2) introduce new > syntax to specify family equivalence.I did suggest the former one here before..., but anyway.> A possible over-engineered solution for family substitutes would be to > promote fontconfig properties from list-valued to ordered-tree-valued, e. g. > having > > ?family: sans--HelveticaClass--Helvetica > ? ? ? ? ? ?| ? ? ? ? ? ? ? `---Arial > ? ? ? ? ? ?+---LucidaClass-----Lucida Sans Unicode > ? ? ? ? ? ?| ? ? ? ? ? `-------Lucida Grande > ? ? ? ? ? ?`---PGothic---------HG-PGothicB-Sun > ? ? ? ? ? ? ? ? ? `------------MS PGothic > > where nodes in the tree could be moved as unit, i. e. all the Sanses can > stay together if an ''edit'' operates on that level, and edits can assign new > parents and childs as additional modes.Yes, I like this and actually thinking of the similar thing.> But I think that would mean, where we''ve avoided doctoring around imaginary > problems in the past, here we''d be happily inviting it, particularly (1) > because generic families achieve the same just fine, (2) when I thought the > general tone on this list was in favor of not introducing new classification > logic on fontconfig''s behalf, and its default rules were about to be > stripped down...Yeah... I felt same thing when I proposed in the past. so as Behdad suggested, starting to work on the sort of fontconfig2 sounds like a good idea.> Apart from that I do wonder what a fontconfig2 could do better, other than > fragment the landscape. The current one-pass forward-chaining rule engine > design is simple enough and well-defined (and used everywhere else from > procmail to iptables to Apache configuration etc.), and even if the API > should someday be changed from A to B or a new way to prioritize fonts is > introduced or whatever, there *should* always be the possibility for someone > (who is not the superuser) to step in between any two rules and apply > modifications right there.True. having said that it''s the fact that it also introduces confusion. I suppose this is because it''s not well-defined for the case where it process the complicated rules. it would be one of issue we can try to improve in the future. For having any possibilities to override by users, we may need to have well-managed hooks or prioritized config for each purposes, rather than doing a lot in one file.> > Raimund-- Akira TAGOH
Hi, just wrote the similar process in scheme until FcConfigSubstitute() in fc-match. that may be easier/helpful to modify/update the pattern building according to the rules. just FYI https://gist.github.com/2986471 -- Akira TAGOH