Hi,
it was noticed in https://bugzilla.redhat.com/show_bug.cgi?id=705348 that the most straightforward way to force autohinting for a particular font:
<match target="font"> <test name="family" compare="eq"> <string>Your Font</string> </test> <edit name="autohint" mode="assign"> <bool>true</bool> </edit> </match>
MAY CAUSE PROBLEMS in Qt applications (more precisely, force autohinting also for other fonts which should use the bytecode interpreter), especially if your font is one of the fonts pulled in for locale coverage (e.g. the Lohit fonts).
Instead, the following snippet is safe to use:
<match target="font"> <test qual="first" name="family" compare="eq"> <string>Your Font</string> </test> <edit name="autohint" mode="assign"> <bool>true</bool> </edit> </match>
Note the added qual="first" attribute. Please ALWAYS USE THIS QUALIFIER when forcing autohinting for a specific font.
(I wasn't aware of this issue myself before this bug report came up. Thanks to Akira Tagoh for the qual="first" fix.)
Kevin Kofler
On 06/05/11 22:36, Kevin Kofler wrote:
Note the added qual="first" attribute. Please ALWAYS USE THIS QUALIFIER when forcing autohinting for a specific font.
No! Wait a second. Please don't do this. Lets follow up in the bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=705348
b
(I wasn't aware of this issue myself before this bug report came up. Thanks to Akira Tagoh for the qual="first" fix.)
Kevin Kofler
On Monday 06 June 2011, Behdad Esfahbod wrote:
No! Wait a second. Please don't do this. Lets follow up in the bug report:
Care to explain why? As far as I can tell, Pango only ever passes one font at a time to fontconfig, so qual="first" will not change anything for Pango; for Qt (or any other library which sends a whole list of fonts to fontconfig), on the other hand, qual="first" is the best thing we can do. It is not ideal, but we cannot really do better.
And if, in the future, Qt were changed to pass only one font at a time too, allowing for more finegrained settings, the qual="first" would still not hurt, because then it'd have no effect, as is the case for Pango now.
Kevin Kofler
On 06/06/11 10:51, Kevin Kofler wrote:
On Monday 06 June 2011, Behdad Esfahbod wrote:
No! Wait a second. Please don't do this. Lets follow up in the bug report:
Care to explain why? As far as I can tell, Pango only ever passes one font at a time to fontconfig, so qual="first" will not change anything for Pango; for Qt (or any other library which sends a whole list of fonts to fontconfig), on the other hand, qual="first" is the best thing we can do. It is not ideal, but we cannot really do better.
And if, in the future, Qt were changed to pass only one font at a time too, allowing for more finegrained settings, the qual="first" would still not hurt, because then it'd have no effect, as is the case for Pango now.
I'm writing a detailed report on the bug. It's true that it doesn't affect pango. However, Qt is completely broken and needs to be fixed. I'm afraid hacking configuration now will just push the real issue to the side again.
behdad
Kevin Kofler
On Monday 06 June 2011, Behdad Esfahbod wrote:
I'm writing a detailed report on the bug. It's true that it doesn't affect pango. However, Qt is completely broken and needs to be fixed. I'm afraid hacking configuration now will just push the real issue to the side again.
Look: * We have very real breakage to fix now. * It is very unlikely that Qt is going to be fixed the way you want it any time soon. (I think 4.8 is already frozen, and I also suspect that this issue will not have high priority for Nokia.) * If and when Qt will be fixed that way, the configuration workaround will become a no-op for Qt. So the workaround does not hinder a proper fix at all. * IMHO, qual="first" is also the theoretically most correct thing to do: If you have more than one font in your lookup list, the settings should be derived from the first one, not from all the fonts in the list. Now you will argue that it's a bug that there's more than one font in the list in the first place, but see above: This is a constraint we have to deal with for now. * Other, less common toolkits may have the same issue as Qt. Do you really think we can fix them all? (I don't.)
So please do not sabotage efforts to get a real-world bug fixed in a timely manner in the name of some theoretical ideal fix which will take months or years to develop.
"The perfect is the enemy of the good." (Voltaire)
Kevin Kofler
On 06/06/11 11:03, Kevin Kofler wrote:
So please do not sabotage efforts to get a real-world bug fixed in a timely manner in the name of some theoretical ideal fix which will take months or years to develop.
Kevin, apparently you do not quite understand how fontconfig is supposed to be used. That's fine. Qt is broken, been broken for years. I'm not talking about "theoretical ideal fix". It's plain wrong, a patch to fix it would be prolly 20 lines. Now if no one really cares about fixing it properly, why bother? Has the issue even been reported to Qt upstream?
Shrug b
On 6 June 2011 21:25, Behdad Esfahbod behdad@behdad.org wrote:
On 06/06/11 11:03, Kevin Kofler wrote:
So please do not sabotage efforts to get a real-world bug fixed in a
timely
manner in the name of some theoretical ideal fix which will take months
or
years to develop.
Kevin, apparently you do not quite understand how fontconfig is supposed to be used. That's fine. Qt is broken, been broken for years. I'm not talking about "theoretical ideal fix". It's plain wrong, a patch to fix it would be prolly 20 lines. Now if no one really cares about fixing it properly, why bother? Has the issue even been reported to Qt upstream?
I do agree with Behdad, problem must be fix from where it originates. .conf rules must be process same way whether it is pango or qt.
for getting some breathing time i am presently fixing it in fonts with tweak.
Thanks, Pravin S
Le Lun 6 juin 2011 17:03, Kevin Kofler a écrit :
- Other, less common toolkits may have the same issue as Qt. Do you really
think we can fix them all? (I don't.)
Kevin,
Please understand that the QT fontconfig code is a PITA that breaks on Fedora settings every release (and every time it's blamed on font packages despite the fact the same settings work fine in GTK apps). Please spend your energy in getting upstream to fix QT not complain at Behdad (who at least wrote a patch to try to fix things a little).
Nicolas Mailhot wrote:
Le Lun 6 juin 2011 17:03, Kevin Kofler a écrit :
- Other, less common toolkits may have the same issue as Qt. Do you
really think we can fix them all? (I don't.)
Please understand that the QT fontconfig code is a PITA that breaks on Fedora settings every release (and every time it's blamed on font packages despite the fact the same settings work fine in GTK apps). Please spend your energy in getting upstream to fix QT not complain at Behdad (who at least wrote a patch to try to fix things a little).
No one is arguing that a proper fix isn't the best *long-term* solution.
And, it turns out there is a short-term solution being suggested, but I have yet to see any critiques on it. Are there any?
It's just that my common-sense-o-meter started buzzing at the implication that y'all would prefer to keep stuff broken in the meantime...
-- Rex
Le lundi 13 juin 2011 à 09:38 -0500, Rex Dieter a écrit :
No one is arguing that a proper fix isn't the best *long-term* solution.
And, it turns out there is a short-term solution being suggested, but I have yet to see any critiques on it. Are there any?
The various short-term solutions I've seen here involved erasing valid hinting data from font files in multiples packages, to avoid setting an override in fontconfig files that QT mis-interpreted, to workaround the failure of freetype to handle partially hinted files in BCI, that was exposed when the new Fedora freetype packager arbitrarily enabled BCI with little to no discussion (or maybe there are more convolutions now, I prefer to forget them)
Methinks that's a lot of font-package-side short-term solutions to hide software-package bugs. Who is going to remember to revert all this mess in all those packages when the bugs are fixed? Who is going to track the bugs are fixed?
Maybe it's better to stop the workarounding now, and wait for stuff to settle a little before adding more short-term fixes to the mix? Or at least limit the experimenting to a couple packages, and think about generalizing it when we're sure it's actually working in all cases, and the blessed solution is actually documented in the wiki and fontpackages-devel, where people can look at it a month from now and understand why some font packages were changed mid 2011?
And next time someone decides to change the distro default font setting, maybe some *testing* before release would be appropriate?
-
Behdad Esfahbod -
Kevin Kofler -
Nicolas Mailhot -
pravin.d.s＠gmail.com -
Rex Dieter