-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
_qcurveto_to_svg fails with specific paths #304
Comments
As a workaround, add a check if def _qcurveto_to_svg(points) -> SVGCommandGen:
for control_pt, end_pt in pathops.decompose_quadratic_segment(points):
+ if end_pt is None: continue
yield ("Q", control_pt + end_pt) |
thanks for the details bug report, yes this is a know issue introduced by latest skia-pathops 0.8, see googlefonts/nanoemoji#455. |
no that would not be the correct fix, I'm afraid. Please pin the version for now, I will fix it soonish |
Thank you, i just tested and it works with the 0.7.4 version |
Fixes #304 Fixes googlefonts/nanoemoji#455 Fixes googlefonts/noto-emoji#429 since skia-pathops v0.8.0, the Path.segments (SegmentPenIterator) may yield segments with an on-curve point set to None when closed contour is only comprised of quadratic beziers and all the on-curve points can be implied as in-between consecutive off-curve points (special TrueType quadratic spline), this was to match FontTools pen protocol, which the SegmentPenIterator is supposed to work with. Picosvg was using this interface for converting from pathops.Path to SVG path.d strings, and uncaught TypeError was being raised when that happened. However, it turns out picosvg can avoid the SegmentPenIterator altogether when converting from pathops.Path to SVG, because the Path's RawPathIterator (i.e. iterating over the path itself as opposed to Path.segments) already yields (verb, points) for individual segment that matches what SVG expects (in this particular case, a move, a list of quadratic bezier segments each with one off-curve point, and a close command, no fonttools-style implied points anywhere). This way we can translate between SVG<=>pathops.Path in a more straightforward way (since they are closed to one another than to fonttools pen protocol more geared to font format specifics).
While using nanoemoji to build a font, I encountered a case where
nanoemoji.write_part_file
fails with this error:When debugging, the last point is
None
:Minimal reproducible svg file:
Command:
Minimal reproducible code using picosvg:
This only occurs when the viewbox size is 16x16, the SVG renders fine in all browsers and editors, is this a bug or I'm just misusing it?
Edit:
After some debugging, it looks like the root problem is in the skia_path:
Output (has None in points):
It looks like there's a problem in the method
close
ofpathops._pathops.Path
class, here is the full log of each iteration of the commands, notice in the last command "Z", it makes the last point insegments
None
:The text was updated successfully, but these errors were encountered: