blPathFitTo does not honor fitFlags

[abu-irrational]

I guess fitFlags should be for maintaining xy proportions, but currently it's not used.
I kindly suggest a bit-flag for flipping the y coords too.

[kobalicek]

I think this could be a possible duplicate of #44 ? Maybe time to finally specify what fitFlags should do?

[abu-irrational]

My suggestions:

how to scale the bbox, 4 choices, (2 bits)

• STRETCH (or FILL) - no aspect ratio preserved
• XYFIT (or BESTFIT) - aspect ratio preserved, blPath centered in the given rect.
• XFIT - idem
• YFIT -idem

Default should be BESTFIT but if we don't want to break the blPathFitTo () API, it must be STRETCH

how to align the bbbox, 9 choiches, (4 bits)

• CENTER, N, NW, W, SW, S, SE, E, NE (cardinal directions)
  The default alignment should be CENTER.

Moreover I'd like a
bit-flag YINVERT for inverting the y coords, since many Paths may be upside-down.
(XINVERT could be added for completeness..)

In total 8 bits

[kobalicek]

Do we want any parity with preserveAspectRatio from SVG (https://www.w3.org/TR/SVG11/coords.html#PreserveAspectRatioAttribute) ? Initially I thought about implementing exactly this, but Blend2D can support a bit more

[abu-irrational]

I personally think those SVG setups are unnecessarily complex and use unintuitive terms.
In any case, the two notations are equivalent.
Among my suggestions, YINVERT and XINVERT are a (questionable) extension.

What are the extended features you are thinking about ?

[kobalicek]

I thought about defining fitFlags that would work for two cases:

• BLPath::fitTo() (the case that we talk about)
• BLContext::blitImage() (where the target is a rectangle and not a point)

What comes on my mind is whether to crop the input or not in case that it would overflow the target rectangle or not. Not sure about anything else - I'm okay with invert as these all just manipulate the transformation matrix in the end.

I mean the goal is of course to support things that SVG supports - if the API is a bit different but compatible it's okay.

[abu-irrational]

I hadn't blitImage in my mind, time to refresh my mind ...
If I'm not wrong, when you do blitImage() to a rect, the image is stretched (FILL stretch) to the dst rect. In this case it could be useful to add the fitFlag to specificy how to stretch it (XFIT,YFIT, BESTFIT, STRETCH/FILL) and how it should be aligned to to one side or a corner of the rect (CENTER, N,NW, W, .. ). There's nothing to crop because in any case the image fits (with or without aspect-ratio distorsion) in the dst rectangle.

When you do blitmage() to a point P, the src image (or a subimage) is not stretched, nor cropped, but it scaled/rotated using the currently-set context coordsys. In this case it could be useful to add a way to define which point of the src-subimage to align with P.
Currently it's only NW (top-left corner), but is could be useful to be able to align the CENTER of the subimage to P, the N(orth) ( midpoint of the top side)... and so on.

Of course these are not core-features, they could be easily implemented "over" the current API, but I think they will be very useful in many practice cases. My only wish is that the default flags values should be simple and intuitive and that they won't bloat the API.