[sc34wg4] Re: COR3 issue: ST_PitchFamily

Fri Oct 2 01:01:20 CEST 2015

(Re-adding the group as I’ve ended up with a summary of all the changes for DR 09-0055 arising from the reconsideration of 09-0037 and 09-0055 and from the discussions in e-mail and at the Beijing meeting.)

Were both 0037 and 0055 originally closed in COR2?  I thought 0055 was in COR3 but I could be wrong and the doc has already been updated to Status: Further Consideration Required.  If it was for COR3, then 0055 simply needs to be re-applied after 0037 is applied (reinstating the deleted attributes).  If it was for COR2, 0055 probably needs to be re-opened and re-applied.  29500-1:2012 does not have prose for the new ST created by 0055, but it does exist in the printed schema (A.4.1), so maybe it was from COR2.  All the other changes 0055 made are non-existent because it edited attributes that 0037 deleted.  In Part 1.

For Part 4, 0055 only mentions changes to schema adding ST_PitchFamily, but not to 16.5.3 Changed attribute for font element (Part 1, 19.2.1.13) which has the full listing of values in the pitchFamily attribute and still says it's of type xsd:byte (even though the schema says it's of type ST_PitchFamily).  Fortunately, there are no other pitchFamily occurrences in Part 4.

So, what I think needs to happen is:

·         First apply revised changes for 0037

o   Reinstate the three attributes in 19.2.1.13 font, one of which is pitchFamily

o   See “DR 09-0037 redux.docx” attached to my mail in this thread from 24 Sept 2015

·         Then apply revised changes for 0055:

o   Part 1: add prose for ST_PitchFamily

o   Part 1: ensure ST_PitchFamily exists in digital and printed XSD and RNG

o   Part 1: ensure schema for CT_TextFont at pitchFamily in A.4.1 points to ST_PitchFamily

o   Part 1: edit text of pitchFamily attributes to point to ST_PitchFamily in: 19.2.1.13 font, 21.1.2.3.1 cs, 21.1.2.3.3 ea, 21.1.2.3.7 latin, 21.1.2.3.10 sym, 21.1.2.4.6 buFont

o   Part 4: ensure ST_PitchFamily exists in digital and printed XSD and RNG

o   Part 4: ensure schema for CT_TextFont at pitchFamily in A.4.1 points to ST_PitchFamily

o   Part 4: edit text of pitchFamily attribute in 16.5.3 to make the same changes as in Part 1

I have attached a full write-up of the DR 09-0055 changes.  This assumes none of the original 0055 changes had been partially made to 29500-1,-4:2012.  While changes will be made against the 2012 edition, and that has partial changes, I think it’s best for clarity and for the historical record to list the entire set of expected changes.

You added a new block of text to the DR log for 0055 titled “2015-09-21/24 Beijing Meeting:” which discussed both 0037 and 0055.  Not sure how to want to alter that so both DRs reference each other.  Most of the e-mail discussion pasted in there is more relevant to 0037.  If you decide to paste in the contents of the attached DR 09-0055 changes v4.docx, then it’s going to largely duplicate (though with minor tweaks) many pages of pasted proposed resolution.  Maybe that’s OK, just FYI.

John

-----Original Message-----
From: Rex Jaeschke [mailto:rex at RexJaeschke.com]
Sent: Thursday, October 1, 2015 10:05 AM
To: John Haug <johnhaug at exchange.microsoft.com>
Subject: RE: [sc34wg4] Re: COR3 issue: ST_PitchFamily

I'm confused John, but maybe it's just the jetlag. (BTW, my flight back on Sunday was recalled to PEK after an hour due to mechanical problems, and then was cancelled, so I spent 24 hours at the airport and hotel nearby.)

Based on what I wrote in the minutes for ST_PitchFamily, I was expecting a proposal for 09-0055, but your attachment was for 09-0037. On reading the email thread on this subject, I now see 09-0037 mentioned, so that's okay.

If I understand correctly, 09-0037 and 09-0055 were both resolved in COR2, which was folded into 29500:2012. They were NOT part of the recent COR3.

