[sc34wg4] Re: COR3 issue: ST_PitchFamily
suzuki toshiya
mpsuzuki at hiroshima-u.ac.jp
Mon Sep 14 08:50:27 CEST 2015
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