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

Thu Jan 27 01:38:22 CET 2011

Hi all - I think I'm at the point where I can now write "Panose" on my resume.

All the numeric values in this mail are decimal.

After some extensive investigation with a few internal Microsoft people and some vendors (we outsource the creation of fonts), I have got some more information about this. It seems to be that it's true that for standard Latin Text fonts (http://www.panose.com/ProductsServices/pan2.aspx), these values are outside the bounds of those allowed for Stroke Variation. However... these are Latin Decorative fonts (http://www.panose.com/ProductsServices/pan4.aspx), and the sixth property for those fonts has been repurposed to be "Serif Variant", with a maximum value of 16 and an entirely different set of enumerations.

Inspired by this, I've gone through the other properties to see if there are any difference and I think there are:

--
Property 2 
In Latin Text this is "Serif Style Classification" and 0-15
In Latin Decorative this is "Class" and 0-12

Property 5
This is "Contrast" in both, but can be 0-9 in Latin Text and 0-13 in Latin Decorative

Property 6
As mentioned, in Latin Text this is "Stroke Variation" and 0-10
In Latin Decorative this is "Serif Variant" and 0-16

Property 7
In Latin Text this is "Arm Style" and 0-11
In Latin Decorative this is "Treatment" and 0-7

Property 8
In Latin Text this is "Letterform" and 0-15 (although there's a typo in the spec where it enumerates 1, 2, 3, 4, 5... 13, 14, 5)!
In Latin Decorative this is "Lining" and 0-8

Property 9
In Latin Text this is "Midline" and 0-13
In Latin Decorative this is "Topology" and 0-15

Property 10
In Latin Text this is "X-height" and 0-7
In Latin Decorative this is "Range of Characters" and 0-5
--

In summary, there seem to be a lot of properties which are slightly different between these two and may mean that our RegEx has to be changed.

Suzuki-san - am I right in my understanding here? Are there different types of font that are overloaded using the same Panose value set? From looking at the specification it seems as if there are yet more sets (Latin Hand Written, Latin Pictoral) that would also need to be accounted for - if I'm right in this then I'm happy to go through, assess the valid values and have a try at updating the RegEx.

Any help much appreciated.

Chris

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

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
>>
> 