In COR3B (the new COR), it seems that your 09-0037 redux file should completely undo what the old 09-0037; correct?

What about the old 09-0055? I don’t see any new text to undo the impact of that. As discussed in recent mails, “none of the edits proposed in DR 09-0055 after the heading “2011-06-03 Chris Rae:” and before the heading “2011-06-20/22 Berlin Meeting:” were incorporated into COR2, so were not integrated into the resulting new standard edition.” Should they be?

What should I be doing with 09-0055?

Rex

-----Original Message-----

From: John Haug [mailto:johnhaug at exchange.microsoft.com]

Sent: Thursday, September 24, 2015 4:44 AM

To: suzuki toshiya <mpsuzuki at hiroshima-u.ac.jp<mailto:mpsuzuki at hiroshima-u.ac.jp>>; SC 34 WG4 <e-SC34-WG4 at ecma-international.org<mailto:e-SC34-WG4 at ecma-international.org>>

Subject: RE: [sc34wg4] Re: COR3 issue: ST_PitchFamily

Keeping this in the existing e-mail thread.  I've attached the final text we arrived at during the face-to-face meeting in Beijing.  In short, it was agreed that any ambiguity or differences between attribute values in the two elements (referring and referred, as described in the original DR) are a degenerate case and left to implementations to take the best action they can for their context.

John

-----Original Message-----

From: suzuki toshiya [mailto:mpsuzuki at hiroshima-u.ac.jp]

Sent: Wednesday, September 23, 2015 9:29 AM

To: SC 34 WG4 <e-SC34-WG4 at ecma-international.org<mailto:e-SC34-WG4 at ecma-international.org>>

Cc: John Haug <johnhaug at exchange.microsoft.com<mailto:johnhaug at exchange.microsoft.com>>

Subject: Re: [sc34wg4] Re: COR3 issue: ST_PitchFamily

Hi,

In today's meeting, there was a suggestion to check whether the different coverage of the optional attributes of CT_TextFont (charset/panose/pitchFamily) has any impacts in resolving the embedded font resource.

I made a set of testing files, and tested with MS Office

2010 and 2013 on Microsoft Windows. I attached my testing files in 7z archive format - if you want me to upload some sites, please let me know.

The results could be summarized very simply, the different coverage of the attributes has no impact in Microsoft Office 2010 and 2013. The tested files are:

01) referring & referred parts have charset only

02) referring & referred parts have panose only

03) referring & referred parts have pitchFamily only

04) referring & referred parts have charset+panose

05) referring & referred parts have panose+pitchFamily

06) referring & referred parts have charset+pitchFamily

07) referring parts have charset, referred part has panose+pitchFamily

08) referring parts have panose, referred part has charset+pitchFamily

09) referring parts have pitchFamily, referred part has charset+panose

10) referring parts have charset+panose, referred part has pitchFamily

11) referring parts have panose+pitchFamily, referred part has charset

12) referring parts have charset+pitchFamily, referred part has panose

13) referring & referred parts have no charset, panose nor pitchFamily

None of them caused the warning dialogue. So, I think "different coverage of the optional attributes; charset/ panose/pitchFamily" is not the "inconsistent attribute".

--

In addition, I tried to check the relationship between OS/2 table's supported codepage coverage and "charset" attribute.

I expected that "charset" attribute should be one of the supported codepages declared in ulCodePageRange in OS/2 table of TrueType:

http://www.microsoft.com/typography/otspec/os2.htm#cpr

Modern Turkish is written by Latin script, so, Century and Arial raise "Turkish" bit on, in OS/2 table. However, if I set "charset" attribute to 161 (=Turkish), Office2010 complains some resources in the document could not be opened. From this result, it is not easy to describe how the charset is determined from the given font bitstream. Some people may want further clarification, but it would be long way (more experiments are

needed) and should not be dealt as a part of DR 09-0037.

Regards,

suzuki toshiya, Hiroshima University, Japan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20151001/c01517c7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DR 09-0055 changes v4.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 75880 bytes
Desc: DR 09-0055 changes v4.docx
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20151001/c01517c7/attachment-0001.docx>