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 > _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
