[sc34wg4] Re: COR3 issue: ST_PitchFamily
John Haug
johnhaug at exchange.microsoft.com
Sat Sep 19 00:28:09 CEST 2015
Thank you for thinking about these issues again after so many years!
DR 09-0037
To ensure I'm looking at the same markup you are, do you mean there is potential confusion/conflict between a "font" element under the "embeddedFont" element in the presentation part and a font element ("latin", "ea", "cs", "sym") under a run properties element ("rPr", "endParaRPr") in a slide part?
Presentation part:
<p:embeddedFont>
<p:font typeface="Abadi MT Condensed" panose="020B0506030101010103" pitchFamily="34" charset="0"/>
<p:regular r:id="rId5"/>
</p:embeddedFont>
Slide part:
<a:rPr lang="en-US" dirty="0" smtClean="0">
<a:latin typeface="Abadi MT Condensed" panose="020B0506030101010103" pitchFamily="34" charset="0"/>
</a:rPr>
My initial thought is the same as your conclusion - the font in the rPr is not the same as the embedded font. But since the description for the charset and pitchFamily attributes of the latin/ea/cs/sym elements says those values may be used for font substitution, you raise a good question about whether they should be considered when determining whether the rPr font is the same as the embedded font. I will request an interpretation from the developers here.
DR 09-0055
My understanding of this DR is simply to enforce the list currently in prose instead by schema. I have no concern with this.
I'll move the hint="cs" discussion over to the separate e-mail thread about that topic.
Thanks,
John
-----Original Message-----
From: suzuki toshiya [mailto:mpsuzuki at hiroshima-u.ac.jp]
Sent: Sunday, September 13, 2015 11:50 PM
To: John Haug <johnhaug at exchange.microsoft.com>
Cc: MURATA Makoto <eb2m-mrt at asahi-net.or.jp>; SC 34 WG4 <e-SC34-WG4 at ecma-international.org>
Subject: Re: [sc34wg4] Re: COR3 issue: ST_PitchFamily
Dear John and Murata-san,
Here are my positions about DR 09-0037, 0040, 0055.
DR 09-0037
----------
The embeddedFont is an interface element to the embedded font; it has the attributes "charset", "panose" and "pitchFamily". But the font referrer in DrawngML (for example) can specify them independently.
Please think about a document with an embedded font; named "Arial", charset=ANSI, panose=020b0604020202020204, pitchFamily=Swiss/Variable.
If DrawingML tries to use a font named "Arial" but charset=Symbol && pitchFamily=Roman/Fixed, how the implementation should handle the request?
The implementation should take the requested font is not the embedded font even if the family name is same?
Or, as the referrer's attributes are described as the attributes for fallback, the family name matching is already sufficient to use the embedded "Arial"?
Considering that existing implementation write these attributes, I have no objection to these attributes in the specification as far as "how the implementation should use the values" is clarified.
DR 09-0040
----------
The "hint" attribute can take "cs" (complex script) for font slot selection?
The reason why "cs" was to be removed is following; By default, the font slot (from ansi/hansi/ea/cs) is selected by the codepoint of the character to be rendered.
Also it is forcibly changed by w:cs or w:rtl elements.
The default slot selection by the codepoint is sometimes not unique but configurable (e.g. the ellipsis is rendered by for ascii slot by default, but it could be changed to ea slot, by setting hint to ea). For such configurable cases, the codepoint-to-slot table have special descriptions like "use X slot, but if hint is set to Y, Y slot is used".
We should be careful that the hint does not change everything, but changes configurable parts.
At present, the codepoint-to-slot table has no character that cs slot is used by default, or, cs slot could be used by setting hint appropriately. If the table is correct, I'm suspicious if setting hint to cs has any effect.
I think this was background why cs would be removed from the possible values of hint.
There would be a few rationales to permit "cs" value in hint;
a) the table was incorrect; some codepoints could be configured to use cs font slot, by setting hint to cs.
b) setting hint to cs makes everything rendered by cs font slot, as w:cs and w:rtl.
c) setting hint to cs does nothing, but the values should be permitted because existing implementation could write it (dealing them as "invalid" is problematic).
I think any of above 3 rationales would be reasonable to permit "cs" in hint, however, "what would occur by setting hint to cs" should be clarified.
DR 09-0055
----------
As far as I check the discussion, there is no rationale to keep current loose type definition for ST_PitchFamily. I suggest to use clearer type defined by Murata-sensei.
Regards,
mpsuzuki
John Haug wrote:
> 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
>>>
>>
>>
More information about the sc34wg4
mailing list