GreenVille font, is it still available? I have a question about it.

[Wierd_w]

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

[Markus Amsler]

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:
>
> 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.

4) Drop SFD->TTF conversion and add a "width hinted" TTF font.