Implement extended TextMetrics object
Categories
(Core :: Graphics: Canvas2D, task)
Tracking
()
People
(Reporter: fs, Assigned: richard)
References
(Blocks 1 open bug, )
Details
(Keywords: dev-doc-complete, parity-chrome, Whiteboard: [DocArea=Canvas][layout:backlog], [wptsync upstream])
Attachments
(7 files, 2 obsolete files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details |
Comment 1•10 years ago
|
||
Assignee | ||
Comment 2•9 years ago
|
||
Assignee | ||
Comment 3•9 years ago
|
||
Assignee | ||
Comment 4•9 years ago
|
||
Updated•8 years ago
|
Comment 5•8 years ago
|
||
Comment 6•8 years ago
|
||
Comment 7•8 years ago
|
||
Comment 8•8 years ago
|
||
Assignee | ||
Comment 9•8 years ago
|
||
Comment 10•8 years ago
|
||
Assignee | ||
Comment 11•8 years ago
|
||
Comment 12•8 years ago
|
||
Comment 13•8 years ago
|
||
Assignee | ||
Updated•8 years ago
|
Assignee | ||
Comment 14•8 years ago
|
||
Comment 15•8 years ago
|
||
Updated•8 years ago
|
Comment 16•8 years ago
|
||
Assignee | ||
Comment 17•8 years ago
|
||
Assignee | ||
Comment 18•8 years ago
|
||
Comment 19•8 years ago
|
||
Comment 20•8 years ago
|
||
Assignee | ||
Comment 21•8 years ago
|
||
Comment 22•8 years ago
|
||
Assignee | ||
Comment 23•8 years ago
|
||
Comment 25•8 years ago
|
||
Comment 26•7 years ago
|
||
Comment 27•7 years ago
|
||
Comment 28•6 years ago
|
||
Comment 29•5 years ago
|
||
It looks like Chrome is going to ship this 77 so it might be worth trying to get done.
Comment 30•5 years ago
|
||
Btw,
Chrome has only shipped actualBoundingBox*, which I think sidesteps most of the issues brought up here.
Comment 31•5 years ago
|
||
I guess we need to look at the latest spec, and at what Chrome is shipping, and if we're happy enough with it then update the patch here to align with them. We may still run into issue because of using different font metrics (for the same font) on different platform back-ends.
Are there web-platform-tests that we can rely on to check behavior here?
Comment 32•5 years ago
|
||
Hi,
I am part of the Excel Online group in Microsoft, We are using this API to measure the text width and height, Currently FireFox is one of the only supported browser which did not implement it, since Edge is now chromium, and Safari also supported bounding box (left, right, height, width).
Unfortunately we might have to instruct customers to switch to other browsers to open office online until this issue is fixed.
Is it possible you will ship only the bounding box part of the API?
What would be the timeline?
Thanks,
Eyal.
Keeping an eye on this issue as it's recently active.
Updated•5 years ago
|
Comment 34•5 years ago
|
||
With Fx73 going to Beta next week, this is going to have to go out with Fx74 at the earliest.
Comment 35•5 years ago
|
||
I've been looking into updating the patch here, with a view to possibly shipping the actualBoundingBox attributes; current try run is at https://treeherder.mozilla.org/#/jobs?repo=try&revision=a62c5c847dcd0fe075849923e3f3c883f2d4f062.
Comment 36•5 years ago
|
||
(In reply to Eyal from comment #32)
Hi,
I am part of the Excel Online group in Microsoft, We are using this API to measure the text width and height, Currently FireFox is one of the only supported browser which did not implement it, since Edge is now chromium, and Safari also supported bounding box (left, right, height, width).
Unfortunately we might have to instruct customers to switch to other browsers to open office online until this issue is fixed.Is it possible you will ship only the bounding box part of the API?
Eyal, could you please confirm if it is specifically the four actualBoundingBox*
attributes that you're looking for (the ones mentioned by Fernando in comment 30), or do you also need the emHeight*
and/or fontBoundingBox*
values?
It's unclear to me exactly what the state of standardization and implementation is here... I see these additional attributes in Chrome, which doesn't seem to match comment 30 above, and I also see an advances
array, which IIRC was quite controversial when it was discussed; meanwhile in Safari I see several *Baseline
attributes (but no advances
).
If we implement just the actualBoundingBox*
attributes, which seem to present the fewest standardization/compatibility issues, would this address your use case adequately?
Updated•5 years ago
|
Comment 37•5 years ago
|
||
(In reply to Jonathan Kew (:jfkthame) from comment #36)
(In reply to Eyal from comment #32)
Hi,
I am part of the Excel Online group in Microsoft, We are using this API to measure the text width and height, Currently FireFox is one of the only supported browser which did not implement it, since Edge is now chromium, and Safari also supported bounding box (left, right, height, width).
Unfortunately we might have to instruct customers to switch to other browsers to open office online until this issue is fixed.Is it possible you will ship only the bounding box part of the API?
Eyal, could you please confirm if it is specifically the four
actualBoundingBox*
attributes that you're looking for (the ones mentioned by Fernando in comment 30), or do you also need theemHeight*
and/orfontBoundingBox*
values?It's unclear to me exactly what the state of standardization and implementation is here... I see these additional attributes in Chrome, which doesn't seem to match comment 30 above, and I also see an
advances
array, which IIRC was quite controversial when it was discussed; meanwhile in Safari I see several*Baseline
attributes (but noadvances
).If we implement just the
actualBoundingBox*
attributes, which seem to present the fewest standardization/compatibility issues, would this address your use case adequately?
Yes, We need the actual bounding box to measure the text width and height.
We also need the baseline to draw an underline,
We need the line gap (leading) for multiple lines of text in a cell (wrap text),
But the last 2 are not provided yet by chrome as well.
If you could add them it would be great,
Thanks,
Eyal.
Comment 38•5 years ago
|
||
(In reply to Eyal from comment #37)
We also need the baseline to draw an underline,
We need the line gap (leading) for multiple lines of text in a cell (wrap text),
But the last 2 are not provided yet by chrome as well.
Looking at the current TextMetrics spec, I don't see any attributes relevant to leading. So if you want some line-spacing/leading metrics to be exposed, I think this needs to be brought up as a spec discussion first.
Comment 39•5 years ago
|
||
This is extracted from the original patch by Richard Matheson; it's not strictly necessary
to implementing the additional TextMetrics attributes, but OTOH if we're going to potentially
expose baseline attributes, it seems sensible to make them somewhat more meaningful than the
fallbacks in the current code.
Eventually we should use baseline tables from the font, but (a) we don't have support for
that in the back-end font code, and (b) very few fonts provide the data anyway, so while this
isn't perfect, for now it's the best we can do.
Comment 40•5 years ago
|
||
This is the main work of Richard Matheson's original patch, updated to current trunk code
and with the new attributes put behind prefs. Because some of the attributes may be more
stable than others (there was a move by Google to change how baselines are represented,
but then this was retracted because Safari is already shipping per the existing spec; and
we have some differences in how we handle font metrics between platforms which may affect
the font ascent/descent values), I've split this into several prefs so that we have the
possibility of enabling just the more stable (and/or more urgently requested) attributes.
(Note that this echos Google's approach per comment 30 of initially shipping part of the API.)
Depends on D59678
Comment 41•5 years ago
|
||
This is unaffected by the differences in font metrics between platform back-ends,
so should be safe to ship without significant risk that it'll be unstable or need
to be revised in future.
Depends on D59679
Comment 42•5 years ago
|
||
For what it's worth, I filed some github issues on the TextMetrics
spec when reviewing it on behalf of the TAG.
Comment 43•5 years ago
|
||
Yeah, there are questions regarding font metrics and baselines that I think need clarification (and probably more work in the implementation...). The actualBoundingBox metrics seem less troublesome, AFAICT.
Comment 44•5 years ago
|
||
Comment 45•5 years ago
|
||
Backed out for failing wpt on OSX at 2d.text.measure.actualBoundingBox.html
Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedJob=285502009&resultStatus=testfailed%2Cbusted%2Cexception&revision=c81d3e9ee1581b9765f9c3ea998dd250364bc969
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=285502009&repo=autoland&lineNumber=918
Backout: https://hg.mozilla.org/integration/autoland/rev/b3d7e55aed9b36bbaff5c16000bc769d867341f0
Updated•5 years ago
|
Comment 46•5 years ago
|
||
Yeah, I saw this failed a test and was backed out - will be looking into it.
Comment 47•5 years ago
|
||
This failed the test for the actualBoundingBoxLeft
attribute because although the glyph in the test font nominally begins at the origin (and so the test expects actualBoundingBoxLeft == 0), we actually return -1 because the bounding box includes potential antialiasing-affected pixels.
As a comment in the test file already says, "Different platforms may render text slightly different", so I think we should just adjust the test to accept a close-to-zero value rather than requiring exactly zero here.
Comment 48•5 years ago
|
||
Comment 51•5 years ago
|
||
Comment 52•5 years ago
|
||
Argh, upstream checks complain if we don't update the original yaml file properly. This should fix things.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 54•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/28a9c958e194
https://hg.mozilla.org/mozilla-central/rev/17f161af2406
https://hg.mozilla.org/mozilla-central/rev/a59075257290
https://hg.mozilla.org/mozilla-central/rev/e3be392e8132
Comment 55•5 years ago
|
||
Comment 56•5 years ago
|
||
bugherder |
Comment 58•5 years ago
|
||
Hi Eyal,
Could you test our nightly builds and confirm that the change implemented in this ticket fixes the issue for the Excel team?
Thanks
Pascal
https://nightly.mozilla.org
Comment 59•5 years ago
|
||
(In reply to Jonathan Kew (:jfkthame) from comment #36)
(In reply to Eyal from comment #32)
Hi,
I am part of the Excel Online group in Microsoft, We are using this API to measure the text width and height, Currently FireFox is one of the only supported browser which did not implement it, since Edge is now chromium, and Safari also supported bounding box (left, right, height, width).
Unfortunately we might have to instruct customers to switch to other browsers to open office online until this issue is fixed.Is it possible you will ship only the bounding box part of the API?
Eyal, could you please confirm if it is specifically the four
actualBoundingBox*
attributes that you're looking for (the ones mentioned by Fernando in comment 30), or do you also need theemHeight*
and/orfontBoundingBox*
values?It's unclear to me exactly what the state of standardization and implementation is here... I see these additional attributes in Chrome, which doesn't seem to match comment 30 above, and I also see an
advances
array, which IIRC was quite controversial when it was discussed; meanwhile in Safari I see several*Baseline
attributes (but noadvances
).If we implement just the
actualBoundingBox*
attributes, which seem to present the fewest standardization/compatibility issues, would this address your use case adequately?
Hi,
First of all I would like to start with a big thank you! It's amazing to see how responsive you are, which really helps building better apps and better browsers :)
I have checked it and it works very similar to chrome which suits our basics needs.
We also need the fontBoundingBox (currently we get it from the height of a div element with the requested font), chromium have it under a flag.
Is it possible to support it as well?
Thanks,
Eyal.
Comment 60•5 years ago
|
||
We also have the fontBoundingBox metrics available behind a flag; you can try setting dom.textMetrics.fontBoundingBox.enabled
to true
in about:config, and experiment with it.
I'm not sure how portable/compatible this will be, as there are various ways of reading font metrics and they may give different results, so would be interested in any feedback.
Reporter | ||
Comment 61•5 years ago
|
||
Updated/created docs:
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/74#Canvas_and_WebGL
https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics
https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics/actualBoundingBoxAscent
https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics/actualBoundingBoxDescent
https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics/actualBoundingBoxLeft
https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics/actualBoundingBoxRight
https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics/alphabeticBaseline
https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics/emHeightAscent
https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics/emHeightDescent
https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics/fontBoundingBoxAscent
https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics/fontBoundingBoxDescent
https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics/hangingBaseline
https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics/ideographicBaseline
Comment 62•2 years ago
|
||
:jfkthame, is there any plan to set the pref to true by default ?
According to MDN, Firefox is the only browser to not support this feature:
https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics/fontBoundingBoxAscent
Comment 63•2 years ago
|
||
We could enable it, I guess, but my concern is that the results are not actually interoperable across browsers, so it's unclear how useful it would really be until that is resolved. See for example the comment at https://github.com/web-platform-tests/interop/issues/159#issuecomment-1303361603.
Comment 64•2 years ago
|
||
In the pdf.js context, I want to use these properties to modify the top of the spans containing the text in the text layer in order to perfectly align them and the text drawn on the canvas.
Could we at least just enable the feature for pdf.js (we already did that in the past for other features, e.g. https://hg.mozilla.org/mozilla-central/rev/0ae8b1a8e1e9) ?
Comment 65•2 years ago
|
||
I don't see a convenient way to do that for these attributes. Maybe we should start by enabling them for Nightly/early-Beta (or Nightly and Dev Edition?), and see what happens. I'm also curious to know how well they work for your use case, as I'm not sure exactly how the canvas metrics will relate to HTML text layout.... it may still be difficult to achieve entirely consistent results.
My suggestion: file a new bug requesting them to be enabled for pre-release channels, or something like that; and then if things go well, we can consider going all the way to release.
Updated•2 years ago
|
Description
•