Meeting minutes
<fantasai> https://
<fantasai> https://
fantasai: for Specify width of autospace gaps , do we need multiple controls or do we need one?
… i think we need one
… just want to confirm
florian: makes sense
… punctuation works differently
xfq: I'm inclined to think we need one
… will confirm with the i18n group
<fantasai> Proposal: only one control needed, would apply to all values except 'punctuation' (which would not be controlled by it)
florian: are you talking about ideograph-alpha and ideograph-numeric
… or is there any other thing?
fantasai: ideograph-alpha and ideograph-numeric
florian: some very picky people might insist that they want slightly bigger spacing
… I can't say I couldn't imagine anyone wondering about this
… no need to do things excessively
… it would be good to see if any lreq people think otherwise
text-spacing - what do we copy?
[css-text-4] text-autospace: what gets copied?
<fantasai> gtihub: w3c/
<fantasai> github: w3c/
fantasai: open question
… I have my own take on the issue
… would be good to hear your opinions
florian: it's probably true you want the punctuation to be copied
… maybe you do want to keep the U+20 removed by 'replace' for ideograph-alpha or numericbecause the spacing will not remain otherwise
<fantasai> xfq_: I think the inter-script spacing is a kind of styling
<fantasai> ... and it should not be copied
fantasai: some text might have U+0020 spaces and some text might not have U+0020 spaces
… we have insert and replace keywords
… when we copy the text do we copy whatever in the source, or do we remove the spacing
xfq_: for clreq's documents, the editors decided not to add any inter-script spacing intentionally
… not using U+20, because it's styling, should not be added as a space
… also supplementary materials etc.
… there were some ppl outside the group who thought space should be added
florian: we could look at PDF output of high-quality engines, to see what they do?
… maybe people have thought about this before
xfq_: width of U+20 is dependent on font
florian: yes, and generally too big
fantasai: could ask Murakami-san?
florian: also Nat McCully
florian: for French it's pretty much always a correction, so keeping the corrected output seems reasonable, for CJK it might be different
text-spacing: trim-all
<florian> w3c/
florian: for those who haven't looked at the interesting comment in another thread that gives more details it's this one ^
… I kind of agree to your opening comment
florian: can we ask Unicode to add half-width variants of commas and middle dots, or is it unrealistic?
fantasai: do we need a <num> tag in HTML?
fantasai: this is also a plain text problem
florian: all these CJ punctuations should never have the space baked in them
fantasai: this is the problem
https://
https://
florian: CSS is the easiest place to introduce it, but maybe not the correct place to introduce it
fantasai: VS 1 for western style and VS 2 for east asian style
… VS1 for left-aligned and VS2 for centered
… we don't have a way to indicate half-width in a consistent way
… we need to start a discussion with Ken Lunde also
… should we start an email thread for that purpose?
public-i18n-core
Ken Lunde
Murakami-san
fantasai + florian
Nat McCully
florian: do we also want to involve any browser implementer people?
Jonathan Kew
Myles Maxfield
Koji Ishii
Behdad Esfabod?
fantasai: we should probably do whatever is implemented in the Adobe fonts, even though the way Ken set up the VS selectors is inconsistent
… if VS is adopted and not all fonts implement this
… should the browsers compensate this somehow
xfq_: It's more difficult to update the fonts than to update the browsers
florian: can this be handled by the text rendering layer, underneath the layout engine
florian: is that the sort of thing that should be handled by HarfBuzz?
florian: it does the right thing for some definition of right thing but the right thing is underdefined
florian: do we possibly want to involve Behdad, or is that too many people in the same thread?
fantasai: we could start with a smaller group
… it's a public thread
florian: it's an option, let's go with that
xfq_: +1
florian: we could involve Kida-san
Fullwidth Collapsing before stops and commas
],
<atsushi> w3c/
w3c/
atsushi: for jlreq we discussed this and produced combinations
… waiting for final check from Kida-san
florian: didn't we handle this already?
fantasai: we did follow up
… but that doesn't cover commas and periods
… colons and semicolons
florian: if it's 2-3 it's fine, if it's 15 maybe we need a different approach
atsushi: I believe in jlreq TF no one objects to Pf or Pe
florian: we want pretty much all sentence or phrase ending punctuations fit in the same box
… there's quite a few of them
https://
xfq_: Chinese group also discussed, but concluded that no fullwidth punctuation should be trimmed
… since it would not be part of the Chinese text
florian: It looks weird, but don't correct it?
fantasai: do we handle C and J differently?
xfq_: So for some fonts, fullwidth bracket is center-aligned
… it may cause a problem
florian: in Korean, Murakami was saying that they mainly use ASCII punctuations, but sometimes mix with fullwidth brackets
https://
florian: it's never right to handle it right
… for Korean it seems needed. If it's merely unnecessary rather than wrong for Chinese, then maybe we should indeed do it
xfq_: discussed having different switches for different punctuation
… or using SPAN
florian: What's the use case for keeping the space? I see a reason to not care, but what's the use case for wanting the extra space to stay?
… if you have fullwidth bracket followed by a period
fantasai: If you have centered fullwidth brackets, you must never trim. It's not about mixing with ASCII or not
fantasai: in the spec we have rules about fullwidth punctuation
… if we need to we can expand the rule
… changing behavior between centered vs non-centered punctuation
“Whether fullwidth colon punctuation and fullwidth dot punctuation should be considered fullwidth closing punctuation or fullwidth middle dot punctuation depends on where in the glyph’s box the punctuation is drawn. If the punctuation is centered, then it should be considered middle dot punctuation. If the punctuation is drawn to one side (left in horizontal text, top in vertical text) and the other
half is therefore blank then the punctuation should be considered closing punctuation and trimmed accordingly. ”
florian: we need to make sure the rule protects center-aligned punctuations
fantasai: currently it assumes the fullwidth bracket is always on one side
fantasai: Right now the spec assumes only colon and dot punctuation can be centered
… if Chinese has centered brackets now, then we need to make updates to the spec
fantasai: it would be useful to understand why the fonts are designed that way
… I wonder if the centering of such brackets is due to the lack of software support for space collapsing
… since if the software doesn't support such collapsing, it looks better to have centered brackets
… IIRC the rules in Chinese, you're not supposed to have centered brackets
xfq_: True. Some fonts do, though. Not most
Microsoft JhengHei
xfq_: including some fonts that come with OS
florian: These would have trouble with any kind of collapsing, not just the mix with ASCII
fantasai: If it's only a few fonts right now, then hopefully if we deploy trimming then fonts will have less incentive to do such things
florian: if there are a few famous fonts among the problematic ones, special processing can be hardcoded in browsers
fantasai: also authors who want such fonts specifically can turn off collapsing
fantasai: Back to the issue, I think we should handle ASCII periods and commas at least
… less sure about colons and semicolons
florian: interrobang maybe also, it's probably not part of ASCII, but conceptually it belongs to the same set of latin-derived broadly used punctuations
fantasai: don't need to do as far as things like Indic dandas
fantasai: what happens if you have CJK closing bracket following by a U+20 space
florian: if it's closing bracket, u+20 space, and kanji
… currently don't do anything
… people have a tendency to use space for alighment
… and they shouldn't do
fantasai: we should only collapse ideograph space, but not ascii space and any other space
xfq_: what's the default value for text-spacing-trim?
fantasai: by default we turn it on