Pseudocode for vectorization?

[ctrlcctrlv]

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]

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]

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]

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

• Vector vs Raster vs Hybrid...
• Ink/Paper vs Grayscale vs Color vs BRDF...
• Ideal vs Screen (may influence hinting and rounding)...

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.