Behdad, Thanks for the pointer to cu2qu, I'll take a look at it. I assume you're suggesting we use that in place of GrPathUtils::convertCubicToQuads. I believe in our case we chop at inflections to avoid artifacts from our resolution independent curve rendering.
As far as scale for our SDFs, 1 unit in distance is one pixel. And Anuj, I'm not sure 2.14 is enough precision in the integer part. It's been a while, but I believe I got better results with at least 3 bits of integer. On Wed, Jun 3, 2020 at 6:33 PM Behdad Esfahbod <beh...@behdad.org> wrote: > Jim, > > I see that in your implementation you are converting cubics to quadratic > spline. That makes a lot of sense and I support that. For the conversion > though, I see a messy piece of code, which is typical of that kind > of thing. I like to introduce you to cu2qu algorithm which we designed and > implemented back when I was at Google. It has a much simpler algorithm, > which is very robust by design and has been used in production of thousands > of fonts in recent years with no bug report whatsoever. The core algorithm > is very simple: > > https://github.com/googlefonts/cu2qu/blob/master/Lib/cu2qu/cu2qu.py#L218 > > Here's a highlevel description of the algorithm: > > https://github.com/googlefonts/cu2qu/issues/10 > > This was specifically designed to have very good behavior for encoding the > results in a 'glyf' table. But is useful for more general uses as well. > > It would work much better if we break the input curve on cusps if any. > But even that has not been an issue: > > https://github.com/googlefonts/cu2qu/issues/6 > > Cheers, > behdad > > > On Wed, Jun 3, 2020 at 3:16 PM Behdad Esfahbod <beh...@behdad.org> wrote: > >> Hi Jim, others, >> >> Thanks for your input. I've been meaning to get into the discussion as >> well but didn't get to. >> >> I support your suggestions: generate from vector instead of bitmap, as >> well as 8-bit 3.5 fixed point or similar at least as an option. In your >> 3.5 fixed-point, does one unit reflect 1em, or 1 pixel at the SDF size? >> >> I think we do want a 8bit representation at least, and possible a higher >> one. >> >> On Wed, Jun 3, 2020 at 10:26 AM Jim Van Verth <jvanve...@google.com> >> wrote: >> >>> Forgive me for coming into this late -- a colleague pointed me to this >>> thread a couple of days ago and I'm just catching up. I work on Skia, and >>> we've been generating SDFs from glyphs for quite some time now, so the >>> possibility of just getting them from Freetype is pretty exciting. >>> >>> I hope you don't mind some comments on what we have now. We currently >>> use the Gustavson algorithm to generate them from bitmaps but it produces >>> slightly fuzzy results. I have wanted to move to use this algorithm to >>> generate them directly from the outline which might be useful to you: >>> >>> https://skia.googlesource.com/skia/+/refs/heads/master/src/gpu/GrDistanceFieldGenFromVector.cpp >>> We use it to store atlased paths at the moment and it produces much >>> better results. >>> >>> As far as format, we use an 8-bit 3.5 fixed point format, because it >>> allows us to combine the SDF and bitmap glyphs into the same atlas to >>> conserve space. There is a sacrifice in quality, but we only use the SDFs >>> for larger glyphs so it's acceptable. >>> >>> If you would like more details on our implementation please let me know. >>> I'm looking forward to seeing how this turns out. >>> >>> >> >> -- >> behdad >> http://behdad.org/ >> > > > -- > behdad > http://behdad.org/ > -- Jim Van Verth | Software Engineer | jvanve...@google.com | 919-210-7664
