On Tue, Feb 20, 2018 at 12:01 PM, Alexei Podtelezhnikov <[email protected]> wrote: >> I'm not an expert on how the code works, but my understanding is that >> subpixel positioning is the norm. > > I highly doubt that Chromium implements subpixel positioning. This > isn't the norm. > > - LCD (subpixel) rendering is about utilizing color channels > separately to improve glyph appearance. > - Subpixel position is freedom of placement of outlines relative to > pixel grid *before* rendering, so it is different. > - Kerning is about spacing of letter pairs like "AV". Again I am not > sure your bug is about that. > - Hinting is about improving contrast, relevant mostly to non-LCD rendering >
Apologies for the terminology confusion. I was going by the "subpixel positioning" definition here: https://www.freetype.org/freetype2/docs/glyphs/glyphs-5.html : """ Subpixel positioning 1. Convert the character string into a series of glyph indices. 2. Place the pen to the cursor position. This can be a non-integer point. 3. Get or load the glyph image. 4. Translate the glyph by ‘pen_pos - floor(pen_pos)’. 5. Render the glyph to the target device at ‘floor(pen_pos)’. 6. Increment the pen position by the glyph's advance width in fractional pixels. 7. Start over at step 3 for each of the remaining glyphs. 8. When all glyphs are done, set the text cursor to the new pen position. """ My understanding is that Chromium does implement this algorithm. At the top of the page there is a caveat: "This algorithm can be used for hinting modes that don't apply horizontal hinting". Which is what I am trying to figure out :) > You mention all of these in the bug report... This is intractable and > confusing. Can you identify specific problem and file bug report with > FreeType if you think it is our problem? _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
