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] thread and non-thread safe issues
I'm currently using freetype to create a simple demo of my further project, and I've noticed that I cannot use FTC_ImageCache_Lookup and FTC_Manager related functions at same time in different threads. It is documented that we can't operate ft_library or some other struct simultaneously, but I didn't find a conclusion or some kind of multithread programming guideline document that figures out all thread safety issues. Can you please give a note on that? We have the following in the CHANGES file for version 2.6. - Behdad Esfahbod contributed code for improved thread-safety, which results in the following model. * An `FT_Face' object can only be safely used from one thread at a time. * An `FT_Library' object can now be used without modification from multiple threads at the same time. * `FT_Face' creation and destruction with the same `FT_Library' object can only be done from one thread at a time. One can use a single `FT_Library' object across threads as long as a mutex lock is used around `FT_New_Face' and `FT_Done_Face'. Any calls to `FT_Load_Glyph' and similar API are safe and do not need the lock to be held as long as the same `FT_Face' is not used from multiple threads at the same time. Note that I have no experience in thread safety code. However, since the cache code is essentially based on FT_Face objects, I believe that you have to use separate caches for different threads. Maybe this can be improved, but unfortunately I'm the wrong guy to do this. 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 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] Improved Arabic auto-hinting
I'll try to get back to this topic soon. On 15-08-20 03:25 PM, Alexei Podtelezhnikov wrote: This effect: https://www.flickr.com/photos/behdad/34769511/ still happens in my limited testing. This looks like a text layout problem, which was traditionally outside of FreeType's responsibilities. The extra ink is a result of bitmap addition, which would be swept under the rug by strong hinting in the new blue zone, of course. The text layout engine on its part could also be a little smarter (read smoother): instead of a+b in the overlap zone, it should try max(a,b). I bet it will solve the issue. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
