Fri 06 Feb 2009 07:11:17 PM UTC, comment #12:
Ok, that all makes sense.
Thanks for tracking this down.
|
Fri 06 Feb 2009 10:18:38 AM UTC, comment #11:
To 1.: No. The hinting instructions in this font only work
fine if you use ClearType, this is, if the horizontal resolution
is three times the vertical resolution. With Vista, this is the
default rendering, so using this font with an older Windows
version you would get bad results too by default.
To 2.: The hinting is bad basically for all ppem values if you
don't triple the horizontal resolution. At larger sizes the
effects are not that visible, however.
To 3.: The missing gasp table is not a problem; Windows applies
some defaults then. However, for ClearType, the gasp table is
`ignored' more or less; you won't get a B/W rendering.
My conclusion: The font is buggy. A well designed font should
support both normal and ClearType rendering.
FreeType doesn't honor the gasp table; this should be handled
on a higher level. You can access the table with a call to
FT_Get_Gasp().
|
Wed 04 Feb 2009 07:42:45 PM UTC, comment #10:
If I understand this correctly (and please correct me if not)...
1. The hinting instructions in this font are done in a way that causes serious problems below a certain font size.
2. For some reason, the hinting instructions work ok for ClearType rendering (maybe because the horizontal ppem is above the magic threshold?).
3. Normally, a TrueType font ought to have a gasp table that tells the rasterizer not to use hinting below a certain font size. But the gasp table is missing in this font.
If that's correct, one solution would be for me to simply disable hinting (in my code that calls FreeType) for TrueType fonts below a certain font size. That size threshold could come from either the gasp table (if present), or a default value (otherwise).
Does FreeType provide functions to query the gasp table?
Does FreeType honor the gasp table (if present)? How does that interact with the various flags (FT_LOAD_NO_AUTOHINT, FT_LOAD_NO_HINTING, FT_LOAD_FORCE_AUTOHINT)?
|
Wed 04 Feb 2009 06:47:16 AM UTC, comment #9:
He further writes
[...] it seemed to look fine with ClearType. Much better than
when I added a gasp table and verified that anti-aliasing
worked with the font.
I suspect that an old PDF generator has been used which stripped
off the ClearType bit from the `head' table.
|
Tue 03 Feb 2009 10:46:55 PM UTC, comment #8:
Here a first answer from the Microsoft guy:
The font does not have a gasp table, so the system uses some
default settings that don't kick in until higher sizes. I was
able to add a gasp table with the appropriate size threshold
and the sample displayed anti-aliased.
In this case, Windows is not refusing ANTIALIASED_QUALITY, but
instead it is using a default threshold to enable
ANTIALIASED_QUALITY for this font.
Standard ClearType does not use the gasp table (although other
forms of ClearType do.)
|
Sat 31 Jan 2009 03:12:51 PM UTC, comment #7:
Thanks. Forwarded to a Microsoft guy asking for help.
|
Tue 27 Jan 2009 07:12:57 PM UTC, comment #6:
Here you go.
birka-subset2.ttf is a modified font file (with a 'name' table).
testfont.cpp is a program which displays the first 256 characters in a font. You need to pass it the font file name and the font name (from the name table). In this case:
testfont birka-subset2.ttf foo99
The three "quality" options are selected by uncommenting the relevant CreateFont call.
(file #17341, file #17342)
|
Tue 27 Jan 2009 05:36:19 AM UTC, comment #5:
Please do so.
|
Mon 26 Jan 2009 07:51:16 PM UTC, comment #4:
Ah, I had no idea that there were separate hints for ClearType.
I'm using a simple program I wrote to test the font. The key thing is the call to CreateFont():
font = CreateFont(14, 0, 0, 0, 0, 0, 0, 0, DEFAULT_CHARSET,
0, 0, ANTIALIASED_QUALITY, 0, fontName);
or
font = CreateFont(14, 0, 0, 0, 0, 0, 0, 0, DEFAULT_CHARSET,
0, 0, CLEARTYPE_QUALITY, 0, fontName);
The text is then drawn with TextOut().
The font embedded in the PDF file did not have a 'name' table, and I don't know how to make Windows display a font without a name, so I ran it through some code (part of Xpdf) that cleans up TrueType fonts (fixes various font problems that I've run into over the years, and adds a name table). That didn't change the behavior of FreeType at all.
I can send the modified font and the full Windows program if you want them.
|
Sun 18 Jan 2009 06:56:50 AM UTC, comment #3:
Thanks. What have you been using to create the Windows images?
A program written by yourself? It's very interesting that
`ANTIALIASED_QUALITY' doesn't work. To which function is this a
parameter? As soon as I know how you've checked that, I'll ask a
Microsoft guy – I can't find a hint for this behaviour within the
font. Maybe the lack of a `gasp' table is causing this?
It seems that this font has hints for ClearType only and doesn't
work at all with normal hinting. If you debug the hinting of
glyph `M' with FontForge, tripling the horizontal resolution,
the hints work just fine (see attached image).
(file #17282)
|
Fri 16 Jan 2009 07:32:10 PM UTC, comment #2:
Ok, here you go...
Without antialiasing, it looks pretty bad, as you suspected. [first screenshot]
Windows refuses to do standard antialiasing (ANTIALIASED_QUALITY) at that size.
With ClearType (CLEARTYPE_QUALITY), the font looks fine. [second screenshot]
Do you know if Windows turns off hinting (bytecode processing) when it does ClearType rendering? (That seems unlikely to me, but who knows.)
Adobe Reader (on Linux) renders the font nicely. (But Adobe seems to have quite a bit of stuff to magically deal with bad/broken TrueType fonts, so maybe that's not so surprising.)
Do you have any idea what's going on here? Is there some way to detect this situation and selectively turn off hinting for problematic fonts?
(file #17273, file #17274)
|
Fri 16 Jan 2009 06:54:40 AM UTC, comment #1:
Indeed, the instructions for `M' cause havoc at 12ppem.
However, before investigating this in detail, I need the
confirmation that this font works well on a Windows machine
(which I doubt).
Please provide a Windows screen shot of the font at 12ppem.
|
Thu 15 Jan 2009 07:56:25 PM UTC, original submission:
I'm attaching a TrueType font where the native hinting behaves poorly at small sizes. For example, run "ftview 12 birka-subset.ttf" and look at the 'M', 'd', 'f', and 'j' glyphs.
I'm not sure the problem is really size-related. At larger sizes, those glyphs still look a little bit odd (leftmost stem in 'M' is slanted, vertical stem in 'd' is too skinny, etc.) -- but it's not so noticeable.
I see the same behavior with FreeType 2.3.1, 2.3.5, and 2.3.8.
The font is a subset taken from a PDF file, so the encoding is probably a little weird.
The font looks fine with the autohinter (or with hinting completely disabled). If I display the PDF file with Adobe Reader, it looks fine, so I'm guessing it's not a bug in the font (but it's hard to say for sure).
|