COR3 issue: ST_Hint

Sun Oct 4 10:44:21 CEST 2015

Shouldn't we say why "cs" was kept altough it never appears in the
table in Part 1, §17.3.2.26, “rFonts (Run Fonts)”?  Just like us, users
will be confused.

Regards,
Makoto

2015-10-04 17:20 GMT+09:00 MURATA Makoto <eb2m-mrt at asahi-net.or.jp>:

> I think that we should mention U+2026
> <http://www.fileformat.info/info/unicode/char/2026/index.htm> (Ellipsis).
> This is a very important use
> case for Japanese users of the hint attribute.
>
> https://en.wikipedia.org/wiki/Ellipsis
>
> Regards,
> Makoto
>
>
> 2015-10-01 9:32 GMT+09:00 John Haug <johnhaug at exchange.microsoft.com>:
>
>> I edited the doc as suggested, though rather than saying (only) for
>> characters which are not explicitly stored… I made it less specific.  I
>> believe someone said there are some printable characters that could map to
>> different font slots.  Attached.  How does that work?
>>
>>
>>
>> John
>>
>>
>>
>> -----Original Message-----
>> From: suzuki toshiya [mailto:mpsuzuki at hiroshima-u.ac.jp]
>> Sent: Thursday, September 24, 2015 4:33 AM
>> To: Arms, Caroline <caar at loc.gov>
>> 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_Hint
>>
>>
>>
>> I have no problem with the proposed improvement of the text.
>>
>>
>>
>> Regards,
>>
>> mpsuzuki
>>
>>
>> * ------------------------------ *
>>
>> *From:* Arms, Caroline [mailto:caar at loc.gov]
>> *Sent:* Thursday, September 24, 2015 3:20 AM
>> *To:* John Haug <johnhaug at exchange.microsoft.com>; SC 34 WG4 <
>> e-SC34-WG4 at ecma-international.org>; suzuki toshiya <
>> mpsuzuki at hiroshima-u.ac.jp>
>>
>> *Subject:* RE: COR3 issue: ST_Hint
>>
>>
>>
>> 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
>> <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
>> <johnhaug at exchange.microsoft.com>]
>> *Sent:* Friday, September 18, 2015 3:28 PM
>> *To:* SC 34 WG4 <e-SC34-WG4 at ecma-international.org>; suzuki toshiya <
>> 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
>> <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
>> <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_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.
>>
>
>
>
> --
>
> Praying for the victims of the Japan Tohoku earthquake
>
> Makoto
>

-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20151004/7849dff0/attachment-0001.html>