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

Tue Jun 14 01:30:22 CEST 2011

Hi Suzuki-san - this looks great. I have processed this as edits to the core standard, and the result is attached. It's very similar to your proposed text, with a couple of minor modifications:

* Regarding your comment about including a normative reference to the Panose spec, there is already actually a reference to ISO/IEC 14496-22:2007 in each of the parent clauses of ST_Panose. Would this suffice? The standard doesn't currently contain a normative reference to HP's specification.
* I have changed the first "guidance" section showing the Panose regexes to be a Note instead as I think this is better suited to being a note.
* I have abbreviated some of the text in the guidance list, just to improve readability.
* I've removed mention of schema changes (I agree with you that there shouldn't be any).

If you agree with my edits, then I think this means we should be able to close this DR in Berlin.

Chris

-----Original Message-----
From: suzuki toshiya [mailto:mpsuzuki at hiroshima-u.ac.jp] 
Sent: 12 June 2011 17:20
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,

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 proposed changes.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 56271 bytes
Desc: DR 09-0061 proposed changes.docx
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20110613/ac75fa81/attachment-0001.bin>