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

[suzuki toshiya]

Dear Chris,

Thank you for correction, the corrected text is acceptable for me.

The last problem is that "ISO/IEC 14496-22:2007 (so-called ISO
spec for OpenType) is appropriate reference for Panose?".

ISO/IEC 14496-22:2007 does not refer Panose spec in its normative
reference (14496-22:2009 is same). But ISO/IEC 14496 does not
define their own valid ranges for each byte, so referring ISO/IEC
14496 as indirect reference to Panose is acceptable solution,
because:
* it shows the correct pointer to genuine Panose spec.
* it includes no information causing misunderstanding about
  the valid value range of Panose.

Anyway, now I think, this insufficiency (lack of the definition
of genuine/valid Panose in ISO spec or the normative references
in ISO spec) should be worked by the side of ISO/IEC 14496-22,
for first. The permission to refer genuine Panose should be discussed
with HP and MonoType, and the project editor of 14496-22 (from MonoType)
is the most appropriate person.

Regards,
suzuki toshiya, Hiroshima University, Japan

Chris Rae wrote:
> 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
>>>>