[sc34wg4] RE: COR3 issue: ST_Hint

[suzuki toshiya]

I have no problem with the proposed improvement of the text.

Regards,
mpsuzuki

Arms, Caroline wrote:
> John,
> 
>  
> 
>  From a grammatical viewpoint, I certainly don’t like “multiple of 
> the”.  What about “more than one of the”?
> 
>  
> 
> I found the paragraph beginning ”There are” rather hard to grasp.  I 
> really needed to read the Note to understand it.  The dogmatic “There 
> are” seemed odd.   And “arbitrate that conflict” and “determine how 
> ambiguities in this run shall be handled” seem to be saying the same thing.
> 
>  
> 
> Would there be any problem with:
> 
>  
> 
> For characters which are not explicitly stored in the document, and 
> which can be mapped into more than one of the font slot categories 
> described in the parent element, this attribute shall be used to 
> determine how ambiguities in this run shall be handled.
> 
>  
> 
>     Just a thought.
> 
>  
> 
>     Caroline
> 
>  
> 
>  
> 
> Caroline Arms
> 
> Library of Congress Contractor
> 
> Co-compiler of Sustainability of Digital Formats resource    
> http://www.digitalpreservation.gov/formats/
> 
>  
> 
> ** Views expressed are personal and not necessarily those of the 
> institution **
> 
>  
> 
> *From:* John Haug [mailto:johnhaug at exchange.microsoft.com]
> *Sent:* Thursday, September 24, 2015 4:44 AM
> *To:* SC 34 WG4; suzuki toshiya
> *Subject:* RE: COR3 issue: ST_Hint
> 
>  
> 
> 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, I modified the descriptive text to make it less proscriptive and 
> more indicative that the values of the attributes are an indicator that 
> only has meaning when taken within the context of the parent element 
> containing the attribute using this simple type.
> 
>  
> 
> John
> 
>  
> 
> *From:* John Haug [mailto:johnhaug at exchange.microsoft.com]
> *Sent:* Friday, September 18, 2015 3:28 PM
> *To:* SC 34 WG4 <e-SC34-WG4 at ecma-international.org 
> <mailto:e-SC34-WG4 at ecma-international.org>>; suzuki toshiya 
> <mpsuzuki at hiroshima-u.ac.jp <mailto:mpsuzuki at hiroshima-u.ac.jp>>
> *Subject:* RE: COR3 issue: ST_Hint
> 
>  
> 
> 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 
> <mailto: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.
>