[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Freetype] PANOSE, and other ways to map fonts correctly [Re: Konqu
Re: [Freetype] PANOSE, and other ways to map fonts correctly [Re: Konqueror double-bidi?]
Fri, 16 Nov 2001 19:13:45 +0000
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
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
| 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
| not work with the highest quality fonts on your system, I propose to
| 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
| 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)
| - 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.
33 Window Decorations and 6 Widget Styles for KDE
- [Freetype] PANOSE, and other ways to map fonts correctly [Re: Konqueror double-bidi?], Vadim Plessky, 2001/11/12
- Re: [Freetype] PANOSE, and other ways to map fonts correctly [Re: Konqueror double-bidi?], David Turner, 2001/11/16
- Re: [Freetype] PANOSE, and other ways to map fonts correctly [Re: Konqueror double-bidi?],
Vadim Plessky <=
- [Freetype] Re: PANOSE, and other ways to map fonts correctly [Re: Konqueror double-bidi?], Alan Shutko, 2001/11/16
- Re: [Freetype] Re: PANOSE, and other ways to map fonts correctly [Re: Konqueror double-bidi?], Vadim Plessky, 2001/11/17
- Re: [Freetype] Re: PANOSE, and other ways to map fonts correctly [Re: Konqueror double-bidi?], Leonard Rosenthol, 2001/11/18
- Re: [Freetype] Re: PANOSE, and other ways to map fonts correctly, Vadim Plessky, 2001/11/19
- Re: [Freetype] Re: PANOSE, and other ways to map fonts correctly, Leonard Rosenthol, 2001/11/19
- [Freetype] Getting black bitmaps - why?, Paul Miller, 2001/11/21
- Re: [Freetype] Getting black bitmaps - why?, Paul Miller, 2001/11/23