Hello,
I'm using Freetype along with a custom rasterizer (based on Antigrain's) in
my app.
I have a few questions as well as some thoughts I'd like to share.
1. my rasterizer doesn't use horizontal hinting at all, only vertical.
Again, this was proved to work well in Antigrain's test rasterizer. Even
though there's a tiny bit of clarity that's lost with no horizontal hinting
(& I mean none, not 1/3 pixel), text gets much clearer to read when
inter-character spacing is fully preserved. It's combining 3-pixel wide
cached masks with blended subpixelling.
One problem that I originally thought to be linked to this [Freetype being
told to rasterize a very wide character so that horizontal hinting is
visibly bypassed, but later I found out that Freetype's own sub-pixel mode
had the same problem] is that vertical hinting changes a font's aspect
ratio. It's quite normal afterall, at small sizes a character can be +-1
pixel tall, which corresponds to up to 20% of the character's size for
small sizes. I wanted to compensate for this, but I'm not sure it even is
possible. Afterall, it's not the WHOLE character that changes in size, but
some bars in it. Still, let's assume that we'd take the size of a lowercase
or an uppercase, could it be compared to the original, unsnapped height, &
a compensation factor be computed from that?
But is that original height even available? I had a lot of troubles with
font metrics, especially for text centering & alignment, it's still not
quite over (I was using the font's bounding box for best results because
the font's height seemed quite unreliable, & now I realize with Windows 8
that Segoe UI got its bounding box changed while its metrics didn't change
at all, only because they added some glyphs).
This is not a big problem, only slightly annoting. I was used to the aspect
ratio of the great Segoe UI as I was using it at small sizes, & on a
high-PPI screen it got wider ("as designed") & not so cool anymore. Of
course if I managed to do the compensation, it's the small size that'd get
wider, but I'd just compensate with my own aspect ratio (which is no
problem with no horizontal hinting).
2. hinting. I quite like Freetype's autohinting, even for fonts that are
supposed to have a great hinting actually. I prefer the way it only snaps 1
edge when the thickness is over 1 pixel, it looks better & there's no jump
in thickness.
However, for symbols, the autohinter isn't always reliable. For example, if
you wanna paint a checkbox that's a composite of a circle & a disk in 2
separate glyphs, you can't have any kind of autohinting (or hinting at all)
here, as the disk has to look properly centered inside the circle.
Problem is, how to combine Freetype's autohinting with the font's own
hinting inside the same font? There doesn't seem to be a hinting mode that
would mean "Autohinting when there is no hinting instruction for a glyph,
otherwise use the glyph instructions".
Does Freetype provide info about a glyph's hinting instructions so that I
could check it & change the hinting method accordingly?
What also makes me wanna use the autohinter more is that apps that offer
hinting out there seem quite rare. I'm using FontForge & having troubles
with it.
3. halftoning.
It's a bit sad that, while a common font caching nowadays is based on alpha
masks, we can't get halftoning from fonts. Some will say that it's an
heresy, I'd say that wanting a multicolor font might be an heresy (even
though you could still change its hue/brightness/saturation which is still
useful enough), there's absolutely nothing against halftoning in a font
glyph.
The problem is the implementation. I've read about support for this in some
font format (can't remember) that's not widely supported. I know that
halftoning can be faked using a halftoning grid, which is even less of a
problem when you can predict the maximum size your glyphs will have on
screen. But this method is very.. hinting unfriendly, so not really an
option for me (even less with the autohinter enabled).
So I was wondering what kind of hack would work.. one idea would be to
build cached glyphs out of several glyphs. That is, one character would be
the opaque one and the next one would be the half-transparent one, & both
would be merged into the same cache. But there's still the problem of
marking a symbol glyph as having a twin somewhere (possibly the kerning
table could be used for this, & the spacing could be used to define a
transparency level), and autohinting is still a problem (but not internal
hinting!).
It's a problem on different sides: the font editor that'd have to provide
some way to mark a path as transparent, one that survives in the TTF that
is (could be path direction? It'd be limiting, but better than nothing). It
would also be a problem of retrieving the path from Freetype itself, as I'm
using Antigrain to do the actual rasterizing.
There are 2 reasons I'm "going vectorial", it's that I can't imagine PC
desktop monitors will lag behind tablets for so long, it's "only" for
legacy reasons that we're not seeing high-density PC desktop monitors yet.
And also because today's style is vectorial, both Windows 8 & the new iOS
showed that flat was great.
Any help or comments? Thanks
_______________________________________________
Freetype-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype-devel
