cu2qu
cu2qu copied to clipboard
googlefonts
Automatically elevate lines to flat curves on incompatibilities (with warning)
It seems it's not uncommon for masters to have a few segments which are incompatible simply because one master's is a curve and another's is a line. In those cases, we can simply promote the line to a flat curve and continue conversion.
Just looked at the code, the way I interprete it, the off-curve controls are positioned exactly where the on-curve controls are, i.e.:
contourPoints.append((None, prevPt, False, None, None))
contourPoints.append((None, pt, False, None, None))
I think I remember this being told to be a bad practice, for designers, because there's no direction for the controls then. Designers should use a tiny offset to the closest on-curve point, to hint the renderer.
Do you have any thoughts about this? Should designers position off curve points directly on the closest on-curve point, or just a bit into the "right" direction? Are there rendering problems with this practice of making on- and off-curve the equal position?
Oh, and, I totally think it is cool to make curves out of lines to make interpolation more compatible :-)
there's no direction for the controls
What do you mean by that? I didn't understand.
I think direction for controls is referring to the directions of the vectors from p0 to p1 and p3 to p2. And I actually don't think there needs to be a direction, since apparently it's not uncommon to see cubic curves in original sources where p0==p1 and p2==p3. It's probably worth mentioning that we can specially handle this case in cu2qu just by turning the curve into a line.
Yea. idk if cu2qu should do this thing I mean it's just a curve converter. Then again it already has a focus on compatibility.
@adrientetar sorry, I missed your question.
there's no direction for the controls
What do you mean by that?
Yes, this:
I think direction for controls is referring to the directions of the vectors from p0 to p1 and p3 to p2.
About this:
it's not uncommon to see cubic curves in original sources where p0==p1 and p2==p3.
That doesn't mean it's good practice either. But, probably it's not that important anyways, I thought it may have something to do with rasterization or so.
Gimme some time to comment here please.
any news on this front? It seems sensible to have this upgrade-line-to-curve feature, even if only as an option.
I've ran into this as well. I don't mind requiring the outlines to be fixed manually. For me the biggest annoyance is that fonts_to_quadratic() stops with a traceback as soon as it runs into the first incompatible glyph. I wish that it skipped such glyphs instead and provided a report at the end.
Ok, here's the problem: for a line p0..p1, what curve do you elevate it to? There is one correct solution indeed, but that's not what many people in this thread expect.
The one correct solution to elevate line to quadratic is p0,(p0+p1)/2.,p1. And correct solution to elevate line to cubic is p0,(2p0+p1)/3.,(p0+2p1)/3,p1. Those are the only curves that match the line t for t. That's important for interpolation. However, the one correct solution is NOT that useful for design work. If you just put the control points on top of the end points, you get different interpolation results. But that's, many times, the intended behavior. In fact, there's infinitely many ways to promote line to curve and only one of them matches the designer's intent. So I'm against automatically doing this.
Does that make sense?