Giters

nothings / stb

stb single-file public domain libraries for C/C++

Home Page:https://twitter.com/nothings

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

stb_truetype.h: letter T has rasterization artefacts for Roboto-Regular.ttf

rds1983 opened this issue · comments

commented

Describe the bug
stb_truetype.h: letter T has rasterization artefacts for Roboto-Regular.ttf

To Reproduce
Steps to reproduce the behavior:

  1. Unpack attached sample: StbTrueTypeBug.zip
    It rasterizes letter 'T' and then saves the result in PNG.
  2. Run CMake.
  3. Update inputPath/outputPath in the main.c
  4. Open generated result.png and observe the artefact: it looks like cross, rather then T
    image

Expected behavior
It shouldn't be cross, but T.

It works correctly when stb_truetype.h if compiled with #define STBTT_RASTERIZER_VERSION 1

image

commented

I assume this is a one-pixel-wide error that you're blowing up with bilinear resampling hence the blurriness? In this sort of scenario (debugger/reporting bugs) you should generally resize with nearest-neighbor ("fat bits") so the actual pixels can be seen, without the bilerp blurring confusing things, or at least mention that this is what you're doing instead of saying that THIS is the actual output. Always, always think about what information the library maintainer has and needs to understand your problem. (If this is what text actually looks like in your application, you're using it wrong.)

Anyway, this is an expected difference between the old rasterizer and the new rasterizer if the font is not defined "correctly", that is in the way that TrueType fonts are traditionally defined (but not actually part of the spec).

Specifically, this is the behavior you would get if the T was defined as two separate overlapping rectangles; the pixels where they overlap will be "double darkened" in the new rasterizer, which doesn't affect the opaque pixels inside the shape, but does affect the AA edge pixels.

Traditional TrueType fonts define a single contiguous outer border, rather than overlapping shapes, as this allows things like classic-style "outline" text effects to be created by simply drawing the lines defining the shape. If my guess about what's going on here is correct, those effects would also not work correctly with that method. However, I'm not sure if there are any modern programs that do that that would demonstrate the effect.

I switched to the new rasterizer on the assumption that fonts that violated this rule were rare, which seems to be true since this is one of very few (or maybe the only) reports of this issue. So I believe this is working as intended, and switching to the old rasterizer is the appropriate solution if you need to use fonts that don't follow these rules and that produce objectionable one-pixel-wide artifacts. It literally cannot be fixed in the new rasterizer.

commented

I see, thanks for the thorough explanation.

commented

Just wanted to clarity that those pics arent from my application, but from the attached sample. And the attached sample simply rasterizes letter 'T' and then saves it as PNG. Which I then opened in the Windows Photos and zoomed. That where those pics came from.

Happy New Year!