drawing: tokenise vector drawings like VSFilter

Our old code deviated from VSFilter in many ways, though
the tokenisation differences only affected nonsensical
or technically invalid drawing command sequences.

While it is possible to retrofit the existing tokenisation loop
to emulate VSFilter’s logic, the result is not as readable as just
directly using greedy point aggregation and a search for the next
valid command similar to VSFilter.
Unfortunately, this has the downside of making the individual
compatibility changes/issues less visible in the diff. Instead
they are spelled out below:

 - VSFilter ignores invalid commands together with their coordinates.
   Prior to this, libass ignored invalid commands itself but appended
   their coordinates to the preceding valid command. This was even
   intentionally exploited to (not-)implement p, resulting in different
   behaviour if p was following something other than s.
 - VSFilter will accept n as the first node
   if an _invalid_ m command appeared before
 - VSFilter drops points from b which are not part of a triplet.
 - VSFilter ignores s commands with less than three points.
 - VSFilter ignores p commands if there aren’t at least 3 nodes yet.

(The last one strictly speaking only holds for xy-VSFilter and
 MPC-HC ISR — but guliverkli2 VSFilter just crashes on such input)

Furthermore, until now libass recognised q for conic bezier in the
tokeniser. This does not exist in VSFilters and was also never
implemented in libass’ token-to-outline parser.

Other than the lack of distinction between spline start and extension
nodes (which also requires support in the parser) our tokenisation
result should now exactly match modern VSFilters.

0 files changed, 0 insertions, 0 deletions