proposal of non-normative regex and text for DR 09-0061, ST_Panose issue
Chris.Rae at microsoft.com
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.
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
Here is my revised text.
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.
> suzuki toshiya, Hiroshima University, Japan
> 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,
>> -----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 ?
>> 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?
>>> -----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.
>>> suzuki toshiya, Hiroshima University
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DR 09-0061 proposed changes.docx
Size: 56271 bytes
Desc: DR 09-0061 proposed changes.docx
More information about the sc34wg4