Hi all, in previous posts to this list, I have sent updates regarding our work on COLRv1: https://lists.gnu.org/archive/html/freetype-devel/2020-07/msg00041.html
Under the keyword COLRv1 we subsume a set of proposed specification extensions which add support for linear and radial gradients, compositing and glyph transformation and shape reuse to the COLR table, increasing the table version number from 0 to 1. These extensions come with support for Variations, which means gradient and transformation properties can be varied using font variation axes and bring a compact and expressive color vector font format to OpenType and the ISO Open Font Format. We’ve been continuously improving the specification - the latest version is found here: https://github.com/googlefonts/colr-gradients-spec/#a2-changes-to-off-5711---color-table At this point, we believe that the proposed COLRv1 specification is in good shape and the main concepts of it are stable. Work is progressing on integrating the specification proposal from the link above into OpenType and the ISO Open Font Format. We successfully implemented and tested a prototype of COLRv1 rendering based on experimental COLRv1 color fonts we made (https://github.com/googlefonts/color-fonts), a COLRv1 implementation in FreeType, and a rasterization implementation in Skia (https://skia-review.googlesource.com/c/skia/+/300558). With your agreement — and I am happy to hear feedback and answer questions — I would like to start upstreaming our implementation of COLRv1 support into FreeType. This contribution is meant as an addition to the current experimental support of COLRv0. It brings support to FreeType for understanding the COLRv1 additions and returns parsed COLRv1 information from the font to a client of the FreeType API in structured form. We believe this is a useful abstraction level, as the COLRv1 additions map to concepts of 2D graphics libraries (Cairo, Skia, etc.) in a straightforward way. So that it is an effective strategy to implement a COLRv1 rasterizer using the drawing primitives from the 2D graphics libraries based on COLRv1 information returned from FreeType. An example on how the API is used can be found here: https://gist.github.com/drott/83bca80294eec7db308231f95655d1c0 and in the Skia work-in-progress implementation at https://skia-review.googlesource.com/c/skia/+/300558 - Pseudocode for the drawing algorithm is also part of the spec here: https://github.com/googlefonts/colr-gradients-spec/#pseudocode Among the things I would like to hear your feedback on: Would you prefer a separate feature flag to be used to distinguish between COLRv0 and COLRv1, or would we keep this new implementation under the same feature flag TT_CONFIG_OPTION_COLOR_LAYERS? I published a set of the first 8 proposed changes. Below you find a list of these. The changes are broken down into addition of new structs and enums to the FreeType public API, adding new public API methods for parsing and extracting COLRv1 information, separate changes for incremental addition of the COLRv1 implementation in ttcolr.h/cc, and finally the registration of the new API to the sfnt driver. * [COLRv1] Add types required for COLRv1 to public API (#59703) https://github.com/drott/freetype2-colr/pull/4 * [COLRv1] Add new methods required for COLRv1 to public API (#59703) https://github.com/drott/freetype2-colr/pull/5 * [COLRv1] Add implementation to retrieve root paint to ttcolr (#59703) https://github.com/drott/freetype2-colr/pull/6 * [COLRv1] Add API to resolve FT_OpaquePaint to FT_COLR_Paint (#59703) https://github.com/drott/freetype2-colr/pull/7 * [COLRv1] Add COLR API to iterate color stops (#59703) https://github.com/drott/freetype2-colr/pull/8 * [COLRv1] Add COLR API to retrieve color layers (#59703) https://github.com/drott/freetype2-colr/pull/9 * [COLRv1] Register new COLR API in sfnt driver (#59703) https://github.com/drott/freetype2-colr/pull/10 * [COLRv1] Connect API from SFNT driver to public API (#59703) https://github.com/drott/freetype2-colr/pull/11 Support for variations is defined in the specification, but this initial implementation does not implement support for variable COLRv1 fonts yet. However, we are committed to contributing that as well, same as we are committed to keeping this implementation in sync should there be further changes to the spec. In order to track the upstreaming effort, I filed https://savannah.nongnu.org/bugs/?59703 If this sounds good to you, can I ask you - Werner and others - to start reviewing the above pull requests as a first step towards merging them? I am looking forward to collaborating with you on this effort, hearing your feedback and hopefully making good progress on bringing COLRv1 support to FreeType. Dominik
