[sc34wg4] Re: COR3 issue: ST_PitchFamily

Thu Sep 10 20:49:37 CEST 2015

I'd probably suggest the first of the two options Shawn suggested back then - the one that wasn't chosen.

John

-----Original Message-----
From: suzuki toshiya [mailto:mpsuzuki at hiroshima-u.ac.jp] 
Sent: Wednesday, September 9, 2015 6:05 PM
To: MURATA Makoto <eb2m-mrt at asahi-net.or.jp>
Cc: John Haug <johnhaug at exchange.microsoft.com>; SC 34 WG4 <e-SC34-WG4 at ecma-international.org>
Subject: Re: [sc34wg4] Re: COR3 issue: ST_PitchFamily

Sorry for my lated response to ST_PitchFamily and ST_Hint issues.
I will be able to post my position on next Monday.

Regards,
suzuki toshiya, Hiroshima University, Japan

MURATA Makoto wrote:
> I don't think that we need a new DR.  We only have to reopen DR 
> 09-0037 and add a new solution.  John, could you propose  a  solution?
> 
> FYI: Suzuki-san is aware of the issues,  and is going to study them.
> 
> Regards,
> Makoto
> 
> 2015-09-10 8:03 GMT+09:00 John Haug <johnhaug at exchange.microsoft.com>:
> 
>> After digging into this, it seems DR 09-0037 may have been resolved 
>> incorrectly – implementations do write out those attributes.  The 
>> correct resolution seems to be the other option from that old e-mail.  
>> Which would leave the attributes in CT_TextFont (technically, re-add 
>> them) and DR
>> 09-0055 can be applied as we planned and approved.  Shall I file a DR 
>> to change 09-0037, assuming we can incorporate that (and 09-0055) 
>> into the pending COR3b?
>>
>>
>>
>> John
>>
>>
>>
>> *From:* John Haug [mailto:johnhaug at exchange.microsoft.com]
>> *Sent:* Friday, August 14, 2015 2:52 PM
>> *To:* 'SC 34 WG4' <e-SC34-WG4 at ecma-international.org>
>> *Subject:* COR3 issue: ST_PitchFamily
>>
>>
>>
>> Background: E-mail “A second COR for 29500-1 and the type 
>> ST_PitchFamily in DML” forwarded below
>>
>> Background: E-mail “ST_PitchFamily in dml-main.xsd” (latest reply
>> 2015-07-12)
>>
>>
>>
>> Summary:
>>
>> ·         DR 09-0055: CT_TextFont at pitchFamily changed to be of new type
>> ST_PitchFamily (missing in DCOR)
>>
>> ·         DR 09-0037 already removed CT_TextFont at charset
>> /panose/pitchFamily
>>
>> ·         --> Proposed: back out DR 09-0055, re-open it, look at it from
>> scratch
>>
>> ·         ** Why was 09-0037 resolved as it was? ("Reviewed Shawn’s email
>> of 2010-03-18. We chose Choice 2, “Remove the attributes from the 
>> standard”." The e-mail is the same as in the DR log from 2009-06-17.)
>>
>> Rex> Yes it looks like we need to reconsider these, and as MM 
>> Rex> suggested in
>> his mail, “Re: A second COR for 29500-1 and the type ST_PitchFamily 
>> in DML”, on 2015-07-30 [JH: Forwarded below], we NOT include this in 
>> the 2nd COR, but rather take our time and fix it next time around. I 
>> suggest making a new DR that points to these two.
>>
>>
>>
>> I think these two DRs need to be looked at together to come to a 
>> final conclusion.  Because there is such a significant amount of text 
>> changed here, I think publishing as is would be a problem and that we 
>> should correct this before the Beijing meeting so the new DCOR ballot 
>> (COR3b?) will have it.
>>
>>
>>
>> *From:* eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com 
>> <eb2mmrt at gmail.com>] *On Behalf Of *MURATA Makoto
>> *Sent:* Thursday, July 30, 2015 2:58 PM
>> *To:* Rex Jaeschke <rex at rexjaeschke.com>
>> *Cc:* John Haug <johnhaug at exchange.microsoft.com>; MURATA Makoto 
>> (FAMILY
>> Given) <eb2m-mrt at asahi-net.or.jp>
>> *Subject:* Re: A second COR for 29500-1 and the type ST_PitchFamily 
>> in DML
>>
>>
>>
>> Although I agree that we should revise CT_EmbeddedFontListEntry
>>
>> and introduce a type (CT_EmbeddedTextFont) without the three
>>
>> attributes, I do not think that this change is a must for this
>>
>> consolidation.  It is not very difficult to address this defect, but
>>
>> if we start to incorporate not-so-difficult DRs as part of the
>>
>> new COR for the remedy, we will run the risk of delaying it and the 
>> consolidated text for months.
>>
>> Regards,
>>
>> Makoto
>>
>>
>>
>> 2015-07-31 0:07 GMT+09:00 Rex Jaeschke <rex at rexjaeschke.com>:
>>
>> Yes, the changes proposed in DR 09-0037 went into COR2 and 29500:2012.
>>
>>
>>
>> John, if you agree that we have a conflict between 09-0037 and 
>> 09-0055, I’ll re-post this thread to the committee and create a new 
>> DR for it. In that case, should we delay a new COR for resolution of 
>> this? After all, it is not related to the recent COR and consolidation.
>>
>>
>>
>> Rex
>>
>>
>>
>> *From:* eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] *On Behalf Of 
>> *MURATA Makoto
>> *Sent:* Thursday, July 30, 2015 2:10 AM
>> *To:* Rex Jaeschke <rex at rexjaeschke.com>
>> *Subject:* Re: A second COR for 29500-1 and the type ST_PitchFamily 
>> in DML
>>
>>
>>
>> Ouch!
>>
>>
>>
>> I think that  DR 09-0037 should have introduced a new complex type,
>>
>> say CT_EmbeddedTextFont, to dml-main.xsd.   Its definition should be:
>>
>>
>>
>>   <xsd:complexType name="CT_EmbeddedTextFont">
>>
>>     <xsd:attribute name="typeface" type="ST_TextTypeface" 
>> use="required"/>
>>
>>   </xsd:complexType>
>>
>>
>>
>> This complex type should be used only for 19.2.1.13  font (Embedded 
>> Font
>> Name) .
>>
>>
>>
>>   <xsd:complexType name="CT_EmbeddedFontListEntry">
>>
>>     <xsd:sequence>
>>
>>       <xsd:element name="font" type="a:CT_EmbeddedTextFont" minOccurs="1"
>> maxOccurs="1"/>
>>
>> ...
>>
>>
>>
>> Then, no other elements will be affected by this change.
>>
>>
>>
>> Yes, we have to revise 19.2.1.13  font (Embedded Font Name)  
>> significantly.
>> Are the changes in DR 09-0037  incorporated now?
>>
>>
>>
>> Regards,
>>
>> Makoto
>>
>>
>>
>>
>>
>> 2015-07-30 5:23 GMT+09:00 Rex Jaeschke <rex at rexjaeschke.com>:
>>
>> [I’m starting off with just the 3 of us. If/when we make progress, 
>> I’ll post to the whole of WG4.]
>>
>>
>>
>> One of the issues Murata-san raised recently (See issue Category 2a 
>> from the teleconference minutes of 2015-07-28.) was the fact that the 
>> definition of the new type we added way back, ST_PitchFamily, did not 
>> have a formal description in the Simple Types clause. This was 
>> supposedly resolved in DR 09-0055. When I first had a detailed look 
>> at that DR, I found that quite a lot of text that WG4 probably (I 
>> can’t be certain) agreed to, didn’t make it into the COR and subsequent consolidated reprint.
>>
>>
>>
>> Today, I started creating a new DR to fix any errors that occurred in 
>> processing DR 09-0055. Unfortunately, this looks like it has led to a 
>> larger problem.
>>
>>
>>
>> We adopted the resolution to DR 09-0055 at the Berlin Meeting on 
>> 2011-06-20/22.
>>
>>
>>
>> That resolution added the schema for the new type, ST_PitchFamily, 
>> and changed CT_TextFont to refer to that new type. This occurred for 
>> both Parts
>> 1 and 4. However, the narrative definition of the type was NOT added, 
>> even though it existed in the earlier part of the DR log. Clearly, 
>> that seems wrong; if we added the schema for a new simple type, we 
>> should have added the corresponding text to describe it.
>>
>>
>>
>> Separately, 15 months earlier, at the Stockholm meeting on 
>> 2010-03-23/25, we closed out DR 09-0037, which involved REMOVING the 
>> following attributes from CT_TextFont: charset, panose and 
>> pitchFamily. These removals are reflected in the resulting COR and 
>> the following consolidated reprint, 29500-2012. However, if the 
>> pitchFamily attribute no longer existed, it couldn’t be changed by DR 
>> 09-0055. But if we remove these changes from DR 09-0055, the only 
>> changes left are to define the new type’s schema, but never to refer 
>> to it anywhere in the schema, which sounds very strange, indeed.
>>
>>
>>
>> Looking at DR 09-0037 further, although we agreed to remove the 3 
>> attributes, the resolution and resulting COR did NOT actually remove 
>> them from the schema definition for that type. It seems to me that 
>> they should have. Also, a number of other types contain elements of 
>> type CT_TextFont, yet 09-0037 didn’t say to remove those 3 attributes 
>> from them (see §21.1.2.3.x for cs, ea, latin, sym, and buFont). Also, 
>> even after the attributes were removed from the narrative in 
>> 19.2.1.13 font (Embedded Font Name), an example remains there that 
>> uses the attributes pitchFamily and charset, which were removed!
>>
>>
>>
>> Bottom line, in the unused proposal text of DR 09-0055, attribute 
>> pitchFamily was to be greatly simplified with a pointer made to the 
>> new type ST_PitchFamily. Yet, DR 05-0037 said to remove this 
>> attribute altogether. All the other edits in the unused proposal of 
>> DR 09-0055 refer exactly to the descriptions of the same attribute 
>> (pitchFamily) in the cs, ea, latin, sym, and buFont elements 
>> mentioned earlier. So it seems that all the proposed text (both used 
>> and unused) hits all the related places in the spec.
>>
>>
>>
>> It is clear that the resolutions we can imply from what was recorded 
>> in DRs 09-0037 and 09-0055 can’t coexist, as they are contradictory. 
>> If we adopt the supposedly omitted text from 09-0055, we contradict 
>> the intent of 09-0037.
>>
>>
>>
>> Maybe the solution is simple: adopt option 1 from DR 09-0037 instead 
>> of Option 2, massaging it to accommodate DR 09-0055’s complete proposal.
>>
>>
>>
>> Rex
>>
>>
>>
>>
>>
>>
>> --
>>
>>
>> Praying for the victims of the Japan Tohoku earthquake
>>
>> Makoto
>>
>>
>>
>>
>>
>> --
>>
>>
>> Praying for the victims of the Japan Tohoku earthquake
>>
>> Makoto
>>
> 
> 
> 