=2D----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=20 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 w= as=20 actually tracking my problems through the kde and the qt library and that=20 quite sensibly uses "Style Hints" and converts these to the generic names. = It=20 expects these generic names to have less weight than the application=20 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=20 notice anything. For a weak binding alias family name my proposal was that= =20 the prefered family name would still be prepended as weak. This is the sam= e=20 as it works at the moment. If there is strong binding alias family name my proposal is that the prefer= =20 would prepend as strong. At the moment it prepends as weak, and so the=20 matching mechanism effectively ignores this prepending. This was the probl= em=20 I was having. The obvious question is why would someone use the alias prefer combination = and=20 expect it to perform as it currently does for a strongly bound alias family= =20 and therefore submit lots of bug reports. I am asking this question with= =20 the naievity of someone who is newly looking at the issue so forgive me if = I=20 have totally misunderstood and there would be many users out there for whom= a=20 change like this would cause problems. =20 =2D --=20 Alan Chandler alan@xxxxxxxxxxxxxxxxxxxxx =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+XSyluFHxcV2FFoIRApNpAKCjZWPlLlmAKd7v+eDtuRHr+pcWVwCfSp10 IwiqyRt4BGYlUpa3anr23Ok=3D =3DOa7u =2D----END PGP SIGNATURE-----
