Re: [svgwg] Character counting in text 'x', 'y', 'dx', 'dy', and 'rotate' attributes.

The SVG Working Group just discussed `Character counting in text 'x', 'y', 'dx', 'dy', and 'rotate' attributes`, and agreed to the following:

* `RESOLUTION: Assignment of multi-value text layout attributes (x, y, dx, dy, rotate) should be according to Unicode codepoint characters, not UTF-16 blocks.`
* `RESOLUTION: Do not change the spec for character values with regards to display: none.`

<details><summary>The full IRC log of that discussion</summary>
&lt;krit> topic: Character counting in text 'x', 'y', 'dx', 'dy', and 'rotate' attributes<br>
&lt;krit> GitHub: https://github.com/w3c/svgwg/issues/537<br>
&lt;krit> Tav: did more investigation. SVG 1.1, what browsers but Firefox do the counting is done by unicode code points and not by UTF16<br>
&lt;krit> AmeliaBR: so an emotion just gets one value of the attribute?<br>
&lt;krit> Tav: look down in the issue an there are a couple of tests. The 1st examples demonstatets that.<br>
&lt;krit> Tav: see the 5 chars at the bottom and they get positioned by unicode points.<br>
&lt;krit> http://tavmjong.free.fr/SVG/positioning-001.svg<br>
&lt;AmeliaBR> s/emotion/emoji/<br>
&lt;krit> Tav: so the empty boxes mean you don't have the necessary font installed<br>
&lt;krit> AmeliaBR: in chrome the red and black versions don't line up. What does it mean?<br>
&lt;krit> Tav: if they line up then the chars get positioned following UTF16<br>
&lt;krit> AmeliaBR: seems to be the useful thing to do esepecailly since most implementations do this<br>
&lt;krit> krit: doesn't work in Ai yet because of UTF16 issues on import<br>
&lt;krit> AmeliaBR: you can try to use entities so that you can comment on the issue what Ai is doing<br>
&lt;krit> krit: will do<br>
&lt;krit> AmeliaBR: what about the DOM methods<br>
&lt;krit> Tav: if you open the console for the tests and look at the output... the DOM methods DO use UTF16.<br>
&lt;krit> AmeliaBR: which seems less useful<br>
&lt;krit> AmeliaBR: there are other DOM methods which read back the actual position and show how the actual layout happens. Those would still use UTF16 but would match up what actually is going to get used.<br>
&lt;krit> AmeliaBR: we need to clearly test what browsers are doing but if browsers use actual unicode characters then...<br>
&lt;krit> krit: To clarify: Browsers use unfixed code points for actual layout but UTF16 for DOM methods?<br>
&lt;krit> Tav: sounds correct.<br>
&lt;krit> AmeliaBR: If you say "give me character 2" it should return which character it is part of taking glyphs and everything into account already.<br>
&lt;krit> AmeliaBR: including UTF16 encoding<br>
&lt;krit> Tav: I think SVG 1.1 actually specs as browsers but Firefox implement it.<br>
&lt;krit> Tav: I think Cameron added a clarification.<br>
&lt;krit> krit: What testing is missing? Tav seemed to have some part of it.<br>
&lt;krit> AmeliaBR: I'd like to see the other DOM methods that read back position cross-browsers.<br>
&lt;krit> AmeliaBR: especially if there are compatibility issues for files that were exported to SVG and now would get positioned incorrectly on reading back.Mostly the non-web use cases.<br>
&lt;krit> krit: Ai would not use any of the DOM methods but I can provide feedback to the visual output.<br>
&lt;krit> AmeliaBR: the description should match up with SVG 1 and most implementations.<br>
&lt;krit> krit: we could reconsider later and resolve now.<br>
&lt;AmeliaBR> Proposed: Assignment of multi-value text layout attributes (x, y, dx, dy, rotate) should be according to Unicode codepoint characters, not UTF-16 blocks.<br>
&lt;krit> RESOLUTION: Assignment of multi-value text layout attributes (x, y, dx, dy, rotate) should be according to Unicode codepoint characters, not UTF-16 blocks.<br>
&lt;krit> AmeliaBR: there was another part of the issue how to collapse whitespaces. Any proposal on that one?<br>
&lt;krit> Tav: from a user perspective: if you change a CSS property the characters move around.<br>
&lt;krit> AmeliaBR: that is consistent how display: none works in CSS layout. In comparison visibility: hidden.<br>
&lt;krit> Tav: the hidden one would use a gap in the text<br>
&lt;krit> AmeliaBR: so you thing there should be a way where automatic layout adjusts but per character markup still applies regardless of the overall layout<br>
&lt;krit> Tav: yes<br>
&lt;krit> AmeliaBR: especially on manual kerning you wouldn't want to match the characters to other characters.<br>
&lt;krit> Tav: right. This is unpredictable in some cases.<br>
&lt;krit> Tav: markup values should be interpreted differently from CSS layout ideally. From a practical use case it might not be relevant.<br>
&lt;krit> Tav: the fact that every one does it as speced except Firefox it might not make it worth changing anyway.<br>
&lt;krit> krit: in the future there are alternatives to kerning with CSS but positioning characters individually is still popular like for iWorks on the cloud.<br>
&lt;krit> AmeliaBR: The workaround would be to put the char positioning on the individual span elements directly rather than the top text element. Would help on display none.<br>
&lt;krit> AmeliaBR: I agree with your conclusion that we should follow the majority of implementations.<br>
&lt;krit> Tav: that is how it is speced in SVG2.<br>
&lt;krit> AmeliaBR: ...and follows previous resolutions.<br>
&lt;krit> proposed RESOLUTION: Do not change a previous resolution for character values with regards to display: none.<br>
&lt;krit> AmeliaBR: could you check if there might be issues on Firefox?<br>
&lt;krit> RESOLUTION: Do not change the spec for character values with regards to display: none.<br>
&lt;AmeliaBR> Here's a Firefox issue re display: none https://bugzilla.mozilla.org/show_bug.cgi?id=1141224<br>
&lt;AmeliaBR> Will need a new issue once the spec for unicode vs UTF-16 is ready.<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-416351148 using your GitHub account

Received on Monday, 27 August 2018 20:06:04 UTC