Bug#401411: Same with Bitstream Vera
On Tue, 2006-12-05 at 20:53 +0100, Loïc Minier wrote: On Tue, Dec 05, 2006, Keith Packard wrote: I think I could fix upstream fontconfig to do a more careful check when fc-cache is run and finds font files newer than the cache for their directory. I don't do that at library initialization time for performance reasons, as font files are generally not upgraded in place. That would avoid the need to run dpkg-reconfigure fontconfig (which is certainly a bad plan). The alternative is to fix font packages to run fc-cache -f on their target directories. Perhaps you can hook a fontconfig cache update with defoma? So far, I've studiously avoided defoma; it's doing weird things with fonts (symlinks to /var/lib/defoma/fontconfig.d?). I'll take a look at it and see if that makes any sense. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#401411: Same with Bitstream Vera
On Tue, 2006-12-05 at 21:46 +0100, Loïc Minier wrote: On Tue, Dec 05, 2006, Josselin Mouette wrote: The fix is to have these packages register their fonts to defoma. This will automatically run fc-cache -f in the defoma directory. Either defoma is borken, or dh_installdefoma doesn't generate the appropriate snippet for what you describe. Perhaps defoma only re-computes the font cache file in the /var/lib/defoma/fontconfig.d directory instead of /usr/share/fonts/truetype/ttf-dejavu. That would cause the same problem. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#401411: Same with Bitstream Vera
Le mardi 05 décembre 2006 à 13:02 -0800, Keith Packard a écrit : On Tue, 2006-12-05 at 21:46 +0100, Loïc Minier wrote: On Tue, Dec 05, 2006, Josselin Mouette wrote: The fix is to have these packages register their fonts to defoma. This will automatically run fc-cache -f in the defoma directory. Either defoma is borken, or dh_installdefoma doesn't generate the appropriate snippet for what you describe. Perhaps defoma only re-computes the font cache file in the /var/lib/defoma/fontconfig.d directory instead of /usr/share/fonts/truetype/ttf-dejavu. That would cause the same problem. Yes, defoma only runs fc-cache in the defoma directory. It won't do anything more to system directories than building symbolic links to them. -- Josselin Mouette/\./\ Do you have any more insane proposals for me? signature.asc Description: Ceci est une partie de message numériquement signée
Bug#401411: Same with Bitstream Vera
On Mon, Dec 04, 2006, Josselin Mouette wrote: I think Loïc's analysis is wrong here (But certainly Cc:ing him would help getting his feedback.) as XUL isn't using the condensed version of the DejaVu (or Vera) fonts. For most pages, it is using the Nimbus Sans fonts. I don't see how this relates to my analysis. I upgraded fontconfig, and the fonts were ugly. I removed DejaVu Condensed, and the fonts were nice again, and the result of fc-match changed as well; certainly you can explain what part of the analysis is incorrect. Beside, I've configured the fonts of my web browser to be serif for serif and sans-serif for sans-serif, and this maps one to one with Dejavu Sans and Devavu Sans Serif, certainly not to Nimbus. -- Loïc Minier [EMAIL PROTECTED] I have no strong feelings one way or the other. -- Neutral President
Bug#401411: Same with Bitstream Vera
On Tue, 2006-12-05 at 15:29 +0100, Loïc Minier wrote: I don't see how this relates to my analysis. I upgraded fontconfig, and the fonts were ugly. I removed DejaVu Condensed, and the fonts were nice again, and the result of fc-match changed as well; certainly you can explain what part of the analysis is incorrect. Right, the current DejaVu font package has a broken version of condensed which does not correctly report the setwidth value in the OS/2 header of the file. I think this will cause the incorrect font selection error that we've seen in this case. Testing this should be fairly straightforward for anyone so inclined; the font can be fixed with fontforge. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#401411: Same with Bitstream Vera
On Tue, Dec 05, 2006, Keith Packard wrote: Right, the current DejaVu font package has a broken version of condensed which does not correctly report the setwidth value in the OS/2 header of the file. I think this will cause the incorrect font selection error that we've seen in this case. Indeed, and it's even fixed in ttf-dejavu 2.12-2 (incoming.debian.org). (However, one need to dpkg-reconfigure fontconfig for the fonts to be fixed.) I'm not closing the bug as it was reported with other fonts as well (at least Bitstream Vera). -- Loïc Minier [EMAIL PROTECTED] I have no strong feelings one way or the other. -- Neutral President
Bug#401411: Same with Bitstream Vera
On Tue, 2006-12-05 at 20:08 +0100, Loïc Minier wrote: On Tue, Dec 05, 2006, Keith Packard wrote: Right, the current DejaVu font package has a broken version of condensed which does not correctly report the setwidth value in the OS/2 header of the file. I think this will cause the incorrect font selection error that we've seen in this case. Indeed, and it's even fixed in ttf-dejavu 2.12-2 (incoming.debian.org). (However, one need to dpkg-reconfigure fontconfig for the fonts to be fixed.) I think I could fix upstream fontconfig to do a more careful check when fc-cache is run and finds font files newer than the cache for their directory. I don't do that at library initialization time for performance reasons, as font files are generally not upgraded in place. That would avoid the need to run dpkg-reconfigure fontconfig (which is certainly a bad plan). The alternative is to fix font packages to run fc-cache -f on their target directories. I'm not closing the bug as it was reported with other fonts as well (at least Bitstream Vera). I guess I don't understand what the issue with Vera was. Josselin, did you have a problem with this? -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#401411: Same with Bitstream Vera
On Tue, Dec 05, 2006, Keith Packard wrote: I think I could fix upstream fontconfig to do a more careful check when fc-cache is run and finds font files newer than the cache for their directory. I don't do that at library initialization time for performance reasons, as font files are generally not upgraded in place. That would avoid the need to run dpkg-reconfigure fontconfig (which is certainly a bad plan). The alternative is to fix font packages to run fc-cache -f on their target directories. Perhaps you can hook a fontconfig cache update with defoma? (I'm not cloning this as a separate bug, I suppose you'll do so if you want one.) -- Loïc Minier [EMAIL PROTECTED] I have no strong feelings one way or the other. -- Neutral President
Bug#401411: Same with Bitstream Vera
On Tue, Dec 05, 2006, Josselin Mouette wrote: The fix is to have these packages register their fonts to defoma. This will automatically run fc-cache -f in the defoma directory. Either defoma is borken, or dh_installdefoma doesn't generate the appropriate snippet for what you describe. ttf-dejavu.postinst has: # Automatically added by dh_installdefoma FILE='/etc/defoma/hints/ttf-dejavu.hints' if [ $1 = configure ]; then test -x /usr/bin/defoma-font /usr/bin/defoma-font reregister-all $FILE fi # End automatically added section Yet I had to dpkg-reconfigure fontconfig. -- Loïc Minier [EMAIL PROTECTED] I have no strong feelings one way or the other. -- Neutral President
Bug#401411: Same with Bitstream Vera
Le dimanche 03 décembre 2006 à 18:27 -0800, Keith Packard a écrit : On Mon, 2006-12-04 at 00:23 +0100, Josselin Mouette wrote: I see the same situation while my fonts are Bitstream Vera. I think Loïc's analysis is wrong here, as XUL isn't using the condensed version of the DejaVu (or Vera) fonts. For most pages, it is using the Nimbus Sans fonts. Which means there is a serious regression somewhere, as this bug had been fixed a long time ago. Hmm. I can't see how that would happen unless the upgrade smashed your configuration files somehow. Can you poke at this using fc-match and see what that does? I first thought of a configuration issue, and I can confirm that the configuration files are exactly the same. Reverting the library brings back Bitstream Vera in XUL applications. This doesn't seem to be a problem for e.g. GNOME applications, only for the weird things XUL is doing with fontconfig. I'm CC-ing glandium in case he has a clue. -- Josselin Mouette/\./\ Do you have any more insane proposals for me?
Bug#401411: Same with Bitstream Vera
On Mon, Dec 04, 2006 at 10:36:00AM +0100, Josselin Mouette [EMAIL PROTECTED] wrote: Le dimanche 03 décembre 2006 à 18:27 -0800, Keith Packard a écrit : On Mon, 2006-12-04 at 00:23 +0100, Josselin Mouette wrote: I see the same situation while my fonts are Bitstream Vera. I think Loïc's analysis is wrong here, as XUL isn't using the condensed version of the DejaVu (or Vera) fonts. For most pages, it is using the Nimbus Sans fonts. Which means there is a serious regression somewhere, as this bug had been fixed a long time ago. Hmm. I can't see how that would happen unless the upgrade smashed your configuration files somehow. Can you poke at this using fc-match and see what that does? I first thought of a configuration issue, and I can confirm that the configuration files are exactly the same. Reverting the library brings back Bitstream Vera in XUL applications. This doesn't seem to be a problem for e.g. GNOME applications, only for the weird things XUL is doing with fontconfig. I'm CC-ing glandium in case he has a clue. Well, I have the latest version of fontconfig, and didn't see any regression with xul applications or others... but I think I don't have the nimbus fonts installed... In what applications do you see that, with which backend (xft or pango or both) ? Mike
Bug#401411: Same with Bitstream Vera
Le lundi 04 décembre 2006 à 12:37 +0100, Mike Hommey a écrit : I first thought of a configuration issue, and I can confirm that the configuration files are exactly the same. Reverting the library brings back Bitstream Vera in XUL applications. This doesn't seem to be a problem for e.g. GNOME applications, only for the weird things XUL is doing with fontconfig. I'm CC-ing glandium in case he has a clue. Well, I have the latest version of fontconfig, and didn't see any regression with xul applications or others... but I think I don't have the nimbus fonts installed... In what applications do you see that, with which backend (xft or pango or both) ? I'm seeing this in epiphany, with the pango backend. I'll try tonight with the Xft backend. The worst thing is that it happens even for pages that ask for the sans-serif family, not only for the ones asking explicitly for Helvetica. -- Josselin Mouette/\./\ Do you have any more insane proposals for me?
Bug#401411: Same with Bitstream Vera
I see the same situation while my fonts are Bitstream Vera. I think Loïc's analysis is wrong here, as XUL isn't using the condensed version of the DejaVu (or Vera) fonts. For most pages, it is using the Nimbus Sans fonts. Which means there is a serious regression somewhere, as this bug had been fixed a long time ago. -- Josselin Mouette/\./\ Do you have any more insane proposals for me? signature.asc Description: Ceci est une partie de message numériquement signée
Bug#401411: Same with Bitstream Vera
On Mon, 2006-12-04 at 00:23 +0100, Josselin Mouette wrote: I see the same situation while my fonts are Bitstream Vera. I think Loïc's analysis is wrong here, as XUL isn't using the condensed version of the DejaVu (or Vera) fonts. For most pages, it is using the Nimbus Sans fonts. Which means there is a serious regression somewhere, as this bug had been fixed a long time ago. Hmm. I can't see how that would happen unless the upgrade smashed your configuration files somehow. Can you poke at this using fc-match and see what that does? -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
