Closed nonergodic closed 1 month ago
Svg.js usually doenst use the baseline to move text. That's why there are 2 methods. The normal move() loves by the upper left corner and amove() moves by text-anchor.
However, this uses bbox and those can only be calculated when the text is rendered. Are your symbols in defs? In that case they won't be rendered and therefore the text can't be positioned by its upper left corner.
Just use amove then and account for the baseline (as you did)
This isn't a bug of svg.js tho but more a way how svg and text works
The documentation states:
The only difference between symbols and groups is that symbols are not rendered.
My example shows that this is clearly not the case and it's not the only instance that I stumbled over where text behaved differently when used in a symbol than when used in a group (but my memory is hazy - I think .cx had a different result when invoked on the group vs the symbol). (I have given up on using a symbol and am now instead using a function to create copies, but as far as I understand, this is less efficient in terms of performance).
I guess in that case we should remove that paragraph because it's rather meant in a more abstract way. Symbols absolutely don't behave the same way. However to use svg.js efficiently, a certain knowledge about svg itself is required. Some context cannot be abstract away in a user friendly way. Some things you just have to try out and see where it goes from there
Fair enough.
See here for a simple example
I encountered this problem locally at first, where I simply didn't see any render of text, while in the fiddle, the text only gets partially rendered.
Edit: Some more tinkering reveals that moving the text to down by adding e.g. a
.move(0, 20)
to its definition in the symbol, like this, "fixes" it.So it seems like this is an issue with texts because their default anchor is on their baseline and then everything that sticks out in a negative quadrant gets cut somehow?