Very small text is badly positioned

135 views
Skip to first unread message

mattl...@live.com

unread,
Jul 31, 2020, 6:59:22 AM7/31/20
to skia-discuss
Just noticed that very small text sizes (1 - 3)  are badly positioned. Most probably due to floating point losses.


I will look into this some more, but I was wondering if there was some property that should be set or some alternate pattern that should be used.

I know that skia has been moving away from string rendering, but this was working properly in m68 at least. Not sure if this is a bug that I should open, or a known issue?

mattl...@live.com

unread,
Jul 31, 2020, 7:26:49 AM7/31/20
to skia-discuss
I did a test on a few platforms, and it appears it is only the freetype platforms with issues:
  • Win32 ✔
  • UWP  ✔
  • macOS  ✔
  • iOS  ✔
  • Linux (assuming this for fiddle) ❌
  • Android  ❌

Ben Wagner

unread,
Jul 31, 2020, 11:00:10 AM7/31/20
to skia-d...@googlegroups.com
What you're seeing here is hinting being scaled up. By default things
are set up so the DirectWrite and CoreText generally aren't hinting
the metrics (though they still may with some fonts). The
implementation of drawString gets the glyph metrics from the font
object (which is a size 1 with normal hinting) and then creates the
text blob with those metrics. This text blob is then scaled up and
drawn. The glyphs are drawn with the scale known and aren't actually
size 1 with normal hinting scaled up (which is something I don't think
we directly support at the moment, though you might be able to emulate
it by getting paths and scaling those up).

In theory drawString could take the matrix into account when getting
the glyph metrics, however it's something of a test only method anyway
(at least at the moment it makes no attempt to do any proper shaping
or anything beyond simple char to glyph mapping). At the moment the
right thing to do for such test string printing would be to set
'font.setLinearMetrics(true);' which will get the linear glyph metrics
which can scale freely (and maybe set the hinting to slight or none if
you want the glyphs to match).
> --
> 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/b76e4832-771c-4859-8171-a9cd041536aan%40googlegroups.com.

Mike Klein

unread,
Jul 31, 2020, 11:13:04 AM7/31/20
to skia-discuss
Let's assume we leave drawString() alone, or even remove it to prevent others from falling into this same trap.

What flow would you suggest here instead of drawString()?

Mike Reed

unread,
Jul 31, 2020, 11:21:30 AM7/31/20
to skia-d...@googlegroups.com

Mike Klein

unread,
Jul 31, 2020, 11:25:30 AM7/31/20
to skia-d...@googlegroups.com
Oh ok, so there’s no way we’ve got at the moment to recreate that “in theory...” path that would take the CTM into account?

Mike Reed

unread,
Jul 31, 2020, 1:29:18 PM7/31/20
to skia-d...@googlegroups.com
We would need to support positionless textblobs -- we used to have that idea, but no one (afawk) used/needed it, so we removed it.

Reply all
Reply to author
Forward
0 new messages