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

[suzuki toshiya]

Dear Chris,

Here is my revised text.

Regards,
suzuki toshiya, Hiroshima University, Japan

mpsuzuki at hiroshima-u.ac.jp wrote (2011/06/13 9:04):
> 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
>>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: DR_09-0061_mps20110613a.doc
Type: application/msword
Size: 304128 bytes
Desc: not available
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20110613/36fe9430/attachment-0001.doc>