Character counting in text 'x', 'y', 'dx', 'dy', and 'rotate' attributes

GitHub: https://github.com/w3c/svgwg/issues/537

Tav: did more investigation. SVG 1.1, what browsers but Firefox do the counting is done by unicode code points and not by UTF16

AmeliaBR: so an emoji just gets one value of the attribute?

Tav: look down in the issue an there are a couple of tests. The 1st examples demonstatets that.
... see the 5 chars at the bottom and they get positioned by unicode points.

http://tavmjong.free.fr/SVG/positioning-001.svg

Tav: so the empty boxes mean you don't have the necessary font installed

AmeliaBR: in chrome the red and black versions don't line up. What does it mean?

Tav: if they line up then the chars get positioned following UTF16

AmeliaBR: seems to be the useful thing to do esepecailly since most implementations do this

krit: doesn't work in Ai yet because of UTF16 issues on import

AmeliaBR: you can try to use entities so that you can comment on the issue what Ai is doing

krit: will do

AmeliaBR: what about the DOM methods

Tav: if you open the console for the tests and look at the output... the DOM methods DO use UTF16.

AmeliaBR: which seems less useful
... 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.
... we need to clearly test what browsers are doing but if browsers use actual unicode characters then...

krit: To clarify: Browsers use unfixed code points for actual layout but UTF16 for DOM methods?

Tav: sounds correct.

AmeliaBR: If you say "give me character 2" it should return which character it is part of taking glyphs and everything into account already.
... including UTF16 encoding

Tav: I think SVG 1.1 actually specs as browsers but Firefox implement it.
... I think Cameron added a clarification.

krit: What testing is missing? Tav seemed to have some part of it.

AmeliaBR: I'd like to see the other DOM methods that read back position cross-browsers.
... 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.

krit: Ai would not use any of the DOM methods but I can provide feedback to the visual output.

AmeliaBR: the description should match up with SVG 1 and most implementations.

krit: we could reconsider later and resolve now.

<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.

RESOLUTION: Assignment of multi-value text layout attributes (x, y, dx, dy, rotate) should be according to Unicode codepoint characters, not UTF-16 blocks.

AmeliaBR: there was another part of the issue how to collapse whitespaces. Any proposal on that one?

Tav: from a user perspective: if you change a CSS property the characters move around.

AmeliaBR: that is consistent how display: none works in CSS layout. In comparison visibility: hidden.

Tav: the hidden one would use a gap in the text

AmeliaBR: so you thing there should be a way where automatic layout adjusts but per character markup still applies regardless of the overall layout

Tav: yes

AmeliaBR: especially on manual kerning you wouldn't want to match the characters to other characters.

Tav: right. This is unpredictable in some cases.
... markup values should be interpreted differently from CSS layout ideally. From a practical use case it might not be relevant.
... the fact that every one does it as speced except Firefox it might not make it worth changing anyway.

krit: in the future there are alternatives to kerning with CSS but positioning characters individually is still popular like for iWorks on the cloud.

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.
... I agree with your conclusion that we should follow the majority of implementations.

Tav: that is how it is speced in SVG2.

AmeliaBR: ...and follows previous resolutions.

proposed RESOLUTION: Do not change a previous resolution for character values with regards to display: none.

AmeliaBR: could you check if there might be issues on Firefox?

RESOLUTION: Do not change the spec for character values with regards to display: none.

<AmeliaBR> Here's a Firefox issue re display: none https://bugzilla.mozilla.org/show_bug.cgi?id=1141224

<AmeliaBR> Will need a new issue once the spec for unicode vs UTF-16 is ready.

Review property value definitions to ensure unitless lengths are correctly included

GitHub: https://github.com/w3c/svgwg/issues/534

ericwilligers: The google docs demonstrates which properties in implementations currently support length and number values as length: https://docs.google.com/spreadsheets/d/1HRzb_-S28xq7GqYKhHbMP2YQlqWLvOWSS_twLXy-I40/edit#gid=1297517027
... we need to look at the properties which we are going to change in the implementations and which in the specification like stroke-dash-array

AmeliaBR: those were defined in SVG 1. though it was redefined by CSS and we need to propose changes to the CSS WG.
... for the geometry properties, thet are SVG specific and already ship in multiple properties I am happy to add the plain numbers for them

krit: there would be some inconsistencies for instance with width and height which do not support numbers.
... also, the layout properties currently are SVG specific but might not be in the future.

ericwilligers: we could say that those are in the quirks mode for SVG.

krit: IIRC there is no official quirks mode yet

<AmeliaBR> Usage data: https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/cx/

krit: I'd suggest that we look if the cx, cy and so on properties could change to length only values
... seems like 20% are number versions
... I guess we have to decide case by case then

ericwilligers: but the numbers are all very very slow

krit: that is true
... starting with the layout properties first... anyone we want to reach out to or investigate?

AmeliaBR: we could bring this up as part of CSS discussions.
... especially with being consistent with width and height and already shipping presentation attributes.

krit: we already have differences between attribute and property value definition so that by itself is not argument for number values on properties.

AmeliaBR: yes

krit: could we send the document to the CSS WG and ask for their feedback?

ericwilligers: I prepared it already and can present to the CSS WG

AmeliaBR: for the stroke-* properties this is just a correction but the other properties are more of a debate.

RESOLUTION: Ask the CSS WG for feedback on number length values for currently SVG specific CSS properties

PRs

krit: the changes from AmeliaBR to build system looked good to me

AmeliaBR: will look at conflicts first
... the one on language is good for merge. Eric already marked them as non-substantial. Going to merge right now.

krit: there is the child keyword/function PR that still needs review

AmeliaBR: will look
... there is Tavs text PR I think we can merge it
... other changes go to new PR

trackbot, end telcon

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/emotion/emoji/
Succeeded: s/propertoes/properties/
Default Present: stakagi, Tav, krit, AmeliaBR, ericwilligers
Present: stakagi Tav krit AmeliaBR ericwilligers
No ScribeNick specified.  Guessing ScribeNick: krit
Inferring Scribes: krit

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 27 Aug 2018
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)