Bounding box calculation

googlefonts / cu2qu

Cubic-to-quadratic bezier curve conversion

Apache License 2.0

64 stars 21 forks source link

Bounding box calculation #190

Closed punchcutter closed 4 years ago

punchcutter commented 4 years ago

Using cu2qu through otf2ttf on a number of OTFs doesn't give perfect results in some cases. It appears to happen most when curves do not have points on extremum. In the attached fonts the C and o are clear examples. Advanced width appears to be fine, but the bounding box is off.

A visual diff: cu2qu_diff

AFa724a4c6ad991aa.zip

behdad commented 4 years ago

The glyph seems shifted. Did you mean to say LSB issue, not bounding box?

I don't see how this is cu2qu issue.

punchcutter commented 4 years ago

No, I don't mean LSB because that doesn't change. Here's the before/after from "C":

behdad commented 4 years ago

I'm guessing that the otf2ttf script is calculating hmtx LSB wrong. Maybe it sets it to the control-box X-min of the cubic glyph, not the quadratic? That would explain the kind of shift you are seeing.

behdad commented 4 years ago

Yeah that makes sense. If there's no extrema points on X/Y axes, then LSB/TSB will be different for quadratic glyph, so the hmtx/vmtx LSB/TSB need to be updated to match, or glyph will show shifted rendering.

punchcutter commented 4 years ago

Yeah, that totally makes sense. There's no explicit handling of hmtx or LSB which I assume is because it worked fine in most cases and nobody noticed until now. This whole process did reveal some relatively minor yet less than ideal cu2qu conversions in some spots, but that's unrelated to this so I'll open another issue for that.

behdad commented 4 years ago

Thanks. Feel free to mention me. I'm not watching the project.