-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 26 Feb 2003 12:15 am, Keith Packard wrote:> Around 20 o''clock on Feb 25, Alan Chandler wrote: > > Is the functionality what would be expected. Would it not be better for > > the at least the <alias> functions of <prefer> bind at the same strength > > as the alias it is prepended to, otherwise it just doesn''t do its job > > The strong/weak binding was added to resolve issues with language vs > family matching. Strongly bound family names are more important in > matching than language which is more important that weakly bound family > names. Before this change, language was actually *more* important than > family which prevented applications from being able to match family names > which didn''t support the document language, even if explicitly selected by > the user.The effect I am seeing is related actually totally unrelated to language. The matching "difference" score for these are 0> > The <prefer> binding is generally used when resolving the generic family > names (sans-serif, serif, monospace) and hence the names added should be > "weak" so that they don''t end up overriding the "real" names provided by > applications.Yes - I full understand the use of weak binding for the generic names - I was actually tracking my problems through the kde and the qt library and that quite sensibly uses "Style Hints" and converts these to the generic names. It expects these generic names to have less weight than the application specified> > I''m afraid the strong/weak binding lets the matching mechanism "show > through" the configuration language more than I''d like, but any > significant change in the existing mechanism would make for some > interesting bug reports from existing users. >This sounds a real shame - but are you sure existing users would actually notice anything. For a weak binding alias family name my proposal was that the prefered family name would still be prepended as weak. This is the same as it works at the moment. If there is strong binding alias family name my proposal is that the prefer would prepend as strong. At the moment it prepends as weak, and so the matching mechanism effectively ignores this prepending. This was the problem I was having. The obvious question is why would someone use the alias prefer combination and expect it to perform as it currently does for a strongly bound alias family and therefore submit lots of bug reports. I am asking this question with the naievity of someone who is newly looking at the issue so forgive me if I have totally misunderstood and there would be many users out there for whom a change like this would cause problems. - -- Alan Chandler alan@chandlerfamily.org.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+XSyluFHxcV2FFoIRApNpAKCjZWPlLlmAKd7v+eDtuRHr+pcWVwCfSp10 IwiqyRt4BGYlUpa3anr23Ok=Oa7u -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 26 Feb 2003 9:48 pm, Keith Packard wrote:> The generic names are often provided by the application and end up (by > default) with strong binding. Perhaps the problem here is an application > using the "generic" name ''fixed'' which in fact matches actual fonts. The > proper generic name is ''monospace'', which won''t match any fonts. >...> I guess I''m still confused over what the actual problem is here.Now you''ve explained it in that way - I see the problem can be seen from a different direction. KDEs konsole has a mode in which it wants to use a "default" font as the font that is used. It actually translates that as a "fixed" family request through qt and then fontconfig (strongly bound) and "monospace (weakly bound) (using QFont::Typewriter style hint). Because on Debian there is a strange font in the xfonts-base package (see my post earlier about the "Additional Style" field in an XLFD) which has family name "fixed" it is found by the fontconfig matching mechanism in preference to any other. I can''t remove that xfonts-base package because then the xserver complains it can''t find the "fixed" font and won''t start. A problem with no obvious way out - except by trying to get "fixed" overwridden when fontconfig does its matching. I can get round the problem using the match pattern stuff in local.conf but I am also interested in the "correct" way of solving this issue. - -- Alan Chandler alan@chandlerfamily.org.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+XUSXuFHxcV2FFoIRAgukAJ0UaTX1wOpnw2q4rFa7BGf1i3669wCePHB0 phTnqZ0H4y/br7Tqesfaqtc=BBd0 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 27 Feb 2003 12:05 am, Keith Packard wrote:> The right way is to get KDE to stop using a specific family name when it > wants a generic monospace font. I''m afraid this may well be my fault when > I was originally hacking Qt for Xft support. I used ''fixed'' as the > generic name before I figured out how font naming in CSS2 works and > switched to ''monospace''.I am not an expert, but I don''t think Qt has a way of not specifying a family. If you try to create a QFont without a name it uses QApplication::font which is set to "Helvetica" by default.> > > A problem with no obvious way out - except by trying to get "fixed" > > overwridden when fontconfig does its matching. > > You should be able to delete the ''fixed'' entry with: > > <match> > <test name="family"> > <string>fixed</string> > </test> > <edit name="family" mode="assign"> > </edit> > </match> >I''ll experiment - my local.conf has exactly the above but with the string "console" in the edit.> You might want additional tests to avoid eliminating ''fixed'' from all > applications (or maybe not -- there aren''t any decent looking fonts in the > fixed family).Hehe Thanks for your help. - -- Alan Chandler alan@chandlerfamily.org.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Xb2tuFHxcV2FFoIRAkHlAJ9fgkv+anXmEU9EYPrkqqSNdRHesgCeIe99 tcdyzIT9FbgKPhVh7Li7P4Y=NUbI -----END PGP SIGNATURE-----
Around 7 o''clock on Feb 27, Alan Chandler wrote:> I am not an expert, but I don''t think Qt has a way of not specifying a > family. If you try to create a QFont without a name it uses > QApplication::font which is set to "Helvetica" by default.Then just use the generic family name ''monospace'' instead of ''fixed'' if you can. ''monospace'', ''monospace'' matches the same fonts as ''monospace''... -keith
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 24 Feb 2003 11:11 pm, Keith Packard wrote:> Around 23 o''clock on Feb 24, Alan Chandler wrote: > > Is it possible to bind console strongly? > > Yes. Take a look in the fonts.dtd file and you''ll see that you can do: > > <edit name="family" binding="strong"> > <string>Console</console> > </edit> > > in a match/edit rule. You can convert your alias expression to a match/ > edit rule, instructions for that are also in the fonts.dtd file. >This is all very well - it answers my immediate problem, BUT Is the functionality what would be expected. Would it not be better for the at least the <alias> functions of <prefer> bind at the same strength as the alias it is prepended to, otherwise it just doesn''t do its job (my initial thought is that <accept> and <default> should as well, but I don''t fully comprehend the importance of language so I am not so sure). - -- Alan Chandler alan@chandlerfamily.org.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+W9OYuFHxcV2FFoIRAgX9AJ9pTjSFAZNqWKySRPQbcErelcVc+ACgi5yk 9nj+mij1eJostP1UEp0U5b8=Qdfa -----END PGP SIGNATURE-----
Around 23 o''clock on Feb 24, Alan Chandler wrote:> Is it possible to bind console strongly?Yes. Take a look in the fonts.dtd file and you''ll see that you can do: <edit name="family" binding="strong"> <string>Console</console> </edit> in a match/edit rule. You can convert your alias expression to a match/ edit rule, instructions for that are also in the fonts.dtd file. -keith
Around 20 o''clock on Feb 25, Alan Chandler wrote:> Is the functionality what would be expected. Would it not be better for the > at least the <alias> functions of <prefer> bind at the same strength as the > alias it is prepended to, otherwise it just doesn''t do its jobThe strong/weak binding was added to resolve issues with language vs family matching. Strongly bound family names are more important in matching than language which is more important that weakly bound family names. Before this change, language was actually *more* important than family which prevented applications from being able to match family names which didn''t support the document language, even if explicitly selected by the user. The <prefer> binding is generally used when resolving the generic family names (sans-serif, serif, monospace) and hence the names added should be "weak" so that they don''t end up overriding the "real" names provided by applications. I''m afraid the strong/weak binding lets the matching mechanism "show through" the configuration language more than I''d like, but any significant change in the existing mechanism would make for some interesting bug reports from existing users. -keith
Around 21 o''clock on Feb 26, Alan Chandler wrote:> Yes - I full understand the use of weak binding for the generic namesThe generic names are often provided by the application and end up (by default) with strong binding. Perhaps the problem here is an application using the "generic" name ''fixed'' which in fact matches actual fonts. The proper generic name is ''monospace'', which won''t match any fonts. It''s the substitutions in the config file which are weak by default. The intent is to ensure that: Times(s),Serif(s) -> Times(s),Times New Roman(w),Serif(s) Language is relevant here. My copy of Times doesn''t have cyrillic letters, so if an application used this pattern for a russian document, if the Times New Roman was bound strong, it would match better than Times did. However, when an application explicitly specifies a family name, with a strong binding, that overrides the language so that the application opens the named font instead of one which supports the language.> If there is strong binding alias family name my proposal is that the prefer > would prepend as strong. At the moment it prepends as weak, and so the > matching mechanism effectively ignores this prepending. This was the problem > I was having.The generic names aren''t supposed to matter as there aren''t supposed to be fonts with those names present in the system. Strong aliases should serve only to override real fonts with others, and that must not be part of the default configuration as that makes it impossible for applications to ever open the overridden fonts. I guess I''m still confused over what the actual problem is here. -keith
Around 22 o''clock on Feb 26, Alan Chandler wrote:> KDEs konsole has a mode in which it wants to use a > "default" font as the font that is used. It actually translates that as a > "fixed" family request through qt and then fontconfig (strongly bound) and > "monospace (weakly bound) (using QFont::Typewriter style hint).If it wants the default monospace font, it shouldn''t place the ''fixed'' family name in the request. ''monospace'' is always mapped to a monospaced font; ''fixed'' is a specific family name used by several legacy bitmap fonts.> I can get round the problem using the match pattern stuff in local.conf but > I am also interested in the "correct" way of solving this issue.The right way is to get KDE to stop using a specific family name when it wants a generic monospace font. I''m afraid this may well be my fault when I was originally hacking Qt for Xft support. I used ''fixed'' as the generic name before I figured out how font naming in CSS2 works and switched to ''monospace''.> A problem with no obvious way out - except by trying to get "fixed" > overwridden when fontconfig does its matching.You should be able to delete the ''fixed'' entry with: <match> <test name="family"> <string>fixed</string> </test> <edit name="family" mode="assign"> </edit> </match> You might want additional tests to avoid eliminating ''fixed'' from all applications (or maybe not -- there aren''t any decent looking fonts in the fixed family). -keith
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It appears that if I have a sequence such as
<alias>
<family>fixed</family>
<prefer>
<family>Console</family>
</prefer>
</alias>
in my /etc/fonts/local.conf file
Then such a sequence still matches a font with the "fixed" family name
in
preference to the "console" family, because in the pattern the value
"fixed"
is a stong binding and the console, although prepended to the pattern list is
a weak binding. When the matching occurs it gives preference to the stronger
binding.
Is it possible to bind console strongly?
- --
Alan Chandler
alan@chandlerfamily.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+WqWjuFHxcV2FFoIRAtY9AKCcxrBg5Q+l6KmG+sriQJ/8OFtkvACgtDP2
9DkX+1kcernXoaRk+CKzWG4=38jR
-----END PGP SIGNATURE-----