COR3 issue: ST_PitchFamily

Thu Sep 10 02:45:51 CEST 2015

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
>

-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20150910/6f5f0e72/attachment-0001.html>