servo / servo/font-kit

Pixels cut off of some characters in `render-glyph`

Open
#253 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
840
Forks
137
Avg merge
4h 56m
Merged PRs (30d)
1

Description

For some glyphs, pixels seem to be cut off in the render-glyph example (mostly, or only with subpixel rendering).
For example: '!'. Here it is only four pixels wide.

image

The glyph should normally look like this when rendered using the same settings to a larger canvas:
image
Here it is 5 pixels wide.

I believe this must be because the glyph size returned by raster_bounds() differs from rasterize_glyph() in Freetype.
Looking into raster_bounds(), I see that it does not pass any hinting information to the underlying typographic_bounds() function, but even if those are supplied, the size of the bitmap returned by raster_bounds() still differs from the actual bitmap that is rasterized. Perhaps because raster_bounds gets the size from FT_Glyph_Metrics instead of FT_Bitmap_Size.

This issue also occurs for a couple other letters. N is pretty bad too with these settings.

Font size: 32px
Font: DejaVuSans
HintingOptions: Full
Rasterization: SubpixelAa

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the render-glyph example with DejaVuSans at 32px, Full hinting, and SubpixelAa, then inspect how raster_bounds() and rasterize_glyph() derive their dimensions. Compare the bounds with the actual rasterized bitmap for ! and N; done means no glyph pixels are clipped and the rendered glyph matches the larger-canvas result.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
computer-graphics
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
40/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.