proposal of non-normative regex and text for DR 09-0061, ST_Panose issue

[Chris Rae]

Hi Suzuki-san - I've been thinking this one through a bit more, and I'm wondering whether this would be a good use of "should". Could we write something along the lines of:

* [Normative] An application should use genuine Panose-1 values
* [Informative] Genuine Panose-1 values are represented by the following regex [this is informative only because it's information that is technically specified elsewhere, and I would like to avoid inadvertently contradicting the Panose spec]
* [Informative] If invalid Panose-1 values are included, an application should use the following means to pick an alternative [...]

I think this would allow us to include all of the information we want (including the results of Suzuki-san's extensive research), pushing users towards legitimate Panose, while still allowing for documents created that fell foul of the confusing selection of Panose "standards".

Your thoughts,

Chris

-----Original Message-----
From: mpsuzuki at hiroshima-u.ac.jp [mailto:mpsuzuki at hiroshima-u.ac.jp] 
Sent: 14 April 2011 14:05
To: Chris Rae
Cc: eb2m-mrt at asahi-net.or.jp; e-SC34-WG4 at ecma-international.org
Subject: Re: proposal of non-normative regex and text for DR 09-0061, ST_Panose issue

Dear Chris,

The inclusion of non-normative regex to validate Panose-1 value in ISO/IEC 29500 is acceptable?

If it is easy to reach the document describing how invalid Panose values are dealt by Microsoft Office implementation from ISO/IEC 29500 without ambiguity, moving it to out of ISO/IEC 29500 would be acceptable. Murata-san, could you tell me how other implementation specific info are included in, or separated from ISO/IEC 29500 ?

Regards,
mpsuzuki

On Thu, 14 Apr 2011 20:40:21 +0000
Chris Rae <Chris.Rae at microsoft.com> wrote:

>Hi Suzuki-san - many thanks for putting this together.
>
>I agree that this information is useful, but it contains implementation 
>details that aren't covered anywhere else in the standard so I don't 
>think it ought to be informative. That said, I am not completely sure 
>that it ought to be normative either. Typically in the standard have 
>steered clear of describing what to do with invalid values, and the 
>proposed text really just describes what Microsoft Office does with 
>invalid Panose values. We could perhaps declare in IS 29500 that the 
>value must contain a Panose-1 value, and then Microsoft should fully 
>document in their implementer notes the process you outline in this 
>text (along with any other detail or restrictions that we find).
>
>Others on WG4 - what do you think of this approach? Suzuki-san, is the 
>situation common enough that we really should document how to deal with 
>invalid data?
>
>Chris
>
>-----Original Message-----
>From: suzuki toshiya [mailto:mpsuzuki at hiroshima-u.ac.jp]
>Sent: 29 March 2011 11:44
>To: Chris Rae
>Cc: MURATA Makoto (FAMILY Given); e-SC34-WG4 at ecma-international.org
>Subject: proposal of non-normative regex and text for DR 09-0061, 
>ST_Panose issue
>
>Dear Chris,
>
>Here is my draft of non-normative regex and the description about how 
>to fallback from invalid Panose-1 value, please comment if such text is 
>suitable to ISO spec. This text is not normative, but I wish if OOXML 
>can provide the info how to simulate existing implementation by 
>Microsoft when it gets invalid Panose-1 value.
>
>Regards,
>suzuki toshiya, Hiroshima University
>