Working pixel perfect with Designer 2 still does not work which is super frustrating for GUI work

[A_B_C]

3 hours ago, tudor said:

That’s easy to solve: VectorStyler automatically converts those strokes to outlines when exporting.

As does FontLab, of course. So I suppose my explanation attempt is not correct. Could you give an example of a complex path where stroke alignments different from “centred on path” would be more difficult than simple centred alignment?

[tudor]

2 hours ago, A_B_C said:

Could you give an example of a complex path where stroke alignments different from “centred on path” would be more difficult than simple centred alignment?

I'm not a software developer, so I don't know. As I said, it was a guess based on the fact that nobody (except the VectorStyler developer) figured out (or care about) how to implement this feature. There must be a reason for that, and it most likely has to do with the complexity of the math involved. Keep in mind that a vector drawing tool for graphic design does more than just drawing paths. It has to calculate and render everything from simple paths, to paths with overlapping parts, fills, boolean operations, clipping paths, effects, etc. 

One example: in Illustrator, aligning the stroke of a clipping mask (a closed shape) to inside or outside, makes that stroke disappear. It is visible only when the stroke is center aligned. Why? I have no idea, but it's something they still haven't figured out how to fix after so many years.

[fde101]

27 minutes ago, tudor said:

There must be a reason for that, and it most likely has to do with the complexity of the math involved.

It is far more likely that they are using underlying graphics libraries which do not support this, or that they similarly consider that an open path does not have an "inside" and are not thinking in terms of needing to work on pixel boundaries so they don't see a reason to do it.

[loukash]

9 hours ago, fde101 said:

 If a feature is not supported in an export format, the results can be rasterized

… converted to shapes! Aka Expand Strokes.

(In other words: Never give Serif the idea to rasterize even more than necessary! )

[tudor]

This document describing a method for "stroking Bezier paths", seems to confirm that the math involved in this seemingly basic operation is quite complex:

https://arxiv.org/pdf/2007.00308.pdf

Quote

Vector graphics standards such as PDF [Adobe Systems 2008], SVG [SVG Working Group 2011], PostScript [Adobe Systems 1985], PCL [Hewlett-Packard 1992], HTML5 Canvas [Whatwg.org 2011], and XPS [ECMA International 2009] support two basic rendering opera- tions on paths: stroking and filling.

The intuition of stroking a path is like a child drawing in a coloring book by “tracing over the lines” and treating each path as the outline to trace. Filling a path is like “coloring inside the lines.”

The stroking operation on paths—mandated and specified by all the listed standards above—lacks a mathematically grounded theory to define what stroking means. To remedy this situation, we aim to provide a principled theory for stroking and show our theory motivates robust, useful, and GPU-amendable methods for stroking.

 

[fde101]

22 minutes ago, loukash said:

… converted to shapes! Aka Expand Strokes.

Yes, when that is possible, and in this case it usually should be.  I meant that statement in general terms, thus the part you cut off.

[fde101]

1 minute ago, tudor said:

This document describing a method for "stroking Bezier paths", seems to confirm that the math involved in this seemingly basic operation is quite complex:

The math behind many vector operations is quite complex and is riddled with exceptions and special cases that can be quite difficult to get right, but in this case, Serif has actually implemented it already, thus the "expand stroke" feature.

[tudor]

This is interesting: "The stroking operation on paths—mandated and specified by all the listed standards above—lacks a mathematically grounded theory to define what stroking means."

Maybe that's why all apps work with the basic inside/outside convention. It's a straightforward concept that's easier to implement if there is no precise math theory for stroking the paths.

[fde101]

There is no precise mathematical concept for filling paths either.  A path or shape in a pure mathematical sense has no presentation or visibility whatsoever, so any kind of presentational aspect of such a shape would be an extension of the theory.

[pixelworker]

Still a very important topic. Please enhance it for ui design use-cases.