COR3 issue: ST_Hint

[John Haug]

Suzuki-san offered these comments on DR 09-0040 along with others in another e-mail:

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.


I can confirm after talking with a developer here that Word will write hint="cs" and that it appears only to be used when Word writes list formatting in HTML output.  So, hopefully we can agree to keep the attribute value and we are all correct that it has no effect on the giant table added to 17.3.2.26 rFonts by this DR.  Assuming there are no other concerns, we should take a little time to tweak the text on the cs description (and possibly reflect the same in eastAsia) to sound less directive since the actions implementers are to take are defined well in the table added to 17.3.2.26.

Thanks for the analysis, Suzuki-san!

John

From: John Haug [mailto:johnhaug at exchange.microsoft.com]
Sent: Wednesday, September 9, 2015 4:06 PM
To: 'SC 34 WG4' <e-SC34-WG4 at ecma-international.org>
Subject: RE: COR3 issue: ST_Hint

We discussed this on the last teleconference.  Nobody remembered the details behind this and some old e-mail dug up by Murata-san and Caroline didn't show a specific decision or reason.  Chris and I looked through a trove of public files we have access to and "cs" does appear in some.  I think the right resolution here is to keep "cs".

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<mailto:e-SC34-WG4 at ecma-international.org>>
Subject: COR3 issue: ST_Hint

Background: E-mail "Leftover from DR 09-0040" (latest reply 2015-08-03)

Summary:
ST_Hint (DR 09-0040)

*         DR removed "cs" value

*         --> Murata-san to remove "cs" from schemas

*         ** Only the value "default" remains; where did "eastAsia" get removed?  DR 09-0040 adds lots of text referring to "cs" and "eastAsia" values of the hint attribute for some CTs, which is of type ST_Hint.  DR 09-0040 is therefore internally inconsistent and should not be applied as is.  I haven't yet rediscovered why ST_Hint had items removed.
Rex> I just checked MM's mail, "Leftover from DR 09-0040" of 2015-08-02, and his proposed schema fix only removes cs; eastAsia is still there.

However, on close inspection, the way the Enumeration Value table is written in the COR (see entry #81) is that this is the complete table. As eastAsian was never intended to be removed, I should have shown an empty row after the default row, containing ..., indicating that the remainder of the table stays as is. And even though the COR didn't contain that ..., when I applied the COR to 2012, I did NOT remove eastAsian, 'cos there was no delete (strike-through in red) instruction in the COR to do so.

Regarding, "DR 09-0040 adds lots of text referring to "cs" and "eastAsia" values of the hint attribute for some CTs, which is of type ST_Hint.  DR 09-0040 is therefore internally inconsistent and should not be applied as is", I see there is a cs element APART from the cs enumeration value in ST_Hint. (I also see that eastAsia is also an attribute name as well as an enum value.)

I think this needs to be looked at to determine whether the cs attribute value should be removed and to confirm whether eastAsia was to be removed (and if so whether it ought to).  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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20150918/ecf6ea28/attachment-0001.html>