Markus Amsler wrote:
I neither fully understood it, but here my opinion.
It >looks like the
"only" problem he has is the TrueType hinting, which affects small font sizes. As long as the kerning (=width of a glyph) is correct, and the font looks somehow similar, it should be suitable for wine's need. So it should be possible to convert Larry's TTF version
with >fontforge to SDF,
and you're done. Adding hinting is IMO a second step.
This is incorrect. The metric EM size per point size is also 'Hintable' with real TrueType instructions, and Tahoma DOES do this. (I can tell, because I ran this test case just today-- Notice how the fonts start being pretty much identically kerned and spaced after about 15pt. Since wine is STUCK using Type-1 hints with FontForge, I built a Type-1 hinted .OTF with Postscript formatted outlines for the test.)
http://lunacy-inc.dyndns.org:88/ahhah/TahomaVS%20Greenville%20Type1%20(7%20t...
http://lunacy-inc.dyndns.org:88/ahhah/TahomaVS%20Greenville%20Type1%20(11%20...
http://lunacy-inc.dyndns.org:88/ahhah/TahomaVS%20Greenville%20Type1%20(14%20...
As you can see, there is a VERY LARGE discrepency between greenville (without TTF instructions) and MS Tahoma (Which does use TTF instructions). Type-1 hinting system does not have a mechanism to overcome this incongruity, because the glyphs have been arbitrarily resized using TTF instructions in MS Tahoma, and Type-1 hinting system does not have a mechanism for this.
Depending on how far you want to go, you have 3 options as I see them:
1) (Best,but unlikely, due to the intense effort required) You fix FontForge to support TTF instructions natively, so that it can build a suitable TTF hinted font file, then scream at FreeType to support them more "Sanely."
2) Use the Type-1 font that is correct at sizes 15 and up, and use a bitmapped font for sizes below that and have WINE perform the substitution.
3) Adapt FontForge to inject SBIT record data (Basically bitmapped font data) directly into a generated OTF, and trump the rasterizer totally for these point sizes.
The last one seems the most workable, but I am unsure if .OTF files can support SBIT data records, although they are a part of the ".ttf wrapper" spec used by OTF files.--- More research would need to be performed to determine the viability of this option. Theoretically, the rasterizer should check for the existance of SBIT records, and if it finds one, simply pull the bitmap from the record, and pass it on through, totally skipping the rasterizer. I would check with Freetype's documentation to see if SBITs are supported with OTF under freetype.
MS Typography has this to say concerning SBITs and OTF files:
http://www.microsoft.com/typography/otspec/recom.htm
<quote> Embedded Bitmaps
Three tables are used to embed bitmaps in OpenType fonts. They are the 'EBLC' table for embedded bitmap locators, the 'EBDT' table for embedded bitmap data, and the 'EBSC' table for embedded bitmap scaling information. OpenType embedded bitmaps are also called 'sbits'.
The behavior of sbits within an OpenType font is essentially transparent to the client. A client need not be aware whether the bitmap returned by the rasterizer comes from an sbit or from a scan-converted outline.
The metrics in 'sbit' tables overrule the outline metrics at all sizes where sbits are defined. Fonts with 'hdmx' tables should correct those tables with 'sbit' values.
'Sbit only' fonts, that is fonts with embedded bitmaps but without outline data, are permitted. Care must be taken to ensure that all required OpenType tables except 'glyf' and 'loca' are present in such a font. Obviously, such fonts will only be able to return glyphs and sizes for which sbits are defined.
1. These metrics are returned as part of the logical font data structure by the GDI CreateLogFont() API. 2. These metrics are returned by the Apple Advanced Typography (AAT) GetFontInfo() API. </quote>
____________________________________________________________________________________ Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
Wierd_w wrote:
Markus Amsler wrote:
Adding hinting is IMO a second step.
This is incorrect. The metric EM size per point size is also 'Hintable' with real TrueType instructions, and Tahoma DOES do this. (I can tell, because I ran this test case just today-- Notice how the fonts start being pretty much identically kerned and spaced after about 15pt. Since wine is STUCK using Type-1 hints with FontForge, I built a Type-1 hinted .OTF with Postscript formatted outlines for the test.)
I would say, that's THE reason why to put TTF files into wines source. Have you done the "width hinting"?
Depending on how far you want to go, you have 3 options as I see them:
- (Best,but unlikely, due to the intense effort
required) You fix FontForge to support TTF instructions natively, so that it can build a suitable TTF hinted font file, then scream at FreeType to support them more "Sanely."
- Use the Type-1 font that is correct at sizes 15 and
up, and use a bitmapped font for sizes below that and have WINE perform the substitution.
- Adapt FontForge to inject SBIT record data
(Basically bitmapped font data) directly into a generated OTF, and trump the rasterizer totally for these point sizes.
4) Drop SFD->TTF conversion and add a "width hinted" TTF font.