Re: [freetype2] Remove #include FT_XXX_H includes from library sources
Le ven. 5 juin 2020 à 00:00, Werner LEMBERG a écrit : > > This is the first time ever that I got a git bundle to handle, and I'm > stuck. I don't know how to apply it to the git repository. Trying > > git pull freetype2-remove-macro-includes.bundle > > results in > > fatal: Couldn't find remote ref HEAD > > Ditto for `git fetch`. > > Please advise. > > No problem :-) there are several ways to use bundles (and I agree the documentation is lacking): 1) The easy way: use it as a git remote: $ git remote add bundle /path/to/bundle $ git fetch bundle >From /home/david/Downloads/freetype2-remove-macro-includes.bundle * [new branch] remove-macro-includes -> bundle/remove-macro-includes This is convenient because this fetches all the heads from the bundle at once, and gives you remote branches for all the heads in the bundle. 2) The hard way: git fetch /path/to/bundle Where is one of the references listed by "git bundle list-heads /path/to/bundle". For this specific bundle: $ git bundle list-heads ~/Downloads/freetype2-remove-macro-includes.bundle 2ebe58073a90538b64170fc274dc5530032726d8 refs/heads/remove-macro-includes So you could then try: $ git fetch ~/Downloads/freetype2-remove-macro-includes.bundle remove-macro-includes >From /home/david/Downloads/freetype2-remove-macro-includes.bundle * branchremove-macro-includes -> FETCH_HEAD Note that the fetch only creates FETCH_HEAD (which will be overwritten on a future fetch), so you don't have a label defined in your repository. You can create a branch from it easily with: $ git branch remove-macro-includes FETCH_HEAD Hope this helps. Let me know if you prefer a different format. I can probably attach patch files generated with "git format-patch" as well, but bundles are far more convenient and safe. - David PS: To create a bundle that includes all patches from origin/master to a local branch, use: $ git bundle create /path/to/new/bundle origin/master..my_branch This creates a head named "my_branch" in the bundle. > Werner >
Re: [freetype2] Remove #include FT_XXX_H includes from library sources
Hello David, > This bundle contains patches to replace all #include FT_XXX_H > statements from the library into the corresponding #include > include. Thanks! If I understand you correctly, the idea is to 'normalize' FreeType so that it looks similar to other libraries, not alienating users with strange macros, right? > The bundle contains 88 commits. Each one renaming a single macro. I > recommend submitting the bundle squashed after verifying that > everything works, but I'll let you choose otherwise if you > prefer :-) This is the first time ever that I got a git bundle to handle, and I'm stuck. I don't know how to apply it to the git repository. Trying git pull freetype2-remove-macro-includes.bundle results in fatal: Couldn't find remote ref HEAD Ditto for `git fetch`. Please advise. Werner
Re: GSOC - Distance Fields
Dear all, please stay constructive and civilized. No need for personal attacks – in the end we all want the same. I'm glad that there are experts on the list who want to share their experience, and who are willing to help Anuj so that he succeeds. I believe that it is a big help to have different implementations and algorithms to look at, so thank you for the links. Anuj will report his progress from time to time on this list, so if you are interested, please chime in then with further comments. Werner
Re: GSOC - Distance Fields
Well. It is your arrogance against my ignorance. Why haven't you thought about contributing your wonderful DF ideas before? Or, is it again like HarfBuzz autoshaper that has to be separate and you have to control it? On Thu, Jun 4, 2020 at 2:32 PM Behdad Esfahbod wrote: > > For more context: I'm not going to stay silent to your abuse anymore. You > have no idea what distance-fields are used for, never used one, never > generated one, and you are blocking real constructive discussion from people > who actually know that shit. > > On Thu, Jun 4, 2020 at 11:31 AM Behdad Esfahbod wrote: >> >> That's BS Alexei. Eff off.
Re: GSOC - Distance Fields
For more context: I'm not going to stay silent to your abuse anymore. You have no idea what distance-fields are used for, never used one, never generated one, and you are blocking real constructive discussion from people who actually know that shit. On Thu, Jun 4, 2020 at 11:31 AM Behdad Esfahbod wrote: > That's BS Alexei. Eff off. > > On Thu, Jun 4, 2020 at 10:28 AM Alexei Podtelezhnikov > 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 >> 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 >> 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 >> 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 >> 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 >> 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.
Re: GSOC - Distance Fields
That's BS Alexei. Eff off. On Thu, Jun 4, 2020 at 10:28 AM Alexei Podtelezhnikov 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 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 > 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 > 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 > 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 > 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/ > > > > -- > Alexei A. Podtelezhnikov, PhD > -- behdad http://behdad.org/
Re: GSOC - Distance Fields
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 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 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 > 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 > 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 > 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 > 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> > >> > > > > > > -- > >
Re: GSOC - Distance Fields
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 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 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 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 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 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/ -- Alexei A. Podtelezhnikov, PhD
Re: GSOC - Distance Fields
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 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 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 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 >>> 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/
Re: GSOC - Distance Fields
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 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 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 >> 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
Re: Edge effect (Depressed) on a Pixmap buffer using freetype lib
On Thu, Jun 4, 2020 at 8:28 AM Aurovind Sagar wrote: > We are using FreeType. Sorry, the intention was not to report any bug. We are > looking for suggestions. We are not from graphics background, hence please > excuse if we have asked any obvious questions. Guys, you need to learn about alpha blending. In the simplest terms: a glyph bitmap is colorless but rather gives you a proportion of brush and background colors: zeros mean that background is unchanged, 255 means it turns into purely brush color, something in between is a mix of colors. Then you just apply several layers like this: shade first, filled body second, outline third.
Re: Edge effect (Depressed) on a Pixmap buffer using freetype lib
Hi Alexei, We are using FreeType. Sorry, the intention was not to report any bug. We are looking for suggestions. We are not from graphics background, hence please excuse if we have asked any obvious questions. As Niyas mentioned, everytime we write new stuff onto the pixmap it would overwrite that particular area. So the whole logic of creating edge effect by writing font at different positions with single pixmap is not helping. We have 2 options in minds (not so concrete), - If we can skip drawing of the pixels of non-font area in bounding box. Then we would not be overwriting. But this looks to be a bit tedious to implement. - Create one more buffer which will have only edge drawing. And render both (one with actual font and a new with edge) in the order of edge buffer first and then font buffer. As creating edge might be an usual need, we thought of seeking inputs from you & team. Thanks Sagar On Thu, Jun 4, 2020 at 5:43 PM Alexei Podtelezhnikov wrote: > > Now here the problem what we are facing is when we load the glyph we get > the data in a bounding box. The glyph which is loaded is a greyscale and it > is with bounding-box. So when we draw the edges and font as per the above > logic, the bounding boxes of the edges and the font gets overlapped. Note, > it is a pixmap buffer. > > At this stage you are no longer using FreeType. So why do you report > your bug here? The bug is in whatever toolkit you use for blending or > in your code if you do blending yourself. >
Re: Edge effect (Depressed) on a Pixmap buffer using freetype lib
> Now here the problem what we are facing is when we load the glyph we get the > data in a bounding box. The glyph which is loaded is a greyscale and it is > with bounding-box. So when we draw the edges and font as per the above logic, > the bounding boxes of the edges and the font gets overlapped. Note, it is a > pixmap buffer. At this stage you are no longer using FreeType. So why do you report your bug here? The bug is in whatever toolkit you use for blending or in your code if you do blending yourself.
