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

[suzuki toshiya]

Dear Horton,

Thank you for comment with the quotation of original spec.
As you quoted, StrokeVariation is NOT 1-dimensional parameter
varying from weak to strong. Forced to say, the combination
of multiple parameters {Gradual/Rapid/Instant} and {Diagobal/
Transitional/Vertical/Horizontal}. Therefore, there is a
possibility that the values out of defined range may describe
special characteristic unlisted in existing Panose. Thus
I want to hear the background how the values out of defined
range were selected for the fonts bundled to Microsoft products,
and how existing implementations handle them.

Regards,
suzuki toshiya, Hiroshima University, Japan

Horton, Gareth wrote:
> 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
>>
>