> 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