Comments (6)
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 infontdue
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
RazrFalcon/ttf-parser#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.
from fontdue.
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.
from fontdue.
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.
from fontdue.
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.
from fontdue.
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.
from fontdue.
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.
from fontdue.
Related Issues (20)
- C interface HOT 6
- Fonts with variable weight? HOT 2
- Adding an example for calculating the bounding box HOT 8
- can fontdue rasterize with fractional pixel offsets? HOT 5
- SDF texture generation HOT 1
- Ligature support- pairing with other libraries
- Rasterize a whole string HOT 3
- Glyph metrics are incorrect HOT 1
- Font line metrics don't match character metrics
- Png Support HOT 1
- How to rasterize colored emojis HOT 1
- Can you add an example of how to create a simple letter and save as a font? HOT 1
- Option to drop the rest of a line instead of wrapping HOT 2
- Bounding box of laid out text for easy shiftnig of the origin?
- Misaligned pointer dereference in `get_bitmap` HOT 4
- Custom font colors HOT 1
- Live demo error when a glagolitic character ( Ⱆ ) is used HOT 3
- 0.7.4 is a semver break HOT 3
- Slight layout performance regression
- No ability to query font for its name HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fontdue.