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

[mpsuzuki at hiroshima-u.ac.jp]

Dear Chris,

Excuse me, 05000000000000000000 is invalid Panose,
if I follow panose.com definition.

Please refer "Latin Pictorial" page,

  http://www.panose.com/ProductsServices/pan5.aspx

"5.3 Weight" and "5.5 Aspect ratio & contrast".
In there, the 3rd and 5th digits of the Panose for
family kind 5 are restricted to "1".
"0" is unavailable. Thus my panose.com-strict regex

\s*0?2\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*0?3\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*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*|\s*0?5\s*0?[0-9A-Ca-c]\s*0?1\s*0?[0-3]\s*0?1\s*0?[0-9]\s*0?[0-9]\s*0?[0-9]\s*0?[0-9]\s*0?[0-9]\s*

refuses 05000000000000000000.

However, as I mentioned in Tokyo meeting, the definition
of Panose is different between MSDN and panose.com.

http://msdn.microsoft.com/en-us/library/ms533998.aspx
http://www.panose.com/

The MSDN-style regex

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

accepts 05000000000000000000.

I will check the Panose values in existing TrueType fonts
bundled to Microsoft Windows etc and the number of the
Panose that is valid in MSDN syntax but invalid in Panose.com
syntax is remarkably large.

Regards,
mpsuzuki

On Wed, 27 Oct 2010 11:57:27 +0900
mpsuzuki at hiroshima-u.ac.jp wrote:

>Dear Chris,
>
>Sorry for lated response. The value 05000000000000000000
>must be accepted, and I was thinking my proposal accepts
>it. I will check, please wait. I will post my replies to
>other issues within 12 hours.
>
>Regards,
>suzuki toshiya, Hiroshima University, Japan
>
>On Tue, 26 Oct 2010 21:24:50 +0000
>Chris Rae <Chris.Rae at microsoft.com> wrote:
>
>>I may have spoken too soon on this one. It would appear there are some values which are acceptable according to the Panose spec which this RegExp does not regard as valid. For example, 05000000000000000000. This seems to be valid according to section 1.5 of the Panose spec (http://www.panose.com/ProductsServices/pan1.aspx) but doesn't match this RegEx. I've pasted the section below.
>>
>>Suzuki-san - is there a chance you could check that I'm right in this assertion?
>>
>>Chris
>>
>>--
>>
>>Panose: 1.5 Digit values of 0 and 1
>>The reader will notice that the value 0 and 1 are defined as Any and No Fit for every digit in the PANOSE system. These have specific meanings to the mapper. 0 means match that digit with any available digit. This allows the mapper to handle distortable typefaces such as multiple master fonts in which, for example, weights may be variable or serifs may change. 1 means that the item being classified does not fit within the present system. There are two possible causes of this. First is that there has been no work done on that family of faces, for example at the present time an Arabic cursive font would have the PANOSE number 1 1 1 1 1 1 1 1 1 1 as there has as yet been no work done on Arabic fonts.
>>
>>-----Original Message-----
>>From: Chris Rae [mailto:Chris.Rae at microsoft.com] 
>>Sent: 25 October 2010 15:37
>>To: e-SC34-WG4 at ecma-international.org
>>Cc: suzuki toshiya (mpsuzuki at hiroshima-u.ac.jp)
>>Subject: DR 09-0061 _ Shared MLs, Shared Simple Types: Constrain ST_Panose value set
>>
>>http://cid-c8ba0861dc5e4adc.office.live.com/view.aspx/Public%20Documents/2009/DR-09-0061.docx
>>
>>This is a very simple one indeed. We talked about this at some length at Tokyo - I was under the impression that certain valid Panose values were not accepted by Suzuki-san's RegEx. This, it turns out, was a mistake - I was truncating unused zeros from the front of the strings and in actual fact this is not done (in Office, or in the Panose specification itself). Panose consists of ten byte couplets denoted in hex where leading zeros are always included, even on the first byte.
>>
>>I used http://www.regexplanet.com/simple/index.html to validate Suzuki-san's sample against some Word documents and it looks like this RegEx does indeed work fine (some sample values: 020F0502020204030204, 02010600030101010101, 020B0604020202020204, 02020603050405020304, 02040503050406030204).
>>
>>I think we can accept the original solution as proposed by the submitter in the DR. Let's discuss on the next call.
>>
>>Chris
>>