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

[Vadim Plessky]

Hello David, nice to hear you!

On Friday 16 November 2001 10:54, David Turner wrote:
|   Vadim Plessky a écrit :
|   > On Sunday 11 November 2001 13:57, Lars Knoll wrote:
|   > |   On Saturday 10 November 2001 05:38, Ilya Konstantinov wrote:
|   > |   >
|   > |   > 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 ;-)

In fact, CSS3 is rather bloated - but IMO it still looks better than CSS2. :-)
My question was what is better option, in your opinion: try to use Panose or 
HStem/VStem values?
 
as "no one with a sane mind was going to implement it" - well, core modules 
(like Box Model, Inheritance) are more-less ok.
There is a problem, though, with Tables and Positioning modules - they are 
quite complex/unclear even in CSS2, and complexity in CSS3 becomes enermous.
Some Microsoft developers (on www-style list) told that they do not think 
that someone will implement all CSS3 modules, and idea with modularization 
was just to allow developers to select necessary modules. 

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

And many fonts jsut do not have PANOSE info as well, or have it incorrect.
This puts Panose vs. HStem/Vstem in appx. equal conditions, when considering 
useful font slection mechanism...
|
|   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.

sounds quite reasonable.
|
|   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..

yes, I was keeping your auto-hinter in mind :-) 
|
|   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..
|

Do you have more info on UniType?
May be, there is some kind of White Paper of Draft around...
I remember you were saying about CSS-based layout library, but as you 
consider CSS3 bloated, I wonder what kind of solution you can propose.
IMO PostScript is not right solution here - as it's even more bloated.
  SVG (inspired by Adobe and Kodak)?  not sure as well ;-))
I mean, some parts of SVG are really nice (and SVG-based Icons are floating 
around me  :-), but probably completed SVG specification is somewhat overkill 
for such task (and SVG still can miss something required for Type Layout) 

|
|   Regards,
|
|   - David
|
|   > 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.

in the mean time, I found some articles that Microsoft was not willing to 
release even IE6 separatly from WinXP.
And it seems that in year or two IE7 will be completely integrated in WinXXX, 
so we will not see wide adoption of it by Windows 95/98 users.

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

-- 

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/