Re: [ft-devel] [patch] TrueType GX/AAT validator

[mpsuzuki]

Dear Mr. George Williams,

Oops, sorry for crossing of paths.

On 23 Aug 2005 17:35:12 -0700
George Williams <address@hidden> wrote:

>So:
>a) 14 fonts uses too-large feature number (out of defined range).
>I can't find anything that says the range is a byte, but there may be
>something I've missed.

I agree. I remove it from the error list.

>b)  67 fonts uses feature number which should not be used.
>I'm assuming this means features not defined in Apple's Registry. I
>think this should be ok.

No, I was meaning about the hole of predefined range.
According to http://developer.apple.com/fonts/Registry/index.html,

>   kanaSpacingType = 25,

>   ideographicSpacingType = 26,

>   cjkRomanSpacingType = 103,

>/* The following types are provided for compatibility; note that
>   their use is deprecated. */
>
>   adobeCharacterSpacingType = 100,        /* prefer 22 */
>   adobeKanaSpacingType = 101,             /* prefer 25 */
>   adobeKanjiSpacingType = 102,            /* prefer 26 */
>   adobeSquareLigatures = 104,             /* prefer 1 */

There is a hole from 27 to 99, I thought it is reserved area,
although I could not find any documentation about it.
It should be used as same as the undefined area > 105?

>c) 117 fonts set wrong feature range (nSetting).
>do you mean that more settings are defined for a feature than are
>present for that feature in the 'feat' table? If so, I agree this should
>be an error.

>Or do you mean more settings are defined than are present in the
>registry? I think that should be ok.

The latter. I was meaning the nSetting value is out of range
defined in Apple registry. For example, feature number 1
(ligatureType) has 15 settings aslike:

>enum {
...
>   ligaturesType = 1,
>
>      requiredLigaturesOnSelector          = 0,
...
>      abbrevSquaredLigaturesOffSelector    = 15,

But, Courier 3.5 in MacOS 9.2.2:

[ftvalid:gx] validation targets: mort
-------------------------------------------------------------------
validation mort table
validate chain 1/2
  mort chain header table
    mort feature list table
...
    featureType 1 is registered    setting 2    
    featureType 1 is registered    setting 3    
    featureType 1 is registered    setting 32    out of defined range 15
    featureType 1 is registered    setting 33    out of defined range 15

setting 32, 33 are out of defined range.

Your suggestion is that undefined setting values should be handled
as the same way for user-defined feature number (so they are not errors)?
If so, I will remove this from the error list.

Regards,
mpsuzuki