Glyph vertical alignment issues

[DMartinek]

Hi everyone!

First thanks for your great work on this library it really helps a lot when developing UIs in VR.
Unfortunately I hit an issue related to fonts. It seems that for some fonts the glyph positioning/metrics aren't correct. The json files generated by the online converter seems to be fine (I also tested it with some of the offline tools, but get the same issues). In my case the error happens with the IBM Plex font but I was able to replicate it with Open Sans too.

It seems that glyphs aren't correctly aligned vertically (and also the horizontal and line advances seem too big).:

This is the same application using the online converters default font (yahei), which doesn't exhibit the issues:

I also tried various options (like kerning/no kerning) etc. but nothing seems to help. The preview of the fonts in the online conversion tool also displays the font correctly.

Did someone else experience something similar? Is it possible that there is some user error on my part, or could there be an error in the libraries font handling?

[swingingtom]

Hello @DMartinek , AFAIK this is indeed possible to notice some glyphs vertically mislocated, but this is per glyph only.

( "i" and other characters are slightly above the baseline )

I've reexported YaHei from the same online converter.

I can also notice the "i" and "s" above the baseline.

In the provided pictures, we can notice that the whole text is progressively offseting itself. And that Im currently not able to reproduce. At first sight, it might look like the camera perspective deformation, or the text or one of its parent has a slight rotation. Try to place the text in front of the camera to see if it can help.

[DMartinek]

Hi @swingingtom,

thanks for trying to replicate this. Yeah sorry the provided pictures were directly from an application with a perspective camera that's maybe why it seems to get worse over time.

I've added some lines to show the issue more clearly. Some glyphs that descend below the base line like the 'g' seem to be offset a lot more than others.

It also seems strange that the line height seems to be wrong with that font while it works fine with others:

I'm not sure if it is allowed to directly share bitmapfonts due to licensing so I rather not post the files here but I can send them to whoever is interested in replicating the behavior. You can also simply get the font from https://github.com/IBM/plex (I use the sans regular version) and use the online msdf converter to convert it using the following characters:
azertyuiopqsdfghjklmwxcvbnAZERTYUIOPQSDFGHJKLMWXCVBN/\*-–+7894561230,;:!?.%$£€={}()[]&~"'#_|°@АаБбВвГгДдЕеЁёЖжЗзИиЙйКкЛлМмНнОоПпРрСсТтУуФфХхЦцЧчШшЩщЪъЫыЬьЭэЮюЯяüÜöÖäÄñÑςερτυθιοπασδφγηξκλζχψωβνμΕΡΤΥΘΙΟΠΑΣΔΦΓΗΞΚΛΖΧΨΩΒΝΜåÅæÆøØ™©®

[swingingtom]

This could indeed comes from the library, and is intensified by a specific font.

Some toughts I could be totally wrong about
Exported fonts are usually in with a font size of 42. Where 48 might be more divisible. Size are also usually exported in integers, so some precision could be lost/rounded during the process.

@felixmariotto do you have leads on this? I noticed that anchor is no more used. Is that a lead?

[felixmariotto]

@swingingtom anchor is used here. It's computed here from the font JSON, honestly I'm not sure what could be wrong.. It would be interesting to use the generated files in another tool, to see if the problem comes from upstream.

[felixmariotto]

A-Frame optionally uses MSDF font files, and their doc lead to the same converter.

Here is an A-Frame codepen comparing their default font and our default font (I linked to this repo's files using unpkg).
I had to use underscores instead of whitespaces because for some reason A-Frame will replace our whitespaces with "m"...

@DMartinek it would be great if you could fork this codepen to show what happens when using the font that has an issue in three-mesh-ui. This way we would know if the issue comes from the converter or from three-mesh-ui.

[DMartinek]

Hi,

I actually just had the same Idea 15 min ago and tried to use my font in A-frame (had the same issues with the spaces...). It seems that they render the font fine:

I will try to add my font to the codepen to see a direct comparison.

Edit:
Added the font to the codepen and it renders fine as well:

[swingingtom]

@swingingtom anchor is used here. It's computed here from the font JSON, honestly I'm not sure what could be wrong.. It would be interesting to use the generated files in another tool, to see if the problem comes from upstream.

my bad. sorry.

I did some export from command line. Font size 48, with 2 decimals. Nothing really helped :/

[swingingtom]

Whereas not being able to identify the origin of this issue, 7.x.x would contain a tool to help us to fix those disagreement : https://felixmariotto.github.io/three-mesh-ui/7.x.x/#ex__baseline

[ROBYER1]

From the issue mention, I am having similar issues with this font attached
Saira_Condensed-SemiBold-msdf.zip

See comparison between the MSDF converter and three-mesh-ui

[swingingtom]

This has been fixed on v6.5.3
Alignment on msdf exported font are from top.

The result can be seen here https://codesandbox.io/s/glyphs-vertical-issues-vunz9
By switching three-mesh-ui version from v6.5.3 to v6.5.2 we can see vertical alignment respected.

Rye font is pretty handy as it has "matching spikes"
Not aligned (6.5.2)

We can notice that spikes of "p" don't match other spikes.

Aligned (6.5.3)

All spikes are aligned.

as @DMartinek said, it was especially noticeable with Saira font

We can also note a difference of character size.

Unfortunately, it doesn't fix alignment issues in Roboto.