Pomax
Approximate cubic-to-quadratic conversion
I'm wondering whether you can produce a cubic-to-quadratic conversion function toQuads([error]). This is extremely useful for producing TTF fonts.
Genuine question, given that I've written font parsers and still help out on font libraries: if you start with cubic curves, why would you even bother to generate TTF outlines? OpenType directly supports cubic curves through Type2 outlines rather than TrueType outlines, so just build your glyphs as Type2 charstrings, put them in a CFF block, and then use that instead.
TrueType GX for example. Manual hinting another example.
I should have a very good routine for this in a few weeks' time.
To answer the original request first: yeah it's entirely possible to add that, I'll see when I have some time.
But as follow up: that still makes absolutely no sense. Don't design in cubic curves and then convert them to quadratic, just design in quadratic curves; there are tons of packages that let you do that. Heck, even Canvas2D does.
@Pomax Most web fonts are provided in TTF because CFF OTF cannot be rendered well under small sizes, compared to TT.
As massively sweeping statements, I plain don't believe you on either point. However, if you have some articles that back those claims up, I'll be happy to read them and possibly revise my opinion.
Won't argue that, but if you need the control, restrict the cubic curve to only allow shapes that correspond to degree-elevated quadratics. Then your conversion error is zero - I don't buy the "design and then throw away the design by lossy conversion" concept, that's doing typeface design backwards.
@Pomax you can see rendering comparison at http://kltf.de/kltf_notes_raster.shtml . For many years CFF OTFs are not rendered well on many platforms, especially Windows GDI.
For webfonts, 1/1000em is an acceptable error.
Windows GDI, however, no longer exists as a serious technology, Windows has moved on and these days it's all Direct2D and DirectWrite. If the argument is "historical" then sure, but that makes no sense: webfonts are a recently popular technology, and the rendering engines that we had when we suddenly all started using webfonts were bad at them. Obvious, one of the two flavours is going to be better given those historical limitations. So the way forward there was (and has been worked on quite a lot!): update the render engines instead of settling for that old technology. Everything has to update around each other, and font render engines used in browsers are steadily improving to match what we're now demanding they support, given the web context we now heavily use fonts in.
I'm going to add in the conversion functions, but I don't buy the "let's all use TTF on the web instead of forcing browser makers to use engines that properly support OpenType for web rendering purposes" argument =)
(if CFF still renders poorly at human readable small sizes in modern browsers on modern devices, that's a valid point, except for Safari, since Apple is clearly not interested in support the web in the slightest, and their browser reflects that for a vast amount of web specs and technologies)
Well at least CFF CJK fonts (like Source Han Sans) ARE still rendered poorly at small sizes on Direct2D. D2D turns OFF y-direction antialiasing when the text size is smaller thant 20px, unless you add a special GASP entry to turn it on manually.
indeed - the engines aren't perfect yet: let's make sure the people who can fix that are confronted with the fact that there is a pressing need for them to fix it.
An(other) argument in favor of ttf vs. otf: the fill rule of otf is unspecified. When there are overlapping paths, different OS render fonts differently. Windows has a particularly strange behavior, as it uses different fill-rules for different font-sizes. This is the cause of the rendering problems that Prototypo is producing on Windows.
We have three solutions to solve that problem and render fonts in real-time without holes and glitches
- implement our own canvas based text rendering and layout algorithm
- merge all paths of all displayed glyphs in less than 16ms
- approximate cubic to quadratic and generate .ttf, for which the fill-rule is specified
The third option looks like the most reasonable one to us at the moment. The fonts would b exported to merged .otf though, as the speed of that export doesn't matter much, not as much as the quality/fidelity of the font anyway.
PS: I just discovered cubic2quad and will likely use that package.
that looks like a decent solution. Any solution I'd have implemented would have probably been based on the FontForge code, too.