freetype: route FC_MATRIX through cairo for color glyphs#10006
Open
Strykar wants to merge 1 commit into
Open
Conversation
Color glyphs (COLR/CBDT/SVG) go through cairo on a second FT_Face, self->face_for_cairo, opened in ensure_cairo_resources. That face never receives the FT_Set_Transform installed on self->face in face_from_descriptor (kovidgoyal#9990): cairo owns FT_Set_Transform on its own face and derives it from the font matrix on every render (_cairo_ft_unscaled_font_set_scale in cairo-ft-font.c). The only channel that reaches color-glyph rasterization is the cairo font matrix, not the FT face transform, so FC_MATRIX is silently dropped on that path. Stock fontconfig rules do not apply FC_MATRIX to color fonts, so this is a hand-built config edge case. Factor the two cairo_set_font_size() call sites in set_cairo_font_size and fit_cairo_glyph into apply_cairo_font_size(), which calls cairo_set_font_matrix() with size * FC_MATRIX when has_matrix is set, and falls through to cairo_set_font_size() otherwise. The non-matrix path is bit-identical to before. For pure shears (xx=1, yy=1) cairo_scaled_font_glyph_extents reads the post-shear bbox so the shrink loop bounds the destination correctly; the user-visible effect is that a sheared color glyph reports a wider bbox and shrinks more aggressively to fit a cell than its upright sibling. Acceptable for the hand-built edge case this PR scopes to. FT_Matrix stores xx,xy,yx,yy in row-major order; cairo_matrix_init takes xx,yx,xy,yy. Same matrix, transposed argument order - pinned with a comment because it is easy to flip. Refs: kovidgoyal#9990
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Color glyphs (COLR/CBDT/SVG) go through cairo on a second
FT_Face,self->face_for_cairo, opened inensure_cairo_resources. That face never receives theFT_Set_Transforminstalled onself->faceinface_from_descriptor(#9990): cairo ownsFT_Set_Transformon its own face and derives it from the font matrix on every render (_cairo_ft_unscaled_font_set_scaleincairo-ft-font.c).The only channel that reaches color-glyph rasterization is the cairo font matrix, not the FT face transform, so
FC_MATRIXis silently dropped on that path. Stock fontconfig rules do not applyFC_MATRIXto color fonts, so this is a hand-built config edge case.Factor the two
cairo_set_font_size()call sites inset_cairo_font_sizeandfit_cairo_glyph into apply_cairo_font_size(), which callscairo_set_font_matrix()withsize * FC_MATRIXwhen has_matrix is set, and falls through tocairo_set_font_size()otherwise.The non-matrix path is bit-identical to before. For pure shears (xx=1, yy=1)
cairo_scaled_font_glyph_extentsreads the post-shear bbox so the shrink loop bounds the destination correctly; the user-visible effect is that a sheared color glyph reports a wider bbox and shrinks more aggressively to fit a cell than its upright sibling. Acceptable for the hand-built edge case this PR scopes to.FT_Matrix stores xx,xy,yx,yy in row-major order;
cairo_matrix_inittakes xx,yx,xy,yy.Same matrix, transposed argument order - pinned with a comment because it is easy to flip.
Refs: #9990