You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I know you changed the default textBaseline from "alphabetic" to "top" in version 0.5, however FF positions the text differently than Chrome/IE9 (Latest stable builds on Windows). This can also be seen in the Inheritance tutorial that comes with the latest build of easeljs. Maybe setting the default back to "alphabetic" would be better until this issue is resolved, or adding a warning in the documentation.
Just noticed this. There is also a difference between phantomjs on windows and phantomjs on linux, but that may be due to the different set of fonts on the systems (the only font i am using is on both, but perhaps standard fonts?). Setting the textBaseline to "alphabetic" yields the same ouput on both platforms.
Seems like the difference scales with font size, so smaller text looks OK, but larger texts are askew.
This is unfortunately a browser issue, and we don't really have any way to reliably work around it. Feel free to vote on the bug to try to hasten its fix. https://bugzilla.mozilla.org/show_bug.cgi?id=737852
It seems most browsers are pretty consistent with the baseline these days, but in CreateJS the difference seem to have increased. Is there something in the code to compensate for the differences which is now basically overcompensating?
It seems only 'middle' and 'alphabetic' are consitent in CreateJS.
To compare different browsers I used: https://www.w3schools.com/TAgs/playcanvas.asp?filename=playcanvas_textbaseline&preval=top
I can't speak to Animate's availability, as Adobe would have to bring in new EaselJS builds themselves. We are hoping that 1.0 is incorporated into a future build of Animate at least, but it won't address that.
Thank you, in that case we'll point to createjs latest release. Also my colleague proposed a solution over stackoverflow if you're interested. It's working ok, just worried about performances
We've observed that "alphabetic" is consistently implemented (in the browsers and versions in our tests). So a quick workaround is to set the TextField.textBaseline to "alphabetic" and then increment TextField.y by the TextStyle.size multiplied by a constant. However that constant varies between fonts, (usually in the 1...1.25 range). Possibly this constant may be determinable programmatically for a catch-all solution that can then auto-convert "top" to a consistent and backwards compatible implementation?
The TextMetrics given by the CanvasRenderingContext2D are not widely implemented in the same way, otherwise we'd have more precise measurements
Otherwise opentype.js could be used to get information about the actual baseline positions of the font. I haven't had time to try it yet but I expect it to be a bit more intensive in the calculations, maybe not the best approach on mobile.
Activity
piksel commentedon Mar 21, 2013
Just noticed this. There is also a difference between phantomjs on windows and phantomjs on linux, but that may be due to the different set of fonts on the systems (the only font i am using is on both, but perhaps standard fonts?). Setting the textBaseline to "alphabetic" yields the same ouput on both platforms.
Seems like the difference scales with font size, so smaller text looks OK, but larger texts are askew.
gskinner commentedon Sep 25, 2014
This is unfortunately a browser issue, and we don't really have any way to reliably work around it. Feel free to vote on the bug to try to hasten its fix.
https://bugzilla.mozilla.org/show_bug.cgi?id=737852
arnovanoordt commentedon Jul 18, 2017
It seems most browsers are pretty consistent with the baseline these days, but in CreateJS the difference seem to have increased. Is there something in the code to compensate for the differences which is now basically overcompensating?
It seems only 'middle' and 'alphabetic' are consitent in CreateJS.
To compare different browsers I used: https://www.w3schools.com/TAgs/playcanvas.asp?filename=playcanvas_textbaseline&preval=top
lannymcnie commentedon Sep 5, 2017
@arnovanoordt There is no compensation in CreateJS.
lannymcnie commentedon Dec 31, 2018
Chrome 71 is inline with Firefox now, so we may consider a built-in solution.
https://bugs.chromium.org/p/chromium/issues/detail?id=607053
https://stackoverflow.com/questions/53958949/create-js-text-position-changed-after-chrome-version-upgrade-from-70-to-71/53988471#53988471
mmagnani-doxee commentedon Jan 18, 2019
Hi @lannymcnie,
the font alignment problem is also there when publishing from Animate CC.
When will the fix be available? will it be there in Animate as well?
thanks
Matteo
lannymcnie commentedon Jan 18, 2019
We are hoping for a fix in 1.x shortly.
I can't speak to Animate's availability, as Adobe would have to bring in new EaselJS builds themselves. We are hoping that 1.0 is incorporated into a future build of Animate at least, but it won't address that.
mmagnani-doxee commentedon Jan 18, 2019
Thank you, in that case we'll point to createjs latest release. Also my colleague proposed a solution over stackoverflow if you're interested. It's working ok, just worried about performances
hypersurge commentedon Jan 23, 2019
We've observed that "alphabetic" is consistently implemented (in the browsers and versions in our tests). So a quick workaround is to set the TextField.textBaseline to "alphabetic" and then increment TextField.y by the TextStyle.size multiplied by a constant. However that constant varies between fonts, (usually in the 1...1.25 range). Possibly this constant may be determinable programmatically for a catch-all solution that can then auto-convert "top" to a consistent and backwards compatible implementation?
alebianco commentedon Jan 24, 2019
@hypersurge I went with a similar approach (https://stackoverflow.com/a/54256368/645252) it's dirt cheap but it works well for most fonts and its consistent cross browser/platform
The TextMetrics given by the CanvasRenderingContext2D are not widely implemented in the same way, otherwise we'd have more precise measurements
Otherwise opentype.js could be used to get information about the actual baseline positions of the font. I haven't had time to try it yet but I expect it to be a bit more intensive in the calculations, maybe not the best approach on mobile.