Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
OK, how do I get at the CFF-PrivateDict SFNT table? FT_Sfnt_Tag doesn't define anything. Do I have to instantiate a CFF_Decoder? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
Hi Dave, On 8/25/2015 8:53 PM, Dave Crossland wrote: As you noted, stdHW and stdVW are normally obtained from a CFF font dictionary. For TT, we (at Adobe) estimate stem width values based on the OS/2 weight class. We use three values, light (50/1000), regular (75/1000) and bold (110/1000). I'm confused about this. If a single style family had a weight class of 400 but it's stems are much more/less than 75, will that font be darkened/lightened too much? Yes, you are correct. The heuristic I described was a compromise for a mobile rasterizer that needed to be small and simple. In a more complete Adobe rasterizer, we analyse the outlines to get a more accurate stem width value. I think the autohint code may have the necessary information to do this, too. Thanks. -Dave ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
Thanks a lot for your input, it helps to understand what the code is doing :) Maybe I'll add your comments as comments somewhere in the code ;) I now have a few ideas: - If font has OS/2 weight class, use that for stdHW/VW. See if that maybe is good enough for our purposes. - If not, use af_get_coverage or something to get at all scripts a font has glyphs for, set all available script analyzers on it, harvest all horizontal standard_widths and take arithmetic mean or median. Or something like that. - Good to know I might need different parameters! Maybe that's why I thought the autohinter results looked... less stellar than the CFF output. Smudgy on the x-axis. - Emboldening in my prototype is currently done *after* the hint computations are done, or more specifically, the analyzers that spit out hints load the glyph to be displayed by themselves to get a pristine copy of the outline. So emboldening is done independently of the hinting machinery. At least I think so. Maybe I'll try applying the emboldening before autohinting is done, in both directions, once I figure out how to get standard_widths for X/Y before metrics and hints are computed. And I want to embolden an outline for a given size only once, so that each call to FT_Load_Glyph() anywhere in the autohinter returns the already modified outline, instead of emboldening the same glyphs again and again. This might help performance if caching isn't involved (XXX: find out how caching is done in FT2/FC and what CF2_Font does) - I cam across this article yesterday via hackernews: http://www.embeddedrelated.com/showarticle/152.php -- only skimmed it, but might help me with the curve. Best regards, Nikolaus ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
On 15-08-25 04:30 PM, Alexei Podtelezhnikov wrote: On Tue, Aug 25, 2015 at 10:42 AM, Behdad Esfahbod behdad.esfah...@gmail.com wrote: On 15-08-25 03:29 PM, Werner LEMBERG wrote: On the other hand: How many recent fonts in the wild have such misformed glyphs? I saw one when developing GLyphy. Note that these are valid fonts according to TrueType spec. They just don't follow the recommended outline winding... Perhaps it's ok to ignore these. Just something to know is possible. For the record, Windows 7 rejects this font. That's probably because my subsetter was too aggressive... If this mistake was made in the letter 'O' it wold not be rendered correctly by FreeType. So this glyph *happens* to render correctly just because the outlines are not nested. Sure. That's the whole point of non-zero-winding fill rune. Testing for this is easier said than done. It easier to fix the font. lol. True. We have to fix these in GLyphy however... b ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
Same here! Also, it currently mishandles glyphs that have outer contours with differing directions... Example call, please. Here you go. Attached. Thanks. Alexei, any ideas how to fix this? Both the auto-hinter and the TrueType driver contain code to properly handle outlines with incorrect directions... On the other hand: How many recent fonts in the wild have such misformed glyphs? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
Hi On Aug 25, 2015 8:21 PM, Dave Arnold darn...@adobe.com wrote: I'm happy to see all of this activity on stem darkening in the past week. It looks like excellent progress. I'm sorry it was a period when I was on vacation and away from email. Hopefully, most questions have been answered, but please let me know if there are outstanding issues that I can help with. Thanks for all this, it's great stuff :) Here are some comments on questions that I saw in the thread that may help. Yes, unhinted glyphs are darkened, too. The need to enhance contrast at small sizes exists whether or not the glyph is hinted. There is a separate control to turn off darkening, if that is needed. The CFF code is designed to darken by different amounts in horizontal and vertical directions. The amount of darkening is determined by scaled stem width, so in a high contrast font, horizontal stems are thinner than vertical stems and need more darkening. In other words, the typographic contrast is reduced at small sizes. (This is similar to what is done for optical sizes.) There is a CFF feature called family blues that limits we darken horizontal stems. I can provide more detail if you want, but this should not apply to TrueType. As you noted, stdHW and stdVW are normally obtained from a CFF font dictionary. For TT, we (at Adobe) estimate stem width values based on the OS/2 weight class. We use three values, light (50/1000), regular (75/1000) and bold (110/1000). I'm confused about this. If a single style family had a weight class of 400 but it's stems are much more/less than 75, will that font be darkened/lightened too much? If we darken TT outlines *after* hinting, we darken vertical stems only, and we apply less darkening than we do for CFF. This is because the nature of TT hints tends to darken horizontal stems at small sizes. (Consider a scaled horizontal stem that is less than one pixel wide. Typically, the hinting will snap it to a full integer pixel, effectively darkening it.) The TT darkening amounts were tuned experimentally so the combined darkening for CFF and TT looked similar. If we darken TT outlines *before* hinting (e.g., by the autohinter) I'd expect horizontal and vertical darkening amounts could be computed separately. I'm not sure how to best estimate the stdHW or the contrast, though. It is necessary to know the direction of the paths in order to darken by adjusting the path outward. While there is a recommended direction for both CFF and TrueType, some fonts don't always follow it. There are three cases: 1. All glyphs in the font have the wrong winding order. Some font converters fail to reverse path direction when moving from CFF to TT or back. 2. Some glyphs in the font have the wrong winding order. Perhaps some glyphs are produced as reflections? 3. Some glyphs contain inconsistent subpaths; some are correct and some are wrong. The CFF rasterizer contains code to compute the winding order direction as the outline is traversed. If, at the end of the glyph outline, the winding order is as expected, then nothing extra needs to be done. If the winding order is wrong, then the glyph is re-rendered with darkening reversed. And the expected direction for this font is reversed. This means for case 1, above, only the first glyph pays a penalty. For case 2, above, a few glyphs will be rendered twice. For case 3, (very rare) we ignore the problem; some glyph components will be lightened instead of darkened. Thanks. -Dave On 8/23/2015 9:14 AM, Werner LEMBERG wrote: 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 don't want emboldening for the `strong' hinting mode (actually, we *do* want that, but this is a much harder problem to solve), you don't have to change anything along the horizontal axis. By the way, I can't directly access e.g. AF_LatinMetrics-axis-standard_width from my af_loader_compute_darkening() as I have only an AF_StyleMetrics to go from.. Is there a reason why standard_width is specific to writing class implementations of AF_StyleMetrics? I don't know. Many of the details evolved over the time... The current subpixel hinting code should already be quite near to that goal. And what keeps it from being made the default mode for the native TT fitter? Behdad has answered that. I haven't found time yet (and I probably won't in the very near future) to run a profiler on the code, fixing hot spots. Maybe this is your follow-up project? :-) Oh, and what's that about subpixel hinting in af_loader_load_glyph()? For `light' hinting mode, you can ignore that. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
I'm happy to see all of this activity on stem darkening in the past week. It looks like excellent progress. I'm sorry it was a period when I was on vacation and away from email. Hopefully, most questions have been answered, but please let me know if there are outstanding issues that I can help with. Here are some comments on questions that I saw in the thread that may help. Yes, unhinted glyphs are darkened, too. The need to enhance contrast at small sizes exists whether or not the glyph is hinted. There is a separate control to turn off darkening, if that is needed. The CFF code is designed to darken by different amounts in horizontal and vertical directions. The amount of darkening is determined by scaled stem width, so in a high contrast font, horizontal stems are thinner than vertical stems and need more darkening. In other words, the typographic contrast is reduced at small sizes. (This is similar to what is done for optical sizes.) There is a CFF feature called family blues that limits we darken horizontal stems. I can provide more detail if you want, but this should not apply to TrueType. As you noted, stdHW and stdVW are normally obtained from a CFF font dictionary. For TT, we (at Adobe) estimate stem width values based on the OS/2 weight class. We use three values, light (50/1000), regular (75/1000) and bold (110/1000). If we darken TT outlines *after* hinting, we darken vertical stems only, and we apply less darkening than we do for CFF. This is because the nature of TT hints tends to darken horizontal stems at small sizes. (Consider a scaled horizontal stem that is less than one pixel wide. Typically, the hinting will snap it to a full integer pixel, effectively darkening it.) The TT darkening amounts were tuned experimentally so the combined darkening for CFF and TT looked similar. If we darken TT outlines *before* hinting (e.g., by the autohinter) I'd expect horizontal and vertical darkening amounts could be computed separately. I'm not sure how to best estimate the stdHW or the contrast, though. It is necessary to know the direction of the paths in order to darken by adjusting the path outward. While there is a recommended direction for both CFF and TrueType, some fonts don't always follow it. There are three cases: 1. All glyphs in the font have the wrong winding order. Some font converters fail to reverse path direction when moving from CFF to TT or back. 2. Some glyphs in the font have the wrong winding order. Perhaps some glyphs are produced as reflections? 3. Some glyphs contain inconsistent subpaths; some are correct and some are wrong. The CFF rasterizer contains code to compute the winding order direction as the outline is traversed. If, at the end of the glyph outline, the winding order is as expected, then nothing extra needs to be done. If the winding order is wrong, then the glyph is re-rendered with darkening reversed. And the expected direction for this font is reversed. This means for case 1, above, only the first glyph pays a penalty. For case 2, above, a few glyphs will be rendered twice. For case 3, (very rare) we ignore the problem; some glyph components will be lightened instead of darkened. Thanks. -Dave On 8/23/2015 9:14 AM, Werner LEMBERG wrote: 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 don't want emboldening for the `strong' hinting mode (actually, we *do* want that, but this is a much harder problem to solve), you don't have to change anything along the horizontal axis. By the way, I can't directly access e.g. AF_LatinMetrics-axis-standard_width from my af_loader_compute_darkening() as I have only an AF_StyleMetrics to go from.. Is there a reason why standard_width is specific to writing class implementations of AF_StyleMetrics? I don't know. Many of the details evolved over the time... The current subpixel hinting code should already be quite near to that goal. And what keeps it from being made the default mode for the native TT fitter? Behdad has answered that. I haven't found time yet (and I probably won't in the very near future) to run a profiler on the code, fixing hot spots. Maybe this is your follow-up project? :-) Oh, and what's that about subpixel hinting in af_loader_load_glyph()? For `light' hinting mode, you can ignore that. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel . ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
Alexei A Podtelezhnikov, PhD On Aug 24, 2015, at 6:11 AM, Behdad Esfahbod behdad.esfah...@gmail.com wrote: On 15-08-23 11:29 PM, Werner LEMBERG wrote: `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 :-) Ok I'm not following what's going on FT_Outline_EmboldenXY only changes the outline and its bounding box. The dimensions of the letter is changed very predictably by xstrength and ystrength. The outline is shifted by half of the strengths so that the bottom-left of the bounding box stays in place. Makes sense? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
On 15-08-24 12:07 PM, Alexei Podtelezhnikov wrote: Alexei A Podtelezhnikov, PhD On Aug 24, 2015, at 6:11 AM, Behdad Esfahbod behdad.esfah...@gmail.com wrote: On 15-08-23 11:29 PM, Werner LEMBERG wrote: `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 :-) Ok I'm not following what's going on FT_Outline_EmboldenXY only changes the outline and its bounding box. The dimensions of the letter is changed very predictably by xstrength and ystrength. The outline is shifted by half of the strengths so that the bottom-left of the bounding box stays in place. Makes sense? Yes, this I understand very well. I have no idea what FT_Glyph_Embolden() is. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
On 15-08-23 11:29 PM, Werner LEMBERG wrote: `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 :-) Ok I'm not following what's going on. Saving advance_width, emboldening, restoring advance-width wouldn't work as the emboldened outline is shifter to the right so as to retain it's lsb. We'd need to shift it left. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
`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 :-) Ok I'm not following what's going on. I've mixed up two different FreeType functions... Saving advance_width, emboldening, restoring advance-width wouldn't work as the emboldened outline is shifter to the right so as to retain it's lsb. We'd need to shift it left. Yes, `centering' the glyph shape by reducing the lsb by 1/2 of the emboldening value. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
FT_Outline_EmboldenXY only changes the outline and its bounding box. The dimensions of the letter is changed very predictably by xstrength and ystrength. The outline is shifted by half of the strengths so that the bottom-left of the bounding box stays in place. Makes sense? Yes, this I understand very well. I have no idea what FT_Glyph_Embolden() is. FT_GlyphSlot_Embolden in ftsynth.c. Sorry for double confusion. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
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? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
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 don't want emboldening for the `strong' hinting mode (actually, we *do* want that, but this is a much harder problem to solve), you don't have to change anything along the horizontal axis. By the way, I can't directly access e.g. AF_LatinMetrics-axis-standard_width from my af_loader_compute_darkening() as I have only an AF_StyleMetrics to go from.. Is there a reason why standard_width is specific to writing class implementations of AF_StyleMetrics? I don't know. Many of the details evolved over the time... The current subpixel hinting code should already be quite near to that goal. And what keeps it from being made the default mode for the native TT fitter? Behdad has answered that. I haven't found time yet (and I probably won't in the very near future) to run a profiler on the code, fixing hot spots. Maybe this is your follow-up project? :-) Oh, and what's that about subpixel hinting in af_loader_load_glyph()? For `light' hinting mode, you can ignore that. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
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 idea. This might be a nice idea! However, I suggest that you first finish the stuff for the auto-hinter. This makes your life much simpler :-) 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. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
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 Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
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. Though I might be wrong. Let's see whether this really necessary. I don't object, since the CFF engine does the same IIRC. Do you also modify advance width? If yes, that shouldn't happen on unhinted. It shouldn't happen either for `light' auto-hinting mode. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
`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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
Thanks Nikolaus for working on this. This is amazing! 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. Though I might be wrong. Do you also modify advance width? If yes, that shouldn't happen on unhinted. If no, then this is essentially just a rasterizer change and shold be done more widely. I'm still am of the opinion that this is a hack to work around lack of gamma-corrected blending AND lack of optical sizes. But since it's in the CFF engine already, we might as well do it universally. behdad On 15-08-20 10:40 PM, Nikolaus Waxweiler wrote: As soon as you switch to a new size, simply recompute the values. Done! I'm almost there. I have extended AF_FaceGlobals to hold: ... FT_UShort stem_darkening_for_ppem; FT_Posdarken_x; ... and modified af_loader_load_g() to do: ... error = FT_Load_Glyph( face, glyph_index, flags ); ... if ( face-size-metrics.x_ppem != loader-globals-stem_darkening_for_ppem ) af_loader_compute_darkening( ... ); if ( slot-format == FT_GLYPH_FORMAT_OUTLINE ) FT_Outline_EmboldenXY(..., ...-darken_x, 0); ... That works for size changes. I have crudely... copy-pasted and adapted cf2_computeDarkening() into af_loader_compute_darkening(). I feel dirty now but IT WORKS!!! There's just one problematic line left: ... stemWidth = cf2_intToFixed(84); /* XXX fill in somehow */ ... That's hopefully the last step ;) Thanks for all your pointers so far! That helped a lot :) I uploaded a small screenshot to show how it looks like with the current stand-in: http://postimg.org/image/6obxidt9d/ (native CFF engine, emboldening autohinter, normal autohinter, all with a gamma of 1.8). 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? By the way, I can't directly access e.g. AF_LatinMetrics-axis-standard_width from my af_loader_compute_darkening() as I have only an AF_StyleMetrics to go from.. Is there a reason why standard_width is specific to writing class implementations of AF_StyleMetrics? I'll see if I can find a way around or get a hold of the implementing class somehow... but first some sleep.. The current subpixel hinting code should already be quite near to that goal. And what keeps it from being made the default mode for the native TT fitter? Oh, and what's that about subpixel hinting in af_loader_load_glyph()? Certainly not. You can't patent the omission of something if everything else stays the same... ;) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
On 15-08-21 03:17 PM, Alexei Podtelezhnikov wrote: This function still needs a bit of work around the corners, both literally and figuratively speaking. Emboldening is not affine transformation. It can introduce artifacts. The function has some crude protection against distortions, but I want to replace them with something more delicate. Be careful out there! Same here! Also, it currently mishandles glyphs that have outer contours with differing directions... If you think that this is worth doing by default. Let's plan it for 2.6.2. 2.7 please! ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
if ( slot-format == FT_GLYPH_FORMAT_OUTLINE ) FT_Outline_EmboldenXY(..., ...-darken_x, 0); This function still needs a bit of work around the corners, both literally and figuratively speaking. Emboldening is not affine transformation. It can introduce artifacts. The function has some crude protection against distortions, but I want to replace them with something more delicate. Be careful out there! How is speed? If you think that this is worth doing by default. Let's plan it for 2.6.2. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
On 15-08-21 03:17 PM, Alexei Podtelezhnikov wrote: This function still needs a bit of work around the corners, both literally and figuratively speaking. Emboldening is not affine transformation. It can introduce artifacts. The function has some crude protection against distortions, but I want to replace them with something more delicate. Be careful out there! Fortunately, this is something for very small font sizes where emboldening distortions are hardly visible. Same here! Also, it currently mishandles glyphs that have outer contours with differing directions... Example call, please. If you think that this is worth doing by default. Let's plan it for 2.6.2. 2.7 please! :-) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
As soon as you switch to a new size, simply recompute the values. Done! I'm almost there. I have extended AF_FaceGlobals to hold: ... FT_UShort stem_darkening_for_ppem; FT_Posdarken_x; ... and modified af_loader_load_g() to do: ... error = FT_Load_Glyph( face, glyph_index, flags ); ... if ( face-size-metrics.x_ppem != loader-globals-stem_darkening_for_ppem ) af_loader_compute_darkening( ... ); if ( slot-format == FT_GLYPH_FORMAT_OUTLINE ) FT_Outline_EmboldenXY(..., ...-darken_x, 0); ... That works for size changes. I have crudely... copy-pasted and adapted cf2_computeDarkening() into af_loader_compute_darkening(). I feel dirty now but IT WORKS!!! There's just one problematic line left: ... stemWidth = cf2_intToFixed(84); /* XXX fill in somehow */ ... That's hopefully the last step ;) Thanks for all your pointers so far! That helped a lot :) I uploaded a small screenshot to show how it looks like with the current stand-in: http://postimg.org/image/6obxidt9d/ (native CFF engine, emboldening autohinter, normal autohinter, all with a gamma of 1.8). 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? By the way, I can't directly access e.g. AF_LatinMetrics-axis-standard_width from my af_loader_compute_darkening() as I have only an AF_StyleMetrics to go from.. Is there a reason why standard_width is specific to writing class implementations of AF_StyleMetrics? I'll see if I can find a way around or get a hold of the implementing class somehow... but first some sleep.. The current subpixel hinting code should already be quite near to that goal. And what keeps it from being made the default mode for the native TT fitter? Oh, and what's that about subpixel hinting in af_loader_load_glyph()? Certainly not. You can't patent the omission of something if everything else stays the same... ;) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
My initial idea was to do the calculations after af_face_globals_get_metrics() filled in 'AF_*Metrics-standard_weight'[1] and store them in AF_FaceGlobals-darken. Until I noticed that they aren't redone on size changes because AF_FaceGlobals doesn't deal with size stuff. Yes, the whole global glyph analysis happens in the font unit space. Then I thought about putting 'darken' into a sort of associative array like [12ppem - FT_Pos(0.1), ...] and *then* store it in AF_FaceGlobals and trigger a recompute for a new size before FT_Outline_Embolden() if the new ppem can't be found in the array. That would make sure that the calculations are really only done once per size if the same face is used in multiple sizes or the client changes sizes back and forth. I think this is not necessary. As soon as you switch to a new size, simply recompute the values. As far as I can see, this isn't computationally expensive. Compare this to re-executing the `prep' table data in the TrueType bytecode engine after a size change. Must investigate AF_GlyphHints and it's use to see if it's better suited than AF_FaceGlobals. I think it gets scrubbed with each size change though?! Yes. Glyph hints are recomputed (i.e., aligned relative to the grid) after a size change. And I still have to understand the glyph slot FT_Load_Glyph recursion stuff. It still boggles my mind. :) It's very simple: The auto-hinter needs unscaled, unhinted glyph outline data for both the global and local processing, and the recursive calls to FT_Load_Glyph do exactly this. I believe that you can ignore this completely for the emboldening issue. At least the dummy FT_Outline_Embolden() that I inserted after each FT_Load_Glyph() do what I want. Yay! Though I still don't know why I can't just do that once somewhere instead of after every FT_Load_Glyph() ;) I think we should use the same approach as is done in Adobe's TrueType engine, according to Dave: Apply emboldening only horizontally and don't do horizontal hinting. In other words, the emboldening will happen only in the FT_RENDER_MODE_LIGHT auto-hinting mode. For the global analysis, the auto-hinter loads a bunch of characters to determine the blue zones, cf. function `af_latin_metrics_init_blues'. However, blue zones are derived from vertical values; it is thus not necessary to call `FT_Outline_Embolden_XY' in thus function. A similar argument holds for `af_latin_metrics_init_widths': Only the stem width measured along the vertical axis is used for light hinting. As a result, I think that you need to call the emboldening function only once, namely right after the `FT_Load_Glyph' call in function `af_loader_load_g'. Speaking of random cleaning-up thoughts, what's the project's stance on making the TrueType bytecode fitter only fit on the Y axis by default? The current subpixel hinting code should already be quite near to that goal. Or would that touch the ClearType patents? Certainly not. You can't patent the omission of something if everything else stays the same... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
I need to figure out where to best place the darkening calculations so they are done just once per face/size. And how to obtain stdVW/stdHW. Yes :) Thanks for your helping along so far :) I spend the day looking for a good place to do and store the calculations and am stumped again. I want to jot down my thoughts to 1. sort them out 2. hope for someone more knowledgeable to point me in the right direction. My initial idea was to do the calculations after af_face_globals_get_metrics() filled in 'AF_*Metrics-standard_weight'[1] and store them in AF_FaceGlobals-darken. Until I noticed that they aren't redone on size changes because AF_FaceGlobals doesn't deal with size stuff. Duh. Then I thought about putting 'darken' into a sort of associative array like [12ppem - FT_Pos(0.1), ...] and *then* store it in AF_FaceGlobals and trigger a recompute for a new size before FT_Outline_Embolden() if the new ppem can't be found in the array. That would make sure that the calculations are really only done once per size if the same face is used in multiple sizes or the client changes sizes back and forth. I guess I'd have to understand FT's memory management first to know how to grow the array. Must investigate AF_GlyphHints and it's use to see if it's better suited than AF_FaceGlobals. I think it gets scrubbed with each size change though?! And I still have to understand the glyph slot FT_Load_Glyph recursion stuff. It still boggles my mind. At least the dummy FT_Outline_Embolden() that I inserted after each FT_Load_Glyph() do what I want. Yay! Though I still don't know why I can't just do that once somewhere instead of after every FT_Load_Glyph() ;) [1]: XXX: good enough or must compute 'real' stdVW/stdHW to get 'darkenX' *and* 'darkenY' instead of a 'darken' for both axes? Investigate after prototype works. Well, ftview tries to mimick the FT_Load_Glyph arguments. Please proceed if you find a way to improve that! It's not easy (at least not for me) to get something better... Will see if I get an idea :) Speaking of random cleaning-up thoughts, what's the project's stance on making the TrueType bytecode fitter only fit on the Y axis by default? Or would that touch the ClearType patents? This is not true. Whoops. Okay then ;) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
Unfortunately, FreeType's source code is not sufficiently documented. It would be great if you could add comments while walking over the various functions that I can then further massage and commit. Alright, will get back to you once I understand.. something ;) Speaking of understanding, I'm trying to understand how darkening works in the CFF driver. So far, I have: cf2_computeDarkening()[1] is called twice per font face (CF2_Font =~ FT_Face?) upon initialization, once for vertical, once for horizontal stems, and calculates by how many pixels between 0 and 0.4 (default params) the font needs to grow in the X and Y direction. These deltas/2 are then used to shift points around when turning the individual points of a glyph into a path, but before passing the path on to the rest of the hinting machinery. Is that correct? I still have to understand the actual calculations and character space stuff, etc. So the idea is, I outfit AF_ModuleRec_ with the no-stem-darkening and darkening-parameters attributes including getters and setters and use the same algorithm as cf2_computeDarkening() to come up with two FT_Pos that get used in FT_Outline_EmboldenXY() after each FT_Load_Glyph(). Correct? Now to figure out how the autohinter is hooked up and invoked by font engines. I need to figure out where to best place the darkening calculations so they are done just once per face/size. And how to obtain stdVW/stdHW. Mode `forced A' is strong auto-hinting, which hints horizontally also, thus modifying the advance widths. `forced B' (which is identical to `B') is light auto-hinting that only hints along the vertical axis, thus the advance widths are the same as if you render the font unhinted. `forced C' should have the same advance widths as `forced A'. Thanks for the explanation. Unfortunately, 'forced A' and 'forced C' have slightly different metrics for Ubuntu-R.ttf and SourceSansPro-Regular.otf... By the way, I find this mode stuff confusing. Shouldn't it be 1. native-grid-fitting, autohinter-unless-tricky, no-grid-fitting 2. hint-X-and-Y, hint-Y-only 3. subpixel-none, subpixel-RGB, ... all as separate knobs with warnings if some combination doesn't work? That's what also bugs me about fontconfig's hintfull, hintslight, etc. I know, organic growth, but this always puts me in a cleaning-up mood ;) Regards, Nikolaus [1]: It is slightly amusing that the CF2 stuff sometimes uses camelCasing while the rest of FT does_not. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
Speaking of understanding, I'm trying to understand how darkening works in the CFF driver. So far, I have: cf2_computeDarkening()[1] is called twice per font face (CF2_Font =~ FT_Face?) upon initialization, once for vertical, once for horizontal stems, and calculates by how many pixels between 0 and 0.4 (default params) the font needs to grow in the X and Y direction. These deltas/2 are then used to shift points around when turning the individual points of a glyph into a path, but before passing the path on to the rest of the hinting machinery. Is that correct? Let's wait for the definite answer from Dave :) I still have to understand the actual calculations and character space stuff, etc. So the idea is, I outfit AF_ModuleRec_ with the no-stem-darkening and darkening-parameters attributes including getters and setters and use the same algorithm as cf2_computeDarkening() to come up with two FT_Pos that get used in FT_Outline_EmboldenXY() after each FT_Load_Glyph(). Correct? Yes. Now to figure out how the autohinter is hooked up and invoked by font engines. It's the `if ( autohint )' block in `FT_Load_Glyph'. `hinting-load_glyph' then points to function `af_loader_load_glyph', IIRC, which in turn calls `FT_Load_Glyph' by itself, but without hinting. I need to figure out where to best place the darkening calculations so they are done just once per face/size. And how to obtain stdVW/stdHW. Yes :) Mode `forced A' is strong auto-hinting, which hints horizontally also, thus modifying the advance widths. `forced B' (which is identical to `B') is light auto-hinting that only hints along the vertical axis, thus the advance widths are the same as if you render the font unhinted. `forced C' should have the same advance widths as `forced A'. Thanks for the explanation. Unfortunately, 'forced A' and 'forced C' have slightly different metrics for Ubuntu-R.ttf and SourceSansPro-Regular.otf... Ah, then I didn't have a close enough look. Right now, I can't explain the difference; maybe a rounding issue. By the way, I find this mode stuff confusing. Shouldn't it be 1. native-grid-fitting, autohinter-unless-tricky, no-grid-fitting 2. hint-X-and-Y, hint-Y-only 3. subpixel-none, subpixel-RGB, ... all as separate knobs with warnings if some combination doesn't work? Well, ftview tries to mimick the FT_Load_Glyph arguments. Please proceed if you find a way to improve that! It's not easy (at least not for me) to get something better... [1]: It is slightly amusing that the CF2 stuff sometimes uses camelCasing while the rest of FT does_not. This is not true. Doing git grep '[A-Z][a-z]\+[A-Z]' -- '*.[ch]' | grep -v FreeType I get almost 1 hits. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
I'll invite to have a look at the auto-hinter implementation, probably coming up with a patch! Ok, so I'm still trying to wrap my head around FT's internals and how it all works (anybody got some recommendations on how to explore an unknown codebase and getting a feeling for it?) and stumbled over this: ftview exposes different AA methods and they result in different metrics when using the autohinter? Look at some font with ftview 16 something.otf, use the autohinter with f and press A, B, C and look at how the glyphs shift around. Shouldn't they stay in place? Interestingly, when Adobe's hinter is active with .otf fonts and you press B (- autohinter), glyphs don't shift. Regards, Nikolaus ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
It looks like the potential for change is there, it's just that stem darkening for non-CFF and autohinted fonts needs to be in place first before the toolkits consider enabling it. I'll have a look around to see if I can maybe salvage something. I'll invite to have a look at the auto-hinter implementation, probably coming up with a patch! The idea to solve the problem is simple: Insert a call to FT_Outline_EmboldenXY after FT_Load_Glyph essentially in all files of src/autofit. What's needed are test w.r.t. speed, reliability, etc. Of course, this should be similarly configurable as the CFF stem darkening mechanism (i.e., dependent on the PPEM value). Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
(Repost because I forgot to click post to list, sorry Werner..) Indeed. So why doesn't get this applied? Is there a negative impact somewhere? Perhaps you should add the patch to the bug report; maybe this helps move the dinosaurs... The author noted that CAIRO_DEBUG=xrender-version=-1 triggers software rendering, so I personally only rigged firefox.desktop and thunderbird.desktop to load it and leave the rest of the desktop hardware-accelerated ;) This patch will probably need to touch other parts of the stack, but I will bug some cairo (and skia/QT?) people to see if there's something that can be done to bring Linux font rendering into the 21st century ;) Side note 1: Firefox on Windows (with DirectWrite enabled for all fonts) does gamma correction for fonts, as does Edge. So it would be bringing the Linux version up to parity. Side note 2: For years I didn't like the autohinter, I always thought it's output looked... pixely, blotchy, color-fringy... the opposite of nice, depending on the size. Wasted a lot of time fiddling with Infinality's patches, stem darkening, etc. It's a bit embarrassing that the problem has been gamma correction the entire time and that the autohinter is doing perfectly fine, even if the output is a bit thin. Which brings us to stem darkening again ;) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
I'll take a look soon... It's a hard problem. There's no easy answer.. On 15-08-08 09:17 AM, Nikolaus Waxweiler wrote: (Repost because I forgot to click post to list, sorry Werner..) Indeed. So why doesn't get this applied? Is there a negative impact somewhere? Perhaps you should add the patch to the bug report; maybe this helps move the dinosaurs... The author noted that CAIRO_DEBUG=xrender-version=-1 triggers software rendering, so I personally only rigged firefox.desktop and thunderbird.desktop to load it and leave the rest of the desktop hardware-accelerated ;) This patch will probably need to touch other parts of the stack, but I will bug some cairo (and skia/QT?) people to see if there's something that can be done to bring Linux font rendering into the 21st century ;) Side note 1: Firefox on Windows (with DirectWrite enabled for all fonts) does gamma correction for fonts, as does Edge. So it would be bringing the Linux version up to parity. Side note 2: For years I didn't like the autohinter, I always thought it's output looked... pixely, blotchy, color-fringy... the opposite of nice, depending on the size. Wasted a lot of time fiddling with Infinality's patches, stem darkening, etc. It's a bit embarrassing that the problem has been gamma correction the entire time and that the autohinter is doing perfectly fine, even if the output is a bit thin. Which brings us to stem darkening again ;) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
I'll take a look soon... It's a hard problem. There's no easy answer.. Thanks :) I just saw that Markus Trippelsdorf posted two patches to this list for Qt5 and Skia to enable proper blending. It was even on by default in Qt5 when someone complained that fonts looked different and too thin compared to what other toolkits rendered, so they reverted the change on XCB[1]. Funny how many pieces of the puzzle are just laying around without much communication between the involved parties. It looks like the potential for change is there, it's just that stem darkening for non-CFF and autohinted fonts needs to be in place first before the toolkits consider enabling it. I'll have a look around to see if I can maybe salvage something. Regards, Nikolaus [1]: https://bugreports.qt.io/browse/QTBUG-41590 PS: I converted the Liberation Sans family to .otf and hinted them with AFDKO. Looks nice, but has some vertical spacing issues: http://imgur.com/a/mMrkD ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
Hello Dave, your response has motivated me to spend some time looking into linear blending :) It turns out that other people had the same idea before, I found https://bugs.freedesktop.org/show_bug.cgi?id=28549 but the discussion there seems to have died quickly and the bug reporter told me he lost interest and is waiting for high-DPI-screens. I too hope for 200+dpi screens in the near future, but I want something to tide me over. I looked through the demo pages he set up[1][2] and found a demonstration of concept in the form of a hack of pixman. I made the patch apply to the current version 0.32.6 and attached it here (I hope it's not too big for the list?). Build the patched pixman somewhere and test it from the build directory with LD_PRELOAD=pixman/.libs/libpixman-1.so CAIRO_DEBUG=xrender-version=-1 some-application-like-firefox. Chrome doesn't seem to work (different rendering library?), Firefox does. First impressions: wow! Text renders much cleaner. Screenshots: http://imgur.com/a/Xb1at -- before/after with autohinted Liberation Sans, before/after with Adobe-CFF-engine-hinted Source Sans Pro. Use wheel thingy the corner of a preview to download full size image. Best regards, Nikolaus [1]: https://bel.fi/alankila/lcd/ [2]: https://bel.fi/alankila/lcd/alpcor.html pixman-0.32.6-glyphalphacorrection.patch.gz Description: application/gzip ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
I looked through the demo pages he set up[1][2] and found a demonstration of concept in the form of a hack of pixman. I made the patch apply to the current version 0.32.6 and attached it here (I hope it's not too big for the list?). Build the patched pixman somewhere and test it from the build directory with LD_PRELOAD=pixman/.libs/libpixman-1.so \ CAIRO_DEBUG=xrender-version=-1 \ some-application-like-firefox What a simple patch! First impressions: wow! Text renders much cleaner. Indeed. So why doesn't get this applied? Is there a negative impact somewhere? Perhaps you should add the patch to the bug report; maybe this helps move the dinosaurs... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?
Hi Nikolaus, I would consider 1.8 to be close to 2.2. The exact value is not critical. But failing to apply a correction is equivalent to gamma 1.0, and does not work well. It is unfortunate that gamma correction when compositing text is not part of FreeType. It is part of the graphics engine of the particular system. So some coordination is necessary between the components, and that's where things often break down. I don't know how it usually goes in Linux. For example, Google's Android sets a usable system default gamma, but OEMs are free to override it, and many do. I do believe that stem darkening should be applied to TrueType. I consider the disparity between CFF and TT right now to be a serious problem. Adobe's proprietary TT rasterizer does apply stem darkening, but the base code is licensed from Microsoft, and cannot be contributed to an open source project. A different approach is needed to do stem darkening in TrueType. In CFF, it is possible to apply darkening to the original outline in both horizontal and vertical directions and then adjust the hints so the final outline comes out properly hinted. In TrueType, it is not possible to adjust the native hints to account for darkening. I see two approaches that could work, though. One is to disable hints in the horizontal direction and just darken in that direction. This is an effective compromise and would be compatible with FreeType's light hint mode. It is also what Adobe does. The second approach would be to use FreeType's autohinter. Apply the stem darkening to the outline prior to running the authohinter. The result would be properly hinted and darkened. Thanks. -Dave On 8/6/2015 7:53 AM, Nikolaus Waxweiler wrote: Hello list, I've been playing around with the CFF renderer again because font rendering is a dear topic to me. What immediately stands out is that rendered fonts are much thicker than what the autohinter puts out. This creates a somewhat strong contrast between local .otfs and web fonts when browsing the net. Now, Dave Arnold said in an old mail to list that The stem darkening function assumes blending with a gamma close to 1.8. * What values/formula should I use with a gamma close to 2.2 or sRGB? * Shouldn't that be the default for a feature that's turned on by default? I currently use Y1-Y4: 300, 200, 200, 0. * Arnold wrote that gamma correction is necessary. What part of the rendering stack does that? And is it, in experience, implemented and working on the usual Linux systems? * What's the state of stem darkening for the autohinter for e.g. TrueType fonts? I see that Infinality has given up on maintaining his patch set. A shared stem darkening would improve the coexistence of Adobe-CFF-rendered and autohinted fonts. It saddens me that this great little piece of rendering code gets so little publicity and (font) support from OSS communities... Shipping the URW35, DejaVu and Liberation font families as properly hinted .otfs instead of .pfbs and .ttfs would be a start. Regards, Nikolaus ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel . ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
