Hi list, I''ve got this bug report against pango [1]. In short, the problem is that fontconfig prefers bitmap fonts of the right family name but arbitrarily far away font size over fonts with the right font size (perhaps non-bitmap) but wrong family name. Sounds useful at first, except that if you happen to ask for "Times 96" and get a bitmap "Times" 12px, that doesn''t really help. Maybe a bitmap font should only be considered usable for sizes from 50% to 200% of its pixelsize? behdad [1] http://bugzilla.gnome.org/show_bug.cgi?id=570182
Behdad Esfahbod wrote:> I''ve got this bug report against pango [1]. In short, the problem is that > fontconfig prefers bitmap fonts of the right family name but arbitrarily far > away font size over fonts with the right font size (perhaps non-bitmap) but > wrong family name. Sounds useful at first, except that if you happen to ask > for "Times 96" and get a bitmap "Times" 12px, that doesn''t really help.Yes, this is a very real problem for things generated in a classic Mac environment where the "Times" font was a scalable font, and, of course, the Helvetica font, which is a very common Type1/TrueType font and has a bitmap font by default in X. Why scale it at all? If the user asks for 18px, we don''t want to stretch a 12px bitmap font to 18, and we wouldn''t want to show it at 12 either. I think the bitmap font matching should be an exact thing only. That''s why bitmap fonts ship with a variety of pixel sizes to start with. If they can''t satisfy the rendering, don''t use it. Actually, isn''t that exactly how bitmap information embedded into True/OpenType is handled? --Pat
Pat Suwalski wrote:> Behdad Esfahbod wrote: >> I''ve got this bug report against pango [1]. In short, the problem is >> that >> fontconfig prefers bitmap fonts of the right family name but >> arbitrarily far >> away font size over fonts with the right font size (perhaps >> non-bitmap) but >> wrong family name. Sounds useful at first, except that if you happen >> to ask >> for "Times 96" and get a bitmap "Times" 12px, that doesn''t really help. > > Yes, this is a very real problem for things generated in a classic Mac > environment where the "Times" font was a scalable font, and, of course, > the Helvetica font, which is a very common Type1/TrueType font and has a > bitmap font by default in X. > > Why scale it at all? If the user asks for 18px, we don''t want to stretch > a 12px bitmap font to 18, and we wouldn''t want to show it at 12 either. > I think the bitmap font matching should be an exact thing only. That''s > why bitmap fonts ship with a variety of pixel sizes to start with. If > they can''t satisfy the rendering, don''t use it. > > Actually, isn''t that exactly how bitmap information embedded into > True/OpenType is handled?Oll Korrect. I agree that rounding to integer and matching is what I prefer. My main issue with going ahead and doing this is that then when you choose a bitmap font in a font dialog you see fallback fonts. Unless the dialog correctly populates the size column from the actual sizes of the font. At least the GTK+ font dialog doesn''t do that currently. Pango has API for this though, so it''s easy fix on my side. behdad> --Pat >
Behdad Esfahbod wrote:> Oll Korrect. I agree that rounding to integer and matching is what I prefer. > My main issue with going ahead and doing this is that then when you choose a > bitmap font in a font dialog you see fallback fonts. Unless the dialog > correctly populates the size column from the actual sizes of the font. At > least the GTK+ font dialog doesn''t do that currently. Pango has API for this > though, so it''s easy fix on my side.It would be great if the GTK font chooser did do that. I can remember even back in the days of Windows 3.x Microsoft did that part correctly. A little off-topic, but it would be great if the GTK font dialog only listed real fonts in real sizes. I''m sure that when I''m in "user mode" I''m not the only one who finds it confusing that something three or four fonts look exactly the same (and they are, it''s how fontconfig maps them to multiple aliases). This is great for the computer coming up with substitutes, but it''s bad for users. --Pat
Pat Suwalski wrote:> A little off-topic, but it would be great if the GTK font dialog only > listed real fonts in real sizes. I''m sure that when I''m in "user mode" > I''m not the only one who finds it confusing that something three or four > fonts look exactly the same (and they are, it''s how fontconfig maps them > to multiple aliases). This is great for the computer coming up with > substitutes, but it''s bad for users.We should fix that by choosing a better sample string. I''ve added all the needed info in Pango, and drafted a spec about how to choose the sample string. Someone need to go ahead and implement that (hint hint). In the mean time, turning fallback off in the font dialog certainly helps. behdad
Behdad Esfahbod wrote:> We should fix that by choosing a better sample string. I''ve added all the > needed info in Pango, and drafted a spec about how to choose the sample > string. Someone need to go ahead and implement that (hint hint). In the mean > time, turning fallback off in the font dialog certainly helps.How does one go about turning off fallback? A define or a user option? The only reason I can think of keeping it is that (for example) the default GNOME settings should be that the fixed-width font is "Monospace" and if a user goes to change that, it should be there as a default selection. I take it that by sample string improvements, you mean that if the user chooses "Sans Serif" they get a sample string that says "Bitstream Vera Sans" or something along those lines? --Pat
Pat Suwalski wrote:> Behdad Esfahbod wrote: >> We should fix that by choosing a better sample string. I''ve added all >> the >> needed info in Pango, and drafted a spec about how to choose the sample >> string. Someone need to go ahead and implement that (hint hint). In >> the mean >> time, turning fallback off in the font dialog certainly helps. > > How does one go about turning off fallback? A define or a user option?Hardcoded in the code.> The only reason I can think of keeping it is that (for example) the > default GNOME settings should be that the fixed-width font is > "Monospace" and if a user goes to change that, it should be there as a > default selection.Disabling fallbacks in pango means: "only use the first font returned". So it works as expected for fake aliases too.> I take it that by sample string improvements, you mean that if the user > chooses "Sans Serif" they get a sample string that says "Bitstream Vera > Sans" or something along those lines?No. What I mean is that if you choose a font that has Arabic coverage but no Latin, an Arabic sample string is shown. behdad> --Pat
Le mardi 03 f?vrier 2009 ? 15:42 -0500, Behdad Esfahbod a ?crit :> Pat Suwalski wrote:> > Actually, isn''t that exactly how bitmap information embedded into > > True/OpenType is handled? > > Oll Korrect. I agree that rounding to integer and matching is what I prefer.Actually stretching bitmap should still be done, but only as last resort if no vector version of the glyph is available at all. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20090203/9d717853/attachment.pgp
Nicolas Mailhot wrote:> Le mardi 03 f?vrier 2009 ? 15:42 -0500, Behdad Esfahbod a ?crit : >> Pat Suwalski wrote: > >>> Actually, isn''t that exactly how bitmap information embedded into >>> True/OpenType is handled? >> Oll Korrect. I agree that rounding to integer and matching is what I prefer. > > Actually stretching bitmap should still be done, but only as last resort > if no vector version of the glyph is available at all.Note that currently we don''t stretch the bitmap. You ask for a 96px font and get one rendered at 10px! That''s perhaps fine for the screen, but for vector output makes zero sense. Oh well... behdad