[sc34wg4] Re: COR3 issue: ST_PitchFamily

Thu Sep 10 03:05:21 CEST 2015

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 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
>>
> 
> 
> 