ThorVG pImpl idiom caused internal data to be scattered
across hierarchical classes. This refactoring consolidates
the data by inheriting pImpl internally, reducing memory
allocation counts and eliminating unnecessary strategy methods.
If the command after `m` is not recognized, it must be recognized as `l` or `L`.
However, if it is not recognized after ending with `z`, all commands after it are ignored.
```
<svg width="100" version="1.0" xmlns="http://www.w3.org/2000/svg" height="100" xmlns:xlink="http://www.w3.org/1999/xlink">
<path style="stroke:#F00" d="m 20,20 0,50 50 0 -50 -50 z 70,70 0,50 50 0 -50 -50 z "/>
</svg>
```
The three specifications below apply.
Specification: https://www.w3.org/TR/SVG/paths.html#ArcOutOfRangeParameters
-
If the endpoint (x, y) of the segment is identical to the current point
(e.g., the endpoint of the previous segment),
then this is equivalent to omitting the elliptical arc segment entirely.
-
If either rx or ry is 0, then this arc is treated
as a straight line segment(a "lineto") joining the endpoints.
-
If either rx or ry have negative signs, these are dropped;
the absolute value is used instead.
The custom implementations of 'strtof' and 'strndup'
present in the svg loader have been moved into a new
'utils' directory (strToFloat and strDuplicate, respectively).
The locale was set while reading the path attr,
which could have caused race conditions between
threads and potentially led to crashes.
Now removed as unnecessary.
@Issue: https://github.com/thorvg/thorvg/issues/1389
Since the arc flags can have values 0 or 1, we reported as
an error cases, when a float value was given.
Since the EBNF grammar can be used, we misread some paths.
Removing the condition that prevents giving a float as a flag solves
this problem and is in agreement with the w3 specs.
strtof's behavior is changed by system locale.
https://linux.die.net/man/3/strtof
Because of this, strtof(10.0000) returns 0.0 in some locales.
When a given value string is locale-independent, strtof has to be
replaced to custom function.
This condition(optimization) is not a step suggested by arc implementation.
https://www.w3.org/TR/SVG11/implnote.html#ArcCorrectionOutOfRangeRadii (Step2)
This code is useful if the arc is too small to represent.
However, scaling often occurs in vectors, which can create unnecessary problems.
example path
<path d="M32.41,20.49a.41.41,0,1,1-.41-.42A.41.41,0,0,1,32.41,20.49Z" transform="translate(0)" fill="#020202"/>
This Array is promoted from SvgVector to use it widely in tvg.
It's similar with std::vector, we can use it instead of it.
Also, svg_loader replaced with it subsequently.
we should avoid code insertion during file dependencies,
such as #include "xxx.h" which has implementations.
This could increase binary size, we can avoid it as possible.
Current patch improves binary size like this:
From: file(2059008) = text(120360) data(8096) bss(80) dec(128536)
To : file(1921832) = text(118429) data(7872) bss(56) dec(126357)
More additional patches will come in to optmize binary size.
When path ends with 'z' or 'Z' command, if 'm' comes as next command,
the current point is incorrectly referenced.
Since 'Z', 'z' means to close the path,
so, Save point and reuse it when 'M' or 'm' is called.
