Re: Gradient Color Fonts, COLR v1 Contributions to FreeType

2020-08-04 Thread Werner LEMBERG


>> Alexei, this sounds interesting.  Care to implement this, as an
>> alternative interface?  What Dominik has written fits quite well to
>> the existing API, so I'm in favor to add his code.
> 
> I am scared of ttgload.c, which constantly juggles transforming and
> hinting.  Are layers ever transformed or hinted?

Of course they are!  The layers are ordinary glyphs consisting of
ordinary outlines, which are handled the normal way.  Whether hinted
layers make sense, and whether you find such layers in the wild is a
different question.


Werner



Re: Gradient Color Fonts, COLR v1 Contributions to FreeType

2020-08-04 Thread Alexei Podtelezhnikov
> > I would much rather prefer that
> >
> > 1) FT_Load_Glyph sequentially loads and merges all contours from all
> >layers into a single outline and uses FT_GlyphSlot->other to tag
> >each contour with the layer information and the corresponding
> >comprehensive (including gradient) color description after
> >palette decoding.  This could potentially work for SVG glyphs
> >too.  I really want FT_GlyphSlot to be self-sufficient and ready
> >for a renderer to handle it without any additional calls.  This
> >could be a new glyph format.
> >
> > 2) then FT_Render_Glyph just calls a color renderer which quickly
> >allocates the entire CBox of memory and just blends the layers
> >possibly using FT_RASTER_FLAG_DIRECT for speed.  We can
> >eventually have gradient support as well.
>
> Alexei, this sounds interesting.  Care to implement this, as an
> alternative interface?  What Dominik has written fits quite well to
> the existing API, so I'm in favor to add his code.

I am scared of ttgload.c, which constantly juggles transforming and
hinting. Are layers ever transformed or hinted?..

> Note that the iterative API works also quite nicely if you are *not*
> using FreeType to manage gradients and the like.  On the other hand,
> it seems to me that your proposed solution necessitates gradient
> handling within FreeType (but maybe I'm just confused).

On the contrary, I am advocating for loading of all layers as combined
outlines with attached color descriptors per each contour or blocks of
contours, but short of rendering. Rendering them would be implemented
*eventually* but not necessarily for all cases. I see that solid
colors and linear gradients are within the realm of possibility for
FreeType as they do not require non-linear math.

Alexei



Re: Gradient Color Fonts, COLR v1 Contributions to FreeType

2020-08-04 Thread Werner LEMBERG


>> I've made some progress with the COLR v1 extension implementation
>> in FreeType and would be happy to hear initial feedback on the
>> general approach and API style.

Dominik, this is very nice code, thanks!

> I would much rather prefer that
> 
> 1) FT_Load_Glyph sequentially loads and merges all contours from all
>layers into a single outline and uses FT_GlyphSlot->other to tag
>each contour with the layer information and the corresponding
>comprehensive (including gradient) color description after
>palette decoding.  This could potentially work for SVG glyphs
>too.  I really want FT_GlyphSlot to be self-sufficient and ready
>for a renderer to handle it without any additional calls.  This
>could be a new glyph format.
> 
> 2) then FT_Render_Glyph just calls a color renderer which quickly
>allocates the entire CBox of memory and just blends the layers
>possibly using FT_RASTER_FLAG_DIRECT for speed.  We can
>eventually have gradient support as well.

Alexei, this sounds interesting.  Care to implement this, as an
alternative interface?  What Dominik has written fits quite well to
the existing API, so I'm in favor to add his code.

Note that the iterative API works also quite nicely if you are *not*
using FreeType to manage gradients and the like.  On the other hand,
it seems to me that your proposed solution necessitates gradient
handling within FreeType (but maybe I'm just confused).


Werner



Re: Gradient Color Fonts, COLR v1 Contributions to FreeType

2020-07-28 Thread Alexei Podtelezhnikov
Hi Dominik and others

On Fri, Jul 10, 2020 at 7:17 AM Dominik Röttsches  wrote:
> I've made some progress with the COLR v1 extension implementation in
> FreeType and would be happy to hear initial feedback on the general
> approach and API style.

Let me repeat myself by saying that I am not particularly happy with
the current state of COLR support. My main concern is that it does not
attempt to provide users with all data at once. The user is supposed
to get each layer separately. The FT_Render_Glyph implements a special
case blending path instead of calling a renderer to do so. I would
much rather prefer that

1) FT_Load_Glyph sequentially loads and  merges all contours from all
layers into a single outline and uses FT_GlyphSlot->other to tag each
contour with the layer information and the corresponding comprehensive
(including gradient) color description after palette decoding. This
could potentially work for SVG glyphs too. I really want FT_GlyphSlot
to be self-sufficient and ready for a renderer to handle it without
any additional calls. This could be a new glyph format.

2) then FT_Render_Glyph just calls a color renderer which quickly
allocates the entire CBox of memory and just blends the layers
possibly using FT_RASTER_FLAG_DIRECT for speed. We can eventually have
gradient support as well.

Even if Skia/Chromium does not care about the rendering part, FreeType
should and it needs complete immediate glyph description.

> I've added a set of FT_Paint_* / FT_COLR_* structures to freetype.h
> representing the primitives in the COLR v1 Gradients spec here:
> https://github.com/googlefonts/colr-gradients-spec/blob/master/colr-gradients-spec.md

Great.This can and should be stored as FT_GlyphSlot->other array for
each contour / layer defined.

