Thanks Jim. A 2.14 representation when 1 unit = 1em is sufficient. If we are talking pixels then 10.6 or better 8.8 makes more sense. And I agree that the pixel values are more useful to clients than em values.
On Thu, Jun 4, 2020 at 8:35 AM Jim Van Verth <jvanve...@google.com> wrote: > 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 > > -- behdad http://behdad.org/
