9:36 p.m.
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
9:37 a.m.
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
9:51 a.m.
On Monday 06 June 2011, Behdad Esfahbod wrote:
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
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
9:54 a.m.
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:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=705348
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
10:03 a.m.
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
10:55 a.m.
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
2:08 a.m.
On 6 June 2011 21:25, Behdad Esfahbod <behdad(a)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
2:30 a.m.
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
9:38 a.m.
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
3:21 p.m.
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?
--
Nicolas Mailhot
4694
days inactive
4702
days old
9 comments
5 participants
participants (5)
-
Behdad Esfahbod -
Kevin Kofler -
Nicolas Mailhot -
pravin.d.s＠gmail.com -
Rex Dieter