freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ft-devel] Fw: [OpenType] kerning in OTF (was: Custom platform (ID 4) cm


From: Werner LEMBERG
Subject: [ft-devel] Fw: [OpenType] kerning in OTF (was: Custom platform (ID 4) cmaps)
Date: Fri, 04 Nov 2005 08:57:23 +0100 (CET)

This might be interesting for some of you.  It means in consequence
that the higher-level code which handles GPOS has probably to discard
the kern values FreeType returns (which only looks at the `kern'
table).


    Werner
--- Begin Message --- Subject: [OpenType] Re: Custom platform (ID 4) cmaps Date: Wed, 02 Nov 2005 11:32:08 -0800
OpenType list address: address@hidden

Thomas Phinney wrote:
My memory kicked in since my last note: I believe that Adobe's current
approach for both TT and CFF flavored fonts is that if there is a
non-empty GPOS table, we don't look for a kern table.

That's right. Specifically, our current approach is to look for a kern table (for either flavour of OT font) iff (a) no GPOS is present, or (b) an empty GPOS is present.

An empty GPOS is defined here as one which has FeatureList == 0 or FeatureList.FeatureCount == 0. I believe VOLT generates such "stub" GPOS and GSUB tables.

Note that this means, for example, that if the GPOS contains only a mkmk feature, and a kern table is present, the font will be regarded as having no kerning information in it.

Sairus



At 11/1/2005 11:09 PM, you wrote:
OpenType list address: address@hidden

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On Behalf Of Adam Twardoch
> Sent: Tuesday, November 01, 2005 10:57 PM
> To: Multiple recipients of opentype
> Subject: [OpenType] Re: Custom platform (ID 4) cmaps
>
> OpenType list address: address@hidden
>
> Thomas Phinney wrote:
>  > That's a tougher call: this is another case of information
> that is  > duplicated for legacy reasons, which mostly don't
> hold for OpenType CFF  > (PS).
>
> That depends on how you treat OpenType PS fonts. If you treat
> them with Adobe code, this may be true. But the hardcoded
> special-purposes behaviors of ATM are not, and should not be,
> part of the spec, right?

We wrote the ATM code to match the spec, not the other way around.

>  >  It invokes a whole bunch of questions about how to
> process fonts  > that have both kinds of kerning. Admittedly,
> these questions are there  > for OpenType TT fonts anyway
>
> Exactly. Redundancy of information in OpenType fonts is huge
> and not very practical. But I think it helps if these
> redundancies are at least consistent among "flavors".
>
> IMO, anything that is flavor-specific in OpenType is a pest
> (like name id 4.3.1). This is why the Options dialog in
> FontLab Studio 5 is 8x as large as that in FontLab 4.6!

Yup, the flavor-specific stuff and redundancies are both a pain.

>  > - do you simply ignore the 'kern' table if you pay
> attention to the  > 'GPOS' 'kern' feature tag?
>  > - if you process both, what is their relationship? Are
> they additive, or  > does one overrule the other...?
>
> The most logical approach would be: if a new structure is
> there, ignore the old one. If GPOS with a kern feature is
> defined, the kern table should be fully ignored.

My memory kicked in since my last note: I believe that Adobe's current
approach for both TT and CFF flavored fonts is that if there is a
non-empty GPOS table, we don't look for a kern table.

>  > Of course, it would have also helped if FontLab hadn't
> made  >  it so easy to violate the spec in this area.  :/
>
> Actually, the language "OpenType fonts containing CFF
> outlines are not supported by the 'kern' table and must use
> the 'GPOS' OpenType Layout table." does not say that the
> "kern" table may not be present in the font.

If you say so.  :)

Cheers,

T

Subscribe: address@hidden
Unsubscribe: address@hidden
Set list to inactive: address@hidden
Set list to active: address@hidden
Message mode: address@hidden
Digest mode: address@hidden




Subscribe: address@hidden
Unsubscribe: address@hidden
Set list to inactive: address@hidden
Set list to active: address@hidden
Message mode: address@hidden
Digest mode: address@hidden



--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]