[sc34wg4] Re: COR3 issue: ST_PitchFamily
suzuki toshiya
mpsuzuki at hiroshima-u.ac.jp
Sat Sep 19 05:26:49 CEST 2015
Dear John,
> Oh, my test is still insufficient; Century and Century Gothic
> have same "charset". I will do yet another experiment.
The results of my preliminary experiments for mismatched charset
seem to be complicated than mismatched panose/pitchFamily:
-----------------------------------------------------------------
Experiment 1)
charsets of all referring parts are changed from "0" (ANSI)
to "177" (Hebrew), but charsets in embeddedfontlist are left
as "0".
--> a dialog is shown "PowerPoint found a problem with content
in <filename>, PowerPoint can attempt to repair the presentation"
-----------------------------------------------------------------
Experiment 2)
charsets of all referring parts and embeddedfontlist are
changed from "0" (ANSI) to "177" (Hebrew).
--> a dialog is shown "PowerPoint found a problem with content
in <filename>, PowerPoint can attempt to repair the presentation"
-----------------------------------------------------------------
There is a possibility that mismatched-charset is seriously
handled than mismatched-panose and mismatched-pitchFamily.
In addition, there is a possibility that existing implementation
checks the mismatch between charset declared by embeddedFontLst
and the embedded binary data.
I think a note to encourage the consistency of charsets among
the referring XML, referred XML and embedded font data would
be safer, if it can cause visible warning in the existing
implementation.
Regards,
mpsuzuki
suzuki toshiya wrote:
> Dear John,
>
> Thank you for comment, just I made a preliminary testing PPTX.
>
> a) a PPTX made by PowerPoint 2010, Title uses Century Gothic, Text uses
> Century
>
> b) a PPTX with a "broken" embeddedFontLst, whose
> panose/pitchFamily/charset are exchanged;
> * "Century Gothic" entry keeps its name and its reference to embedded
> font stream,
> but its panose/pitchFamily/charset are replaced by those in original
> "Century" entry.
> * "Century" entry keeps its name and its reference to embedded font stream,
> but its panose/pitchFamily/charset are replaced by those in original
> "Century Gothic" entry.
>
> c) a PPTX with "broken" font referrers, whose familyname "Century
> Gothic" and
> "Century" in slideMaster1.xml and slideLayout2.xml are exchanged.
>
> Opening them by PowerPoint 2010, the results I see are:
> b) looks same with a)
> c) looks differently, uses "Century" on the title, and "Century Gothic"
> on the text.
>
> According to this result, the font familyname matching seems
> to be sufficient to identify an embedded font resource, and
> the different panose/pitchFamily might not have serious impact.
>
> Oh, my test is still insufficient; Century and Century Gothic
> have same "charset". I will do yet another experiment.
>
> Regards,
> mpsuzuki
>
> John Haug wrote:
>> 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
>>>>>
>>>>
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: office2010-broken-charset-in-all-xml.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 1771785 bytes
Desc: not available
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20150919/0fc2703d/attachment-0002.pptx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: office2010-century-charset-different-from-embeddedfont.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 1771802 bytes
Desc: not available
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20150919/0fc2703d/attachment-0003.pptx>
More information about the sc34wg4
mailing list