I forgot to attach the patch. Duh.
diff --git a/include/freetype/ftautoh.h b/include/freetype/ftautoh.h
index cf7b76f..68d59e7 100644
--- a/include/freetype/ftautoh.h
+++ b/include/freetype/ftautoh.h
@@ -439,6 +439,36 @@ FT_BEGIN_HEADER
*/
+
No, unless FT_Outline_Embolden() does that, then yes ;)
`FT_Outline_Embolden' *does* change the advance width! You have to
save the metrics before the call, then restoring the original values.
Don't you mean experimental FT_Glyph_Embolden?
___
A similar argument holds for `af_latin_metrics_init_widths': Only
the stem width measured along the vertical axis is used for light
hinting.
Meaning, I'd have to modify AF_*Metrics to also compute stem widths
on the horizontal axis and use that for stemWidth?
I don't think so. Since we
stem width measured along the vertical axis == stdHW?
Yes.
I was thinking about refactoring the emboldening out into a kind of
service that font drivers can use internally when they promise to
hint Y only. But I know too little about FT's internals yet to
judge if this is actually a good
1. The function to compute how much darkening to apply is a crude copy-pasta
of the real thing in cff/cf2font.c
Is this the one with four parameters? I do not understand why it has to be so
complex. I am not a big fan unless someone can explain it?
On 15-08-21 11:37 PM, Nikolaus Waxweiler wrote:
@Werner: What keeps the subpixel hinting code from being turned on by default?
It's extremely slow apparently... Needs someone to study it in detail and
make it fast.
___
Freetype-devel mailing list
Hi list,
so I just finished a very rough prototype for stem darkening for the
autohinter. This is not meant for inclusion into master but rather as a
starting point for discussion. Apply patch against master.
The code has numerous problems:
1. The function to compute how much darkening to
On 15-08-21 07:35 PM, Werner LEMBERG wrote:
Same here! Also, it currently mishandles glyphs that have outer
contours with differing directions...
Example call, please.
Here you go. Attached.
behdad
test#1.ttf
Description: application/font-ttf
I just noticed that the darkening calculation might be off, making stuff
excessively bold. Here's a new patch. Sorry :(
diff --git a/include/freetype/ftautoh.h b/include/freetype/ftautoh.h
index cf7b76f..68d59e7 100644
--- a/include/freetype/ftautoh.h
+++ b/include/freetype/ftautoh.h
@@ -439,6
One thing we need to figure out before this goes out is, this will
be introducing drastic weight differences between unhinted,
autohinted-light, autohinted-medium+, and bytecode-hinted. That's
not very good. I think at least unhinted should get the same boost,
unless turned off explicitly.
`FT_Outline_Embolden' *does* change the advance width! You have to
save the metrics before the call, then restoring the original
values.
Don't you mean experimental FT_Glyph_Embolden?
Oops *blush*. Please forget what I've said :-)
Werner
1. The function to compute how much darkening to apply is a crude
copy-pasta of the real thing in cff/cf2font.c
Is this the one with four parameters? I do not understand why it has
to be so complex. I am not a big fan unless someone can explain it?
I haven't yet looked closely at the new
12 matches
Mail list logo
