Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Calculate width of text filled with only (or mostly) whitespace #10

Open
CalvinLeGassick opened this issue Jul 9, 2020 · 4 comments
Open

Comments

@CalvinLeGassick
Copy link

CalvinLeGassick commented Jul 9, 2020

Is there a way to get text-metrics to include every whitespace when computing the width of a string?

With strings that are all whitespace or mostly whitespace, the width that text-metrics produces seems to be computed after stripping out whitespaces. At the least, the width results are smaller than when I just compute the width of the string using canvas.measureText. Here's an example of the mismatch:

https://codesandbox.io/s/text-metrics-whitespaces-mzgh2?file=/src/index.js

Am I just missing some CSS prop I need to pass to text-metrics to get it to understand how I want it to treat whitespaces?

I expected passing in pre or break-spaces to white-space would do this trick but it did not. Is it possible this "if block" should add whitespace to the line string before continue-ing if certain white-space values are present?

if (BAI.has(parts[i - 1]) && BAI.has(parts[i])) {

Also, I did see this issue but could not find the trim() culprit that was mentioned. The trim in normalizeWhitespace looks like it doesn't trim if white-space: pre is used, so I would think that should be fine.

export function normalizeWhitespace(text, ws) {

@bezoerb
Copy link
Owner

bezoerb commented Jul 15, 2020

Hey @CalvinLeGassick, thanks for the detailed issue :)
It looks like line 464 is causing this unexpected behavior. Good catch! I think maybe this if block could be removed at all as the whitespace already get's normalized in normalizeWhitespace.
Do you like to try and create a PR?

thanks

bezoerb added a commit that referenced this issue Apr 28, 2021
@bezoerb
Copy link
Owner

bezoerb commented Apr 28, 2021

@CalvinLeGassick : This should be fixed in v2.0.9

@benshabatnoam
Copy link

I'm not sure, but it looks looks like this should be a closed issue, as v2.0.9 contains a fix for it...
Anyway, I got to this issue because I'm having this problem with v4.0.1, therefore my question is do you think this issue became a regression in my version? thanks

@adamatronix
Copy link

I am also facing this issue. Even in 2.0.9 trailing spaces aren't being calculated propery.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants