Closed Bug 371787 Opened 17 years ago Closed 4 years ago

Support the 'letter-spacing' and 'word-spacing' properties in SVG

Categories

(Core :: SVG, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla72
Tracking Status
relnote-firefox --- -
firefox72 --- fixed

People

(Reporter: a.neumann, Assigned: heycam)

References

(Blocks 2 open bugs, )

Details

(4 keywords)

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070226 Minefield/3.0a3pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070226 Minefield/3.0a3pre

the word-spacing attribute doesn't seem to be implemented, see screenshot with rendering comparison Minefield/Opera: http://www.carto.net/neumann/mozillasvgbugs/word-spacing_minefield_opera.png

The upper window shows the rendering in Minefield ignoring the word-spacing attribute, the lower window shows the correct rendering in Opera 9.1.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Status: UNCONFIRMED → NEW
Ever confirmed: true
letter-spacing has the same problem - attribute not implemented.
FF3beta5, Windows XP SP2
Assignee: general → nobody
QA Contact: ian → general
Blocks: svg11tests
Summary: word-spacing attribute not implemented on text/tspan elements → Support the 'letter-spacing' and 'word-spacing' properties in SVG
Severity: enhancement → normal
Depends on: svgtext
Example for letter-spacing in SVG: http://johan.github.com/kilobyte-svg-challenge/logos/lysator.svg

Webkit reference rendition: http://i.imgur.com/nQhv0.png
Firefox 19 broken rendition: http://i.imgur.com/reRJm.png (alpha channel bugs are mine; ignore the white bg)
Depends on: 839955
Assignee: nobody → longsonr
Assignee: longsonr → nobody
Cameron, what are your thoughts now that bug 839955 is fixed?
Flags: needinfo?(cam)
Blocks: 934525
It's not trivial to get working.  IIRC nsTextFrame uses a PropertyProvider object to get the spacing property values, and it wasn't obvious where to get one of those (with the right values) from within nsSVGTextFrame2.  longsonr recently tried to get this working -- how far did you get Robert?
Flags: needinfo?(cam)
Attached patch WIP (obsolete) — Splinter Review
This is as far as I got. Asserts occur and the DOM mostly doesn't work.

Rendering seems fairly reasonable though.
Just ran into this issue. Is there still any work being done?
Not by me currently so if you want to continue from where I left off, feel free.
AFAIK Gecko is the only engine that does not support these attributes.
Hi all,

We would really like to use XUL and Gecko engine for rendering SVG graphics and this issue is halting the whole idea. How likely is it to be resolved in the next few months?

Greetings,

Dejan
See comment 10 i.e. How likely are you to submit a patch to implement or pay someone to do so on your behalf, Dejan?
(In reply to Robert Longson from comment #14)
> See comment 10 i.e. How likely are you to submit a patch to implement or pay
> someone to do so on your behalf, Dejan?

Very unlikely.
who can do it? - I would like to spend some money to solve this issue. Maybe we can share the costs??
(In reply to Tom from comment #16)
> who can do it? - I would like to spend some money to solve this issue. Maybe
> we can share the costs??

Feel free to publish on https://www.bountysource.com/teams/mozilla/
Assignee: nobody → cku
The following SVG uses the letter spacing attribute:
http://johan.github.io/kilobyte-svg-challenge/logos/lysator.svg

As of Mar 2, 2017 this works properly in Safari, Chrome, Edge, and Internet Explorer 11. Firefox still appears to ignore the letter-spacing SVG attribute.
according to current job assignment, I will not have time to work on this feature in within six months. deassign.
Assignee: cku → nobody
Whiteboard: [parity-chrome][parity-edge][parity-safari]
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Whiteboard: [parity-chrome][parity-edge][parity-safari]
This lack of support of this properties are annoying like in old days IE6. I can understood it if there are no string engine support for creating spacing between glyphs, but it exist! Property "dx" prove that there are all necessary mechanisms to support it. "dx" can be used to simulate 'letter-spacing' an probably 'word-spacing'.

For
'letter-spacing: N;'
it can be simulated by:
'dx: 0 N N N ... N;' where number of N is length of string in <text> minus one.

In case of 'word-spacing' this is more complicated but doable.

Robert or Cam, could you summarize why is this hard? Like, rendering-wise I assume this is just a matter of removing these early-returns right?

I guess this is hard because this needs to be all exposed in the SVG DOM APIs?

Well, just gave that a shot and that's not enough itself. I missed one of the other early returns, but clearly that's not enough. Letter spacing is probably easy since you can just use the same mechanism as dx, and not handle it in nsTextRun. word-spacing however is (probably?) harder.

I think the DOM APIs may come out in the wash if you do it right.

The right way to handle this is to ensure we have an appropriate PropertyProvider object whenever we call into glyph measuring functions on text runs. I wrote a patch and it didn't seem too tricky in the end.

Assignee: nobody → cam
Status: NEW → ASSIGNED

Some trickiness would be needed to ensure getEndPositionOfChar and getExtentOfChar don't include any letter-spacing or word-spacing that comes after it. I haven't handled that. We'd need to add some new function or flags to measure advances on a text run that specifically exclude any final space. I'm inclined to leave that to a followup.

(In reply to Cameron McCormack (:heycam) from comment #33)

The right way to handle this is to ensure we have an appropriate PropertyProvider object whenever we call into glyph measuring functions on text runs.

Robert's approach to explicit get the spacing information and apply it during SVG glyph positioning could also work, but I think it would be harder to ensure that we apply spacing in exactly the same way that CSS does. So I think it's easier to rely on nsTextFrame to position its glyphs with letter-spacing etc. applied, and then use those results when layering on the SVG glyph positioning.

Pushed by cmccormack@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ed9b896fd383
Add support for letter-spacing and word-spacing in SVG text. r=jfkthame,longsonr
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla72
Blocks: 1598121

Since I raised w3c/csswg-drafts#4498, let me also ask the question here: how can author detect the existence of this feature?

There's no pure CSS way to detect whether letter-spacing and word-spacing have an effect on SVG text (since @supports would return true for the properties in general). It was kind of just a bug that we didn't support these properties on SVG text.

If you have script available you can always create a <text> element with spacing, then look at the bounding box or something to tell if it has an effect.

Release Note Request (optional, but appreciated)
[Why is this notable]: Support for making letter-spacing and word-spacing work on SVG text is a common author request.
[Affects Firefox for Android]: Yes, this is a platform feature.
[Suggested wording]: The letter-spacing and word-spacing CSS properties now work on SVG text.
[Links (documentation, blog post, etc)]: Maybe just https://developer.mozilla.org/en-US/docs/Web/CSS/letter-spacing and https://developer.mozilla.org/en-US/docs/Web/CSS/word-spacing.

relnote-firefox: --- → ?
Regressions: 1599173

Is this worth a mention in the main (user-facing) release notes or is a developer note at https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/72 sufficient?

Flags: needinfo?(cam)

I think a developer note is sufficient.

Flags: needinfo?(cam)

This bug still appears to be present in Firefox 72, even though stated that it is fixed.

Yes, it was disabled in bug 1599173 because of a serious regression, and then re-enabled when fixed, which was bug 1600855 (and which unfortunately didn't make it on time for 72). So will be in 73.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #49)

Yes, it was disabled in bug 1599173 because of a serious regression, and then re-enabled when fixed, which was bug 1600855 (and which unfortunately didn't make it on time for 72). So will be in 73.

Ok, thanks!

thank you!

Attachment #8334130 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.