Getting rounded off widths for glyphs, which is causing uneven spacing between the characters

160 views
Skip to first unread message

Sonaali Mittal

unread,
Sep 24, 2019, 2:54:43 AM9/24/19
to skia-discuss

Hi, 
From the version m74 onwards we started getting this issue of uneven spacing between characters:

Screenshot 2019-09-24 at 11.59.43 AM.png
We realized this is happening because of getting integer values for the widths of individual glyphs, through the method `SkFont.getWidthBounds()` even though we give skScalar array for the values.

For example, we get following widths for Roboto font for font-size 38:

22.000000, 10.000000, 9.000000, 13.000000, 22.000000, 20.000000, 13.000000, 20.000000, 20.000000, 

and for the same characters, for font-size 19, we get 
10.000000, 4.000000, 5.000000, 7.000000, 10.000000, 10.000000, 7.000000, 10.000000, 10.000000
Similarly for bounds as well.

Earlier (in m72), we used to get proper decimal values of the widths(without the rounding off), and the positioning of the glyphs was hence working fine

On trying to log those values in the skia code, it perhaps seemed to me that in the method `SkScalerContext_FreeType::generateMetrics()` the values of `fFace->glyph->advance.x` are being set in such a way that `SkFDot6ToFloat()` method always returns an integer value.

I want to ask you if this change in the width values and bounds' values- is the expected behavior? If so what is the workaround for proper spacing of the characters?

Thanks,
Sonaali

Hal Canary

unread,
Sep 24, 2019, 9:13:07 AM9/24/19
to skia-discuss
What is SkFont::isSubpixel() set to?

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/e4f52ba5-7c10-4b70-b1e0-c926e5016f6c%40googlegroups.com.

Ben Wagner

unread,
Sep 24, 2019, 10:54:45 AM9/24/19
to skia-d...@googlegroups.com
I imagine what is happening is that you used to set SkFont::setSubpixel(true) (to allow for subpixel placement of the glyphs) and this used to also force linear metrics. If you want to force linear metrics you can now use SkFont::setLinearMetrics(true). If you want even spacing and glyphs without hinting you probably want to set SkFont::setHinting(SkFontHinting::kNone). I believe the issue you are seeing here is that various early versions of Roboto are rather poorly hinted and just look like that when hinting is enabled (which is probably why you're getting integers for the advances). If you provide the exact version of Roboto you are using (which really means provide the file itself, since the version wasn't always updated well) I can take a look and make sure it's actually the font.

Sonaali Mittal

unread,
Sep 24, 2019, 1:38:02 PM9/24/19
to skia-discuss
Yes we are indeed setting SkFont::setSubpixel(true) - though I'm not aware of why we do that. I'm reading up to understand more about the properties you mentioned. Attached though the roboto-font file that I'm using.
Thanks



On Tuesday, 24 September 2019 20:24:45 UTC+5:30, bungeman wrote:
I imagine what is happening is that you used to set SkFont::setSubpixel(true) (to allow for subpixel placement of the glyphs) and this used to also force linear metrics. If you want to force linear metrics you can now use SkFont::setLinearMetrics(true). If you want even spacing and glyphs without hinting you probably want to set SkFont::setHinting(SkFontHinting::kNone). I believe the issue you are seeing here is that various early versions of Roboto are rather poorly hinted and just look like that when hinting is enabled (which is probably why you're getting integers for the advances). If you provide the exact version of Roboto you are using (which really means provide the file itself, since the version wasn't always updated well) I can take a look and make sure it's actually the font.

On Tue, Sep 24, 2019 at 9:13 AM Hal Canary <halc...@gmail.com> wrote:
What is SkFont::isSubpixel() set to?

On Tue, Sep 24, 2019, 2:54 AM Sonaali Mittal <sonaal...@gmail.com> wrote:

Hi, 
From the version m74 onwards we started getting this issue of uneven spacing between characters:

Screenshot 2019-09-24 at 11.59.43 AM.png
We realized this is happening because of getting integer values for the widths of individual glyphs, through the method `SkFont.getWidthBounds()` even though we give skScalar array for the values.

For example, we get following widths for Roboto font for font-size 38:

22.000000, 10.000000, 9.000000, 13.000000, 22.000000, 20.000000, 13.000000, 20.000000, 20.000000, 

and for the same characters, for font-size 19, we get 
10.000000, 4.000000, 5.000000, 7.000000, 10.000000, 10.000000, 7.000000, 10.000000, 10.000000
Similarly for bounds as well.

Earlier (in m72), we used to get proper decimal values of the widths(without the rounding off), and the positioning of the glyphs was hence working fine

On trying to log those values in the skia code, it perhaps seemed to me that in the method `SkScalerContext_FreeType::generateMetrics()` the values of `fFace->glyph->advance.x` are being set in such a way that `SkFDot6ToFloat()` method always returns an integer value.

I want to ask you if this change in the width values and bounds' values- is the expected behavior? If so what is the workaround for proper spacing of the characters?

Thanks,
Sonaali

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-d...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-d...@googlegroups.com.
Roboto-Regular.otf

Sonaali Mittal

unread,
Sep 25, 2019, 3:44:54 AM9/25/19
to skia-discuss
Hi!
As you said that this issue might be font-file specific, I realized that this is happening for me for only specific devices. We use skia to render on various Android devices and when we don't have a specific font, we look into the system fonts and use them for the rendering. (in the previous message, I seem to have shared with you the font file which was working fine in terms of the spacing. attaching the one causing the issue in this one). 
So I tried setting hinting-off (or kNone) and it started working perfectly. 
But my question here is, is it okay to set hinting off for all the fonts that we might use (on all Android devices)? If not, how may we make the decision?
Also, the same question for sub-pixel positioning - should we always set it true/false, or if not what should we base the decision upon?
Thanks a lot for your help,
Sonaali
Roboto-Regular.ttf

Ben Wagner

unread,
Sep 25, 2019, 11:26:56 AM9/25/19
to skia-d...@googlegroups.com
This second Roboto-Regular (the .ttf one) actually has no hinting in it at all, and states that it is modified by Samsung. The first Roboto-Regular (the .otf one) is actually hinted quite a bit and is generally more complete, it claims to be a version which Google released. As a result of this, this may be an issue with the autohinting? I'll need to investigate that now that we've worked out many of the other issues in this area. If you change the hinting to 'SkFontHinting::kSlight' and you are compiling in a fairly new FreeType I think you'll also have good results.

In general you probably always want sub pixel positioning. There's probably not a lot of downside to using kSlight hinting, I would use kNone if you treat the text more like graphics and less like legible text (expect it to scale uniformly). Ideally, you wouldn't be running ito this issue and could just use the normal default. I'll try to take a look into if we need to take more information into account for the text metrics.

To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/c71ba8a6-4ca7-48bc-acc3-2135eeb0d50d%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages