DR 09-0061: Shared MLs, Shared Simple Types: Constrain ST_Panose value set

[Horton, Gareth]

Hi all,

Maybe this is the result of the Panose StrokeVariation structure not being large enough to hold all the possible values in the Panose spec.

In Panose, values from 0-10 are allowed:

2.6 Stroke Variation

Sub-digits

0-Any
1-No Fit
2-No Variation
3-Gradual/Diagonal
4-Gradual/Transitional
5-Gradual/Vertical
6-Gradual/Horizontal
7-Rapid/Vertical
8-Rapid/Horizontal
9-Instant/Vertical
10-Instant/Horizontal

http://www.monotypeimaging.com/ProductsServices/pan2.aspx (This was the best reference I could find, I'm not 100% sure it's authoritative, I would prefer that Suzuki-san could confirm it's accuracy)

The MSDN structure only allows the following:

PAN_ANY = 0x00,
PAN_NO_FIT = 0x01,
PAN_STROKE_GRADUAL_DIAG = 0x02,
PAN_STROKE_GRADUAL_TRAN = 0x03,
PAN_STROKE_GRADUAL_VERT = 0x04,
PAN_STROKE_GRADUAL_HORZ = 0x05,
PAN_STROKE_RAPID_VERT = 0x06,
PAN_STROKE_RAPID_HORZ = 0x07,
PAN_STROKE_INSTANT_VERT = 0x08

It would seem that No Variation and Instant/Horizontal are not catered for by the MSDN structure.  

Hopefully, some remapping occurs, since in Panose, 2 is No Variation, compared to Gradual/Diagonal in the MSDN structure, putting all higher values off by 1.

Gareth

-----Original Message-----
From: suzuki toshiya [mailto:mpsuzuki at hiroshima-u.ac.jp] 
Sent: 03 December 2010 11:00
To: Chris Rae
Cc: e-SC34-WG4 at ecma-international.org
Subject: Re: DR 09-0061: Shared MLs, Shared Simple Types: Constrain ST_Panose value set

Dear Chris,

Sorry for lated response.

>> 04040605051002020D02 (Gabriola)
>> 04020705040A02060702	(Algerian)
>> 04030905020B02020C02	(Bauhaus 93)
>> 04040905080B02020502	(Broadway)

>> \s*0?[0-5]\s*0?[0-9A-Fa-f]\s*0?[0-9ABab]\s*0?[0-9]\s*0?[0-9]\s*0?[0-8
>> ]\s*0?[0-9ABab]\s*0?[0-9A-Fa-f]\s*0?[0-9A-Da-d]\s*0?[0-7]\s*

According to MSDN's definition of Panose:
http://msdn.microsoft.com/en-us/library/dd162774%28VS.85%29.aspx
the analysis of the values of 4 fonts in above is following:

name:        defined range:  the values in 4 fonts in above
bFamilyType: 0x00 - 0x05: 0x04 ok
bSerifStyle: 0x00 - 0x0F: 0x02-0x04 ok
bWeight:     0x00 - 0x0B: 0x06-0x09 ok
bProportion: 0x00 - 0x09: 0x05 ok
bContrast:   0x00 - 0x09: 0x02-0x08 ok
bStrokeVariation: 0x00 - 0x08: 0x0B-0x10 not good
bArmStyle:   0x00 - 0x0B: 0x02 ok
bLetterForm: 0x00 - 0x0F: 0x02-0x06 ok
bMidLine:    0x00 - 0x0D: 0x05-0x0D ok
bXHeight:    0x00 - 0x07: 0x02 ok

The stroke variation byte exceeds the defined range of PANOSE.bStrokeVariation in MSDN.

I have no idea how existing implementations of Microsoft handle these values. The production of these fonts are
following:

* Gabriola is produced by John Hudson, Microsoft
* Algerian is produced by URW
* Bauhaus 93 is produced by URW
* Broadway is designed by URW, MonoType and Microsoft

Chris, could you find any experts worked for the production of Gabriola? I want to ask how its bStrokeVariation value (out of the range defined in MSDN) is defined and how it is expected to be dealt. I'm not sure the values in other fonts (Algerian, Bauhaus 93 and Broadway) are set by Microsoft or other productions (like URW).

Regards,
suzuki toshiya, Hiroshima University, Japan

suzuki toshiya wrote:
> Dear Chris,
> 
> Great thank you and the testing team in Microsoft for the checking! I 
> will reply within 48 hours, please wait.
> 
> Regards,
> mpsuzuki
> 
> Chris Rae wrote:
>> Just when we thought this was done! I had one of our testers run through a bunch of existing documents to see if he could find any Panose values that weren't covered by this RegExp. Unfortunately, he found four (the font names they correspond to are on the right just for info):
>>
>> 04040605051002020D02 (Gabriola)
>> 04020705040A02060702	(Algerian)
>> 04030905020B02020C02	(Bauhaus 93)
>> 04040905080B02020502	(Broadway)
>>
>> As far as I can see the only thing that these have in common is that they start with 04, but that does seem to be permitted by Suzuki-san's RegEx. For reference, the RegEx we were using was:
>>
>> \s*0?[0-5]\s*0?[0-9A-Fa-f]\s*0?[0-9ABab]\s*0?[0-9]\s*0?[0-9]\s*0?[0-8
>> ]\s*0?[0-9ABab]\s*0?[0-9A-Fa-f]\s*0?[0-9A-Da-d]\s*0?[0-7]\s*
>>
>> Suzuki-san, do you think these values are incorrect?
>>
>> I haven't actually delved into which part of the RegEx is failing specifically here, but I'll do that if you don't see anything obvious.
>>
>> Chris
> 
>