search

googlefonts / colr-gradients-spec

63 stars 8 forks source link

Pseudocode for vectorization? #357

Open ctrlcctrlv opened 2 years ago

ctrlcctrlv commented 2 years ago

I was thinking about this while contemplating sile-typesetter/sile#1273, but certainly the use case of SILE is indeed a common one, where the best output would indeed not be a bitmap image, but instead some vector format; in the case of SILE, PDF-flavored PostScript; in the case of e.g. #288, SVG.

Would it be beneficial to have a section of the document detailing the general process and considerations that need to be taken by those thinking of working in vector space?

drott commented 2 years ago

What kind of rules or explanations would you benefit from? Do you have a particular backend in mind? Do you mean it may be beneficial to describe what primitives to place into a vector output?

For reference, and this may be known already, the BlackRenderer has an SVG backend: https://github.com/BlackFoundryCom/black-renderer/tree/main/Lib/blackrenderer/backends

ctrlcctrlv commented 2 years ago

Yes I mean that it would be beneficial to describe even the broad strokes of what we need to implement. Do we need boolean operations on Bezier paths? Do we need to be able to apply matrices to points and what size matrices? I think the answer to both of these is yes and to the second PostScript sized but it has been a while since I asked this and I didn't look it up before replying heh

reli-msft commented 2 years ago

It might be a good idea to define various "output device types". The device types could have multiple dimensions:

I think it should be possible to define a drawing semantics on Vector + Ink/Paper devices for a certain subset of Paints. And perhaps, we should introduce a "WithDeviceTypePaint" to allow a COLRv1 table to behave differently under different circumstances.