Apologies, it was not my intent to bikeshed. As I said before, I'm looking forward to seeing his results. Either way, happy to offer my experiences off-thread if desired.
On Thu, Jun 4, 2020 at 1:28 PM Alexei Podtelezhnikov <apodt...@gmail.com> wrote: > Jim, Behdad, > > Please hold your horses. This is Anuj's GSoC project for this summer. > It is not nice to take it over until September. For now, please let > him explore the field. Feel free to discuss your own implementation in > a separate thread or at least povide some explanation instead of > abrupt "8.8 makes more sense" or "when I was at Google". This is > highly inappropriate as you had your chance to contribute Distance > Fields before May and will have it after September. > > Best regards, > Alexei > > > > > On Thu, Jun 4, 2020 at 12:39 PM Behdad Esfahbod <beh...@behdad.org> wrote: > > > > 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 > <(919)%20210-7664> > >> > > > > > > -- > > behdad > > http://behdad.org/ > > > > -- > Alexei A. Podtelezhnikov, PhD > -- Jim Van Verth | Software Engineer | jvanve...@google.com | 919-210-7664
