SVG import: Fontforge adds a ton of extra points whenever circles are involved #1702
Comments
|
How does it look after you have used menu item " Element / Simplify... / Simplify " on both shapes? When I did that it made the circle 'simpler' with only the 4 on-curve points I'd expect. Also notice how it works on the curve at the base of the 'i's. Both of them get simplified to be smoother. |
|
Simplifying does not remove all the extra points. I tried it. The serifs should be defined with only two points. And it does nothing about the distorted tittle |
|
The left tittle here is the one that is defined with an I did wonder about that Oh, and I also experimented with changing Let me go peek at the code struggling with I'm afraid, though, that I don't understand about "The serifs should be defined with only two points." Can you explain more what is different than you expect? |
|
it ought to look like this: && what is an F-SVG ? |
|
"F-SVG" is just one of the labels used here, assigned to issues to categorize them - 'F' for 'feature' (related to a particular area of FF) , 'SVG' for the SVG handling feature. I'm looking at the SVG code now. Since I'm not that familar with the internals it'll take me a bit of time. I can see that the control points for the splines making up the 'circle' are not set correctly. They are too far away from the on-curve point and so the curves are flattened - that's why it is ugly. |
|
k thankss!! |
|
Umm yeah... I think I've got a solution for SVG circles/ellipses not being understood correctly, but it is a bit ambitious. Is there anyone here up on both splines and bezier math? fontforge/svg.c routine The existing code tries to handle these with quadratic beziers, and setting the spline control points to corners of an imaginary rectangle around the shape. But... _everyone knows_ that quadratic beziers can't approximate ellipses, right? No wonder the result was so ugly, So you need cubic beziers and figure out what to set the control points to, given the rx and ry values. Research finds articles throwing around "magic numbers" and formulas like
Since by inspection of well-done circles (Inkscape) I'd derived numbers like 0.55 and 0.548 finding those articles made me happy. The idea is to change out the control point construction in lines 1799-1821 of In lieu of a PR just yet, here's the changed section: What do y'all need to know to trust all this? References: |
|
Thanks! BTW can't you like use fontforge's own circle tool for that ? |
|
I've tested some more and will create a PR with this fix. Here are example circle and ellipse, imported without the change and then with the change: Strangely, with a recent build (that includes the change) the other aspects that Kelvin was complaining about have gotten better. And I don't know why - it is certainly nothing to do with the SVG circle/ellipse element change Unless forcing one component to use cubic bezier curves improved the whole picture? Has something about fixing up spline curves changed for the better lately? It looks better than even "simplify" can do. Here is the original SVG file imported again. Compare with the original picture from above, repeated below after the recent picture: Splines split minds... |
See fontforge#1702 "SVG import: Fontforge adds a ton of extra points whenever circles are involved" for additional discussions and illustrations. Imported SVG circle and ellipse elements were being implemented using quadratic bezier splines, which is known to be incorrect, as cubic beziers are needed to even approximate these curves. As part of using quadratics, the control points were spaced too widely apart and thus were flattening sections of the curves. fontforge/svg.c routine SVGParseEllipse() is changed to use cubic splines. Additionally the control point distances are determined using a magic constant from formulas described on the web that give a very good approximation to the desired curves when using only 4 splines. Investigation finds that the existing UI circle curve drawing feature within FF already uses cubics (and showing that quadratics were rejected as inadequate) and use of a number near to the ideal magic constant. (fontforgeexe/cvshapes.c :: CVMouseDownShape() and struct ellipse3)
See fontforge#1702 "SVG import: Fontforge adds a ton of extra points whenever circles are involved" for additional discussions and illustrations. Imported SVG circle and ellipse elements were being implemented using quadratic bezier splines, which is known to be incorrect, as cubic beziers are needed to even approximate these curves. As part of using quadratics, the control points were spaced too widely apart and thus were flattening sections of the curves. fontforge/svg.c routine SVGParseEllipse() is changed to use cubic splines. Additionally the control point distances are determined using a magic constant from formulas described on the web that give a very good approximation to the desired curves when using only 4 splines. Investigation finds that the existing UI circle curve drawing feature within FF already uses cubics (and showing that quadratics were rejected as inadequate) and use of a number near to the ideal magic constant. (fontforgeexe/cvshapes.c :: CVMouseDownShape() and struct ellipse3)
|
thank you sm!!!!!!!!! |
When copying and pasting a glyph from Inkscape that has an svg circle in it (like the tittle on the 'i'), Fontforge will distort the circle and add a bunch of unnecessary points to the other paths copied with it—like the stem of the 'i'. The problem gets worse the larger the glyph is scaled. If you convert the circle to a path in Inkscape, the glyph imports fine.
Here's a test svg with two 'i's—they're identical except the blue one has an svg circle as its tittle. (Sorry apparently github doesn't let you upload svgs)
The text was updated successfully, but these errors were encountered: