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

mpsuzuki at hiroshima-u.ac.jp mpsuzuki at hiroshima-u.ac.jp
Mon Jun 13 02:04:16 CEST 2011


Dear Chris,

Sorry for that I couldn't reply timely, and
thank you for the classification of normative
and informative parts about Panose issue and
the correction about the use of "should".
Your proposal is good and covering the infos
that I proposed to include. I have no objection.

In my previous draft, I inserted a long informative
text enclosed by "[Guidance: ... :end guidance]".
I will revise my draft (if required) in following:
* Splitting the text into 2 clauses (a part for regex,
  another part for invalid Panose processing).
* Insert new short line "An application should use
  genuine Panose-1 values." before informative text.
Is this following to your proposal?

And, do you have any recommendation how to enclose
the informative parts? In my previous draft, I used
[Guidance: ... :end guidance]. If [Note: ... :note]
is more suitable, I will do so.

Regards,
suzuki toshiya, Hiroshima University, Japan





Regards,


On Sat, 11 Jun 2011 01:46:47 +0000
Chris Rae <Chris.Rae at microsoft.com> wrote:

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


More information about the sc34wg4 mailing list