DR 09-0061: Shared MLs, Shared Simple Types: Constrain ST_Panose value set
mpsuzuki at hiroshima-u.ac.jp
mpsuzuki at hiroshima-u.ac.jp
Wed Mar 16 09:24:17 CET 2011
Dear Chris,
Sorry for long lated response, and thank you for detailed
checking of the defined range of the values in genuine
Panose, for "Latin Text" family kind and "Latin Decorative"
family kinds. As your message described in detail, the each
digits are defined independently, and the valid ranges of
the digits are different in the family kinds. It is confusing
contrast from the Panose digits in OS/2 table specified by
OpenType spec.
<tt>
<OpenType_Panose>
bFamilyType 0x00 - 0x05
bSerifStyle 0x00 - 0x0F
bWeight 0x00 - 0x0B
bProportion 0x00 - 0x09
bContrast 0x00 - 0x09
bStrokeVariation 0x00 - 0x08
bArmStyle 0x00 - 0x0B
bLetterForm 0x00 - 0x0F
bMidLine 0x00 - 0x0D
bXHeight 0x00 - 0x07
</OpenType_Panose>
<genuine_Panose>
LatinText LatinHandWritten LatinDecoratives LatinSymbol
0x02 0x03 0x04 0x05
0x00 - 0x0F 0x00 - 0x09 0x00 - 0x0C 0x00 - 0x0C
0x00 - 0x0B 0x00 - 0x0B 0x00 - 0x0B 0x01
0x00 - 0x09 0x00 - 0x03 0x00 - 0x09 0x00 - 0x03
0x00 - 0x09 0x00 - 0x06 0x00 - 0x0D 0x01
0x00 - 0x0A 0x00 - 0x09 0x00 - 0x10 0x00 - 0x09
0x00 - 0x0B 0x00 - 0x0A 0x00 - 0x07 0x00 - 0x09
0x00 - 0x0F 0x00 - 0x0D 0x00 - 0x08 0x00 - 0x09
0x00 - 0x0D 0x00 - 0x0D 0x00 - 0x0F 0x00 - 0x09
0x00 - 0x07 0x00 - 0x06 0x00 - 0x05 0x00 - 0x09
</genuine_Panose>
</tt>
I had expected that the font vendors are following to
GDI or OpenType spec, because the primal target or OS/2
table is IBM OS/2 or Microsoft Windows (Apple Macintosh
does not request to have OS/2 table). However, you reported
4 fonts bundled to Microsoft products don't fit to the
value range in GDI or OpenType spec, but fit to genuine
Panose spec (in your message posted on 2010-Dec-01):
04 04 06 05 05 10 02 02 0D 02 (Gabriola)
04 02 07 05 04 0A 02 06 07 02 (Algerian)
04 03 09 05 02 0B 02 02 0C 02 (Bauhaus 93)
04 04 09 05 08 0B 02 02 05 02 (Broadway)
These values have too large value for 6th digit (0x0A - 0x10),
if we assume GDI or OpenType spec. In the discussion in last
year, I was proposing a validation which is based on GDI or
OpenType spec range, but accepts all concrete values of existing
and important fonts. If some font vendors produce the products
with Panose value following to genuine Panose spec,
this direction (based on GDI or OpenType spec and relaxing it
to accept existing products) should be reconsidered.
Just I've revisited my previous investigation about which spec
is used by the font vendors, genuine Panose or OpenType? (posted
in 2010-Oct-27, with perl scripts checking vanose value and the
list of Panose values collected from the computers around me).
In my investigation all 2666 fonts are valid in MSDN spec but 45
fonts (mainly Latin Decorative and Latin Symbols) are invalid in
genuine Panose spec, and I guessed that MSDN spec is preferred by
the font vendors. But, today I found a bug of my checker for genuine
Panose, specific to Latin Decorative. The syntax I checked for
Latin Decorative was:
\s*0?4\s*0?[0-9A-Ca-c]\s*0?[0-9ABab]\s*0?[0-9]\s*0?[0-9A-Da-d]\s*(0?[0-9A-Fa-f]|10)\s*0[0-7]\s*0?[0-8]\s*0[0-9A-Fa-f]\*0[0-5]\s*
There is a typo, "\*" should be "\s*". If this bug is fixed,
the invalid Panose values in my list are updated as:
Windows 7
---------
invalid panose: 05000000000000000000 # esri_30s.ttf
invalid panose: 05000000000000000000 # wingding.ttf
invalid panose: 05000500000000000000 # REFSPCL.TTF
invalid panose: 05000800060100000101 # Mathematica1b.ttf
invalid panose: 05010000000000000000 # opens___.ttf
invalid panose: 05010700040101000101 # Mathematica4mb.ttf
invalid panose: 05010800040101000101 # Mathematica4b.ttf
Mac OS X
--------
invalid panose: 01000500000000020003 # Kokonor.ttf
invalid panose: 01000500000000020004 # Baghdad.ttf
invalid panose: 05000000000000000000 # Apple Braille Outline 6 Dot.ttf
invalid panose: 05000000000000000000 # Apple Braille Outline 8 Dot.ttf
invalid panose: 05000000000000000000 # Apple Braille Pinpoint 6 Dot.ttf
invalid panose: 05000000000000000000 # Apple Braille Pinpoint 8 Dot.ttf
invalid panose: 05000000000000000000 # Apple Braille.ttf
invalid panose: 05000000000000000000 # Wingdings.ttf
GNU/Linux
---------
invalid panose: 01000500000000000000 # homa.ttf
invalid panose: 01000506000000020004 # nazli.ttf
invalid panose: 01000700000000000000 # titr.ttf
invalid panose: 030b0800000101010101 # UnPilgiBold.ttf
invalid panose: 05010000000000000000 # opens___.ttf
In pragmatic scope, the problem seems to be specific to
Latin Symbol only (01 xx xx xx xx xx xx xx xx xx is "no
fit", so it is not so confusing to insist as following
values are simply ignored).
If existing implementation of Microsoft follows to genuine
Panose spec and the value range definitions in MSDN is
recognized to be an insufficiently described info, the
direction to start from GDI / Opentype definition and
extend to accept important products should be reconsidered.
Chris, is it possible to find any expert in Microsoft who
knows how Panose values in font or office document are used?
Regards,
suzuki toshiya, Hiroshima University, Japan
P.S.
corrected regex for genuine Panose would be:
\s*(00){10}\s*|\s*(01){10}\s*|\s*02\s*0[0-9A-Fa-f]\s*0[0-9ABab]\s*0[0-9]\s*0[0-9]\s*0[0-9Aa]\s*0[0-9ABab]\s*0[0-9A-Fa-f]\s*0[0-9A-Da-d]\s*0[0-7]\s*|\s*03\s*0[0-9]\s*0[0-9ABab]\s*0[0-3]\s*0[0-6]\s*0[0-9]\s*0[0-9Aa]\s*0[0-9A-Da-d]\s*0[0-9A-Da-d]\s*0[0-6]\s*|\s*04\s*0[0-9A-Ca-c]\s*0[0-9ABab]\s*0[0-9]\s*0[0-9A-Da-d]\s*(0[0-9A-Fa-f]|10)\s*0[0-7]\s*0[0-8]\s*0[0-9A-Fa-f]\s*0[0-5]\s*|\s*05\s*0[0-9A-Ca-c]\s*01\s*0[0-3]\s*01\s*0[0-9]\s*0[0-9]\s*0[0-9]\s*0[0-9]\s*0[0-9]\s*
On Thu, 27 Jan 2011 00:38:22 +0000
Chris Rae <Chris.Rae at microsoft.com> wrote:
>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
>>>
>>
>
>
More information about the sc34wg4
mailing list