> I've also added two new main entry points:
>
>   FT_EXPORT ( FT_Bool )
>   FT_Get_Color_Glyph_Layer_Gradients ( FT_Face   face,
>FT_UInt   base_glyph,
>FT_UInt   *aglyph_index,
>FT_COLR_Paint *   paint,
>FT_LayerIterator *iterator );
>
> For retrieval of the v1 layers, returning an FT_COLR_Paint union with
> solid, linear or radial gradient information depending on the union's
> format identifier.
>
>   FT_EXPORT ( FT_Bool )
>   FT_Get_Colorline_Stops ( FT_Face   face,
>FT_ColorStop *   color_stop,
>FT_ColorStopIterator *iterator );
>
> This methods work analogously to the layer retrieval functions for
> COLR v0 and v1, but defines a new ColorStopIterator to retrieve color
> stops of a gradient without requiring large client side allocations.

It is this iterator complexity which I do not like. Why not load
everything into FT_GlyphSlot?

Regards,
Alexei



Re: Gradient Color Fonts, COLR v1 Contributions to FreeType

2020-07-10 Thread Dominik Röttsches
Hi Werner and others,

I've made some progress with the COLR v1 extension implementation in
FreeType and would be happy to hear initial feedback on the general
approach and API style.
I am not requesting a full review yet, but I would be very happy if
you had some time to take an initial high-level look. (Caveat: The
code still has a set of TODOs and formatting needs tuning to follow
the FreeType conventions more precisely).

I've added a set of FT_Paint_* / FT_COLR_* structures to freetype.h
representing the primitives in the COLR v1 Gradients spec here:
https://github.com/googlefonts/colr-gradients-spec/blob/master/colr-gradients-spec.md

I've also added two new main entry points:

  FT_EXPORT ( FT_Bool )
  FT_Get_Color_Glyph_Layer_Gradients ( FT_Face   face,
   FT_UInt   base_glyph,
   FT_UInt   *aglyph_index,
   FT_COLR_Paint *   paint,
   FT_LayerIterator *iterator );

For retrieval of the v1 layers, returning an FT_COLR_Paint union with
solid, linear or radial gradient information depending on the union's
format identifier.

  FT_EXPORT ( FT_Bool )
  FT_Get_Colorline_Stops ( FT_Face   face,
   FT_ColorStop *   color_stop,
   FT_ColorStopIterator *iterator );

This methods work analogously to the layer retrieval functions for
COLR v0 and v1, but defines a new ColorStopIterator to retrieve color
stops of a gradient without requiring large client side allocations.

I'm attaching git format-patch style patch on top of ToT, and you can also use
https://github.com/drott/freetype2-colr/compare/master...colrV1ApiSquashed
if you like for providing feedback.

Thank you very much in advance for taking a look. I'll be
out-of-office for two weeks but I'll respond to any feedback as soon
as possible when getting back.

Dominik

On Tue, Jun 30, 2020 at 11:46 AM Dominik Röttsches  wrote:
>
> Hi Werner,
>
> thanks for the encouragement.
>
> On Tue, Jun 30, 2020 at 10:40 AM Werner LEMBERG  wrote:
>
> > > In a team effort with Roderick Sheeter & Cosimo Lupo & Dave Crossland
> > > (Google Fonts) and myself (Blink/Chrome)
> >
> > ... and Behdad Esfahbod ...
>
> Yes!
>
> > Thanks.  Are there fundamental differences to the googledocs version at
> >   
> > https://docs.google.com/document/d/1EPndWsdMK_M135FOIxQZ--dHpH727rXEBvLZqgIzZvs/edit?ts=5de68042#heading=h.no8g2ykeo8za
>
> I don't think there are major differences, we moved it to GitHub to
> allow public comments and issue tracking.
>
> Dominik


0001-Draft-COLR-Table-v1-Gradient-Extensions-API-Proposal.patch
Description: Binary data


Re: Gradient Color Fonts, COLR v1 Contributions to FreeType

2020-06-30 Thread Dominik Röttsches
Hi Werner,

thanks for the encouragement.

On Tue, Jun 30, 2020 at 10:40 AM Werner LEMBERG  wrote:

> > In a team effort with Roderick Sheeter & Cosimo Lupo & Dave Crossland
> > (Google Fonts) and myself (Blink/Chrome)
>
> ... and Behdad Esfahbod ...

Yes!

> Thanks.  Are there fundamental differences to the googledocs version at
>   
> https://docs.google.com/document/d/1EPndWsdMK_M135FOIxQZ--dHpH727rXEBvLZqgIzZvs/edit?ts=5de68042#heading=h.no8g2ykeo8za

I don't think there are major differences, we moved it to GitHub to
allow public comments and issue tracking.

Dominik



Re: Gradient Color Fonts, COLR v1 Contributions to FreeType

2020-06-30 Thread Werner LEMBERG


> In a team effort with Roderick Sheeter & Cosimo Lupo & Dave Crossland
> (Google Fonts) and myself (Blink/Chrome)

... and Behdad Esfahbod ...

> we have proposed and published an OpenType extension to the COLR
> table to bring color gradients to color vector fonts.

Thanks.  Are there fundamental differences to the googledocs version
at

  
https://docs.google.com/document/d/1EPndWsdMK_M135FOIxQZ--dHpH727rXEBvLZqgIzZvs/edit?ts=5de68042#heading=h.no8g2ykeo8za

which even I have made suggestions to?

> I've started prototyping support for the COLR v1 additions to FreeType
> in a local repository.

Great!  Looking forward to your code :-)


Werner