Font size and layout not quite right

[8bitslime]

It seems like that Fontdue's rasterized characters are just a little smaller than that of Firefox or Chrome. Also, using the Roboto font, the lowercase 'i' is very noticeably different.

I made a little test where I laid my program over Firefox, both using Roboto-Regular, 40px.

It looks like the character advance and line height aren't quite right. Does Fontdue support kerning? Also, will we be able to change the line height in the future? I couldn't find anything related to these in the docs.

[mooman219]

Glyph differences:

• On windows you're using direct write which does make text look thinner and crisper. You can get the raw coverage data you need to generate RGB subpixel rasterized glyphs via the rasterize_subpixel function, but it is moderately difficult to render it correctly unless you're prepared to dive into a lot of color math to blend it correctly in your shader. This can't be made easier in fontdue because the work required to make it blend correctly needs to be done in the shader.
• Red is always gonna look worse than black

No changes planned here.

Layout differences: Fontdue layout adds more padding than is required for two reasons:

• This was a trade-off for having smaller texture caches because subpixel offsetting means more glyph variations. There is support for it internally but I haven't exposed it yet because my attempts at making a nice API made it easy for users to get it wrong and have worse looking text.
• I was being defensive to make the text more readable.

Planned changes:

• Subpixel offsetting, need to make this dummy proof
• Kerning, I need to PR support to ttf-parser https://github.com/RazrFalcon/ttf-parser/issues/55
• More misc layout options. Overall I think we're better than glyph_brush_layout already

Philosophy differences: Fontdue is just aiming to be the best high level, pure rust solution, competing with ab_glyph/rusttype/glyph_brush_layout. Its target audience is embedding in games, web, kernels, and other no-std environments where spinning up something like FreeType isn't trivial. Its API is designed to have you think about the details as little as possible. It's never going to be browser grade.

[8bitslime]

The example here was just rendering with greyscale AA, no subpixel. I will admit that I know very little about text rendering, but when I tried subpixel glyphs, the red and blue sheens looked very exaggerated giving black characters a more pinkish hue. Blending was done in OpenGL per this StackOverflow answer. If you have any resources on learning the proper color technique that would be much appreciated. I am also on the hunt for resources on how browsers render text, at least at the high level. My implementation just caches all visible glyphs in a texture atlas, but I'm starting to think that may not always be ideal.

Altogether I think that Fontdue looks incredibly good, especially for the performance. It may be foolish of me to attempt getting somewhere near browser-quality text, but to be honest, just the greyscale glyphs are very close already.

[mooman219]

the red and blue sheens looked very exaggerated giving black characters a more pinkish hue ... you have any resources on learning the proper color technique that would be much appreciated

Here's a very old but relevant primer http://agg.sourceforge.net/antigrain.com/research/font_rasterization/ . If you come across anything Microsoft patent related, most of those expired last October.

My implementation just caches all visible glyphs in a texture atlas, but I'm starting to think that may not always be ideal.

You might want a proper cache with eviction, but that doesn't sound bad in a pinch!

Altogether I think that Fontdue looks incredibly good, especially for the performance.

Thanks! It's even better than the browser in terms of linearization and because it's an exact coverage raster (at the cost of spicy Font::new times), but a lot of the last mile stuff outside of rasterization that affects perceived quality isn't quite there yet.

[8bitslime]

That read into the wonderful world of subpixel positioning was very interesting. It makes me very eager for subpixel offsetting in Fontdue. GlyphPositions from the layout manager use floating-point x and y positions, but the docs say it only returns whole numbers, is it planned to make those also support subpixel coordinates as well? All of that combined with kerning could make for some very nice looking text.

[mooman219]

Those will always be whole numbers, even with subpixel positioning. They're the coordinates to place the rasterized image, which is always aligned to the pixel grid.

i.e. if the glyph 5 pixels wide needs to be placed at X: 45.5, then the GlyphPosition X will be 45 and width will be 6. The position is floored to 45, and the offest is applied at raster time and will be baked into the image, making the image 0.5 pixels wider by adding 0.5 pixels of padding to the left side, and then the width is ceiling'd. This is the only way to maintain exact coverage data. Fontdue has the geometry at raster time so subpixel offsets are trivial.

The consequence of this is that you'll be caching new glyph textures for each possible subpixel offset. The letter 'a' will look different if it's offset by 0.1 or 0.2 pixels. Therefore fontdue will need to also have API for a tolerance such that you as a user can say "I was a maximum of X variations per glyph" so you can cache efficiently.

[8bitslime]

That makes sense. Does Fontdue already do this? I can't tell just from reading the source code. I think proper kerning and subpixel positioning as well as more layout options like line height and adjustable character spacing is basically everything I want out of this issue. For my particular use case, I'm trying to make a very professional looking UI just for my own amusement.