Text cursor position is incorrect after changing fonts (using font face observer)

[blobinabottle]

Version

2.0.1

Test Case

http://jsfiddle.net/blobinabottle/xsLgppan/16/

Steps to reproduce

Change the text to Roboto and check last words of the fist line, the text cursor got an incorrect position.

It's worst if you select pacifico (I'm selecting SIT :-)).

Expected Behavior

Cursor should be a the right position.

Is there anything to do to avoid this situation? I tried clearFabricFontCache but not sure I've done it right.

[blobinabottle]

fabricjs.com/loadfonts it's the same issue in this demo, just by switching to pacifico.

[blobinabottle]

The only way to get it working correctly I found, is by bypassing the cache system in the text:
http://jsfiddle.net/blobinabottle/xsLgppan/42/

Is that really important for perf? When is it called?

[asturur]

Very weird.
What do you mean bypassing the cache system? that you return always empty object and force fabric to calculate every time?

I do not understand whey calculation should fail just from the cache.

[blobinabottle]

yes in my getFontCache, I always return empty object... But I don't understand why it's working like that.

[blobinabottle]

Ok the culprit is here. We change the fontCache[_char] and I see this value changing with no reason for the same character in a same text block :

// try to fix a MS browsers oddity
        if (kernedWidth > width) {
          var diff = kernedWidth - width;
          fontCache[_char] = kernedWidth;
          fontCache[couple] += diff;
          width = kernedWidth;
        }

If I comment this it's working.

[asturur]

What is weird is that it does not happens with all fonts.
Pacifico is a particular weird font.

Look this gif i recorded

As you can see each gliph change to follow the next one, is like a kerning, inverse. This may bring to some kind of problem in measurement logic.

But needs to verified

[asturur]

Maybe when we measure the single char we should measure it with a space in front?

[blobinabottle]

yes I see what you mean, but I think the font measurement is correct.
When the IE fix is removed everything is working fine (didn't get it again with many different fonts). Not sure to understand what the IE fix is doing ?

[asturur]

can you show me here the IE fix?

[blobinabottle]

It's in _measureChar method. I can't find it in GitHub UI (only in the raw file if I search for "// try to fix a MS browsers oddity")

[asturur]

just make a copy paste of your file, for reference here.

[blobinabottle]

jsfiddle.net/xsLgppan/72/ I updated the fiddle with the change.

[asturur]

i m sorry you already posted the fix here:

// try to fix a MS browsers oddity
        if (kernedWidth > width) {
          var diff = kernedWidth - width;
          fontCache[_char] = kernedWidth;
          fontCache[couple] += diff;
          width = kernedWidth;
        }

so what is happening is that MS measure fonts in pixels.
So a font of 11.1 is big 11 a font of 11.9 is big 12
Sometimes kerned Width was a little bit bigger because:

a = '11.3' => 11
b = '11.3 => 11

ab = 22.6 => 23

b kerned was then ab - a = 12.

and this was normally wrong.

But we see that with pacifico this is a possible use case.

So we need a better logic.

[blobinabottle]

Okay I understand now. So a little difference accumulates on long lines even with simple font like Roboto. And I see some discussion about it already happened long time ago :D Automattic/node-canvas#331

[blobinabottle]

Are you sure this fix really worth it? Testing on IE without the fix, and this is the worst I can get in terms of offset... Very small.

[blobinabottle]

With font yellowtail on IE 11.0 with the fix, it's pretty bad. Without it it's working quite well.

[asturur]

After that fix i inserted another safety measure about ie

CACHE_FONT_SIZE = 200

so i measure everything at 200 so that rounding measurement are a bit killed in this way.
i think i can bump it up to bigger and remove the IE fix maybe.

[blobinabottle]

indeed. And this is a smarter fix than the other condition

[asturur]

LOL is easy to say what fix is smarter when you did not had to find them in the first place :D :D :D :D

[blobinabottle]

:-D In fact you already fixed all the bugs in advance, you just forget you did it :-D