- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 19 Sep 2019 09:07:45 +0000
- To: public-svg-issues@w3.org
The SVG Working Group just discussed `Character counting in text attributes`, and agreed to the following: * `RESOLVED: Do not change the previous resolution.` <details><summary>The full IRC log of that discussion</summary> <mstange> Topic: Character counting in text attributes<br> <AmeliaBR> github: https://github.com/w3c/svgwg/issues/537<br> <mstange> AmeliaBR: To recap: text attributes for positioning, as we've been discussing, can have multiple values that can be applied to multiple characters.<br> <mstange> AmeliaBR: The first step is that we look at the attribute and assign each value to a different DOM character. In some cases that's very simple.<br> <mstange> ... But if you have more complex multi-byte characters, things get more confusing.<br> <mstange> s/characters,/characters or clusters,/<br> <mstange> AmeliaBR: "What is a character" becomes a debate.<br> <mstange> ... There are other definitions that use utf-16 blocks, which is not very useful. But beyond that, do you use unicode codepoints or do you combine and cluster things so that you have a combining accent character, are those the same character or different characters?<br> <mstange> ... We have a resolution from January which resolved that values in the array should be assigned based on unicode codepoints.<br> <mstange> ... The argument for that is that unicode codepoints are stable and won't be affected by whether a new cluster gets introduced, or whether a particular font supports a particular combining unit.<br> <mstange> myles: Other part of the resolution: We count based on code points, but we don't segment based on code points.<br> <mstange> myles: Let's say we have the string of code units "A" "B" "heart emoji" "red combining character". Now we also have an array of positioning values with four elements.<br> <mstange> ... Now we need to come up with a mapping. There's to parts to this resolution: When you count, you count code point by code point. And the second part is: You're allowed to disregard any positions assigned to any combining characters, because the combining characters don't get rendered on their own.<br> <mstange> ... We didn't want to have a situation where regular characters following a combining character end up in the wrong position because they get assigned the wrong value from the position array.<br> <mstange> ... This ensures consistency between browsers.<br> <mstange> AmeliaBR: It's not intuitive for hand-authoring. But the upside is that, outside of browser differences of the graphing cluster, the rest of the layout stays consistent from browser to browser. Once you get past the cluster that has the discrepancy, everything else is the same.<br> <mstange> nmccully: Let's say there is a browser with a shaping engine and one that is not. The browser that has a shaping engine will <missed>. The browser that *doesn't* have a shaping engine will presumably manually get positioning information and the combining red would be passed by itself to a table that gives a space.<br> <mstange> AmeliaBR: There is a multi-stage lining up process. The way we're proposing is: positioning values to code points is a one-to-one matching. The next step (matching code points to your shaping) is where things can be discarded because of ligatures or combinations etc.<br> <mstange> r12a: There are two issues. One, e.g. the word réd can have two code point representations, and an author cannot immediately see which one is used.<br> <mstange> heycam: If the positional values are coming from a graphical editor, the graphical editor knows what code points are used and can generate the correct arrays.<br> <mstange> AmeliaBR: Yes, it's only the hand authoring case that's hard.<br> <mstange> myles: Alternatively, we could specify that <missed> goes through normalization.<br> <mstange> r12a: I do not like the idea of normalizing my content. Sometimes I want things to be composed and put the accents afterwards.<br> <mstange> myles: Pragmatic / performance, might not be worth it.<br> <mstange> r12a: The other issue is that, for example if you have some Persian, sometimes a zero-width joiner is used at the end of a word to produce the right shape. Then you need the two characters to stay together.<br> <mstange> ... and those are not a graphing cluster.<br> <mstange> heycam: You would ignore the positioning value for the zero-width joiner.<br> <mstange> AmeliaBR: If you're intentionally putting the ZWJ <missed>, you still want contextual glyph selection.<br> <AmeliaBR> s/<missed>/to change to a medial glyph/<br> <mstange> heycam: CSS properties can change the effect of ligatures and other combinations, and you wouldn't want to have to adjust your positioning value array based on that.<br> <AmeliaBR> s/<missed> goes/the text content/<br> <mstange> nmccully: If you need backward compatibility with engines that don't understand the red combining thing, <missed><br> <mstange> myles: A lot of people said "there is incompatibility and we have to deal with it."<br> <AmeliaBR> s/engine will <missed>/engine will get fewer glyph clusters from the engine than there are characters/<br> <mstange> nmccully: Are you protecting from a malformed SVG from a bad player?<br> <mstange> nmccully: Different browsers might get different results for cluster segmentation. Users want to get consistent positions everywhere. So we can't count positioning values based on the results from cluster segmentation. So we have to do the matching based on something in the source.<br> <heycam> mstange: seems like whenever you have parallel arrays, you should just have a single array of pairs<br> <heycam> ... why is this API necessary?<br> <mstange> AmeliaBR / myles: There is existing content that uses it.<br> <mstange> r12a: In Indic scripts you have conjuncts, you split a syllable at a time.<br> <mstange> ... (shows an example that has two graphing clusters that combine into one visible unit)<br> <mstange> myles: This is why we didn't want to specify what segmentation to use.<br> <AmeliaBR> s/graphing clusters/grapheme clusters/g<br> <mstange> AmeliaBR: r12a, are you ok with keeping the existing resolution?<br> <mstange> r12a: It's not pretty, but I understand why it's there, and I can't figure out anything better.<br> <mstange> r12a: (shows a testcase that renders differently in Firefox and Chrome, where diagonal Arabic text is rendered top-right to bottom-left in Firefox and top-left to bottom-right in Chrome)<br> <mstange> RESOLVED: Do not change the previous resolution.<br> <AmeliaBR> RRSAgent, make minutes<br> <RRSAgent> I have made the request to generate https://www.w3.org/2019/09/18-svg-minutes.html AmeliaBR<br> <prushforth> CG meeting is on channel #svgcg<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/svgwg/issues/537#issuecomment-533040447 using your GitHub account
Received on Thursday, 19 September 2019 09:07:46 UTC