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

[David Turner]

Hello Vadim,

Vadim Plessky a écrit :
> 
> 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/ .
> 
I though that CSS3 was bloated, suffered from dire second-system effects
and that
no one with a sane mind was going to implement it.. Well, how things
change ;-)

It's true that the Postscript formats provide HStem/VStem values even
though many
fonts don't have extremely useful values here; note also that there is
nothing
similar in TrueType.

Instead of relying on format-specific modules and features, which will
invariably
not work with the highest quality fonts on your system, I propose to
simply
compute them from the glyph outlines themselves.

For your information, the auto-hinter already contains code to compute
stems
(in src/autohint/ahglyph.c) and this could be easily adapted to only
compute
the values you'd need. This could be added as an optional module to
FreeType
when completed..

There is also the problem of storing all data in a persistent store to
avoid
re-computing everything at run-time.. Yet another argument why something
like UniType is needed..


Regards,

- David


> 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/
> 
> _______________________________________________
> Freetype mailing list
> address@hidden
> http://www.freetype.org/mailman/listinfo/freetype