[Freetype] PANOSE, and other ways to map fonts correctly [Re: Konqueror double-bidi?]

[Vadim Plessky]

On Sunday 11 November 2001 13:57, Lars Knoll wrote:
|   On Saturday 10 November 2001 05:38, Ilya Konstantinov wrote:
|   > On Fri, Nov 09, 2001 at 07:05:47PM +0100, Lars Knoll wrote:
|   > > Have a look at qtconfig. It currently has no KDE integration, but it
|   > > allows you to specify a list of substitutions that should be tried
|   > > for every font, in case the glyph you want is not available in the
|   > > font requested.
|   >
|   > Is there any chance we could retrieve PANOSE info from the fonts and
|   > decide by it, or is it somehow patented?
|
|   I think it's open. It's an interesting idea, but I'm not sure how easy to
|   imlpement it'll be. But I guess we should have a look.

In order to implement CSS3: Fonts module support (in KHTML), we will need to 
get access to HStem and VStem values (from PostScript Type1 or TrueType font)
It seems that mapping font according to HStem and VStem values (arrays) was 
recognized as more accurate than Panose (in W3C CSS Working Group) - or at 
least as effective, as Panose.  You can find more details in CSS3 
specifications, available at http://www.w3.org/Style/CSS/ .

For people who are not aware about such "font details" as Hstem and VStem.
Concept was introduced by Adobe for hinting in PostScript Type1 fonts.
Standard PS font BoundBox has dimension of 1000x1000 (floating point values).
Than you can calculate a set of _standard_ stem's widths from all characters 
in the font. If you take, for example, H, K, M, T glyphs in Helvetica, and 
get width of vertical stems in those glyphs - it will be, say, around 65.
Glyphs a, b, h, k, m, t - most likely, will have smaller value for VStem 
width - about 50-55.
You put both values into VStem array (typically, from 3 to 6 values)
Later on, PostScript interpreter uses these values (HStem and VStem arrays) 
to *guess* what exact width of Vstem or height of Hstem should be, doing 
grid-mapping, stem-width(height) correction, etc. - for particular output 
device.
IMO set of Hstem and Vstem values is better characteristic of the font than 
general info like "Sans-serif, semi-bold" - which is most likely you will get 
from Panose for Helvetica Light or Arial.
For example, I was comparing Arial and Pragmatica (clone of Helvetica with 
Cyrillic support) - they have absolutely different values of HStem and VStem. 
(while most likely you will not be able to distinguish these 2 fonts 
vusually, unless you are a font expert of have extensive DTP experience)
If you are interested in more details, I can found these data on my hard disk 
and give exact values.  

AFAIK FreeType2 library provides access to HStem and VStem values (they are, 
in fact, required for PS Type1 font rendering, and can be easily calculated 
for TrueType or other outline fonts)
I don't know wether Qt2 or Qt3 picks up those values and exposures these 
values in some sort of API.
But adding such API to Qt, or directly to kdelibs, seems quite reasonable.

May be, some FreeType developers have experience of using Hstem/Vstem values 
in their applications?   What algorithm, for example, Pango library uses to 
make "font guess"/mapping?

Anyway, having CSS3: Fonts support in *any* of Open-Source projects will 
benefit *all* Open-Source movement - as Microsoft doesn't have it in IE6, and 
most likely they will not get it in another year or 2 years.
So it would be very nice if KHTML has support for this, far ahead of 
Microsoft - it gives very good reason for Windows users to upgrade to Linux, 
FreeBSD or other UNIX'es.
  
|
|   Lars

-- 
Best Regards,

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/