- Closed paths are not yet rendered correctly when the final (
\pgfpathclose
) segment is an edge case. There are multiple reasons for this:invisibleline
andclosepath
segments must be checked for the edge case, which is not implemented yetinvisibleline
andclosepath
segments must be shortened on both ends, so their start and end angles must be set correctly. Furthermore, they must be shortened even though their previous/subsequent segment is formally invisible. Neither is implemented- If the above were implemented, there may still be issues left to solve
- consider splitting
tikzlibrarynfold.code.tex
into a pgf and a TikZ library, as most of it does not need TikZ - look for potential issues with large paper sizes
- pull request to TikZ/pgf to simplify code injection
angle too sharp
detection: Is there a better way to detect if we move a point back too far?- May be possible for lines but very hard for curves
- do curvature checks and throw warnings at the start and end of offset segments
- remove direct and indirect
\pgfmathparse
calls, mostly in the joins- check if
\pgf@nfold@roundjoin
can be simplified before optimising
- check if
- add
\else
in various places (likely better performance) - the
A1A4
length is computed for every offset; this is something we could cache from the subdivision phase - faster, less precise
veclen@
-> this is being used a lot- if
x > y
, computex*(1+(y/x)^2)^(1/2) approx x*(A+B*(y/x)^2)
; optimizeA=1.
andB=.5
over the unit circle - could copy a lot of the existing veclen code; maybe skip the "scaling for precision" steps?
- if
- rendering: are quick commands an option?
qmoveto
,qlineto
etc.?