Re: GSoC 2020 - Porting font-rs rendering engine to FreeType
Thanks for the quick reply, Werner. [...] The actual raster part is mostly in `src/raster.rs' which is > > quite small. Also, creating a C wrapper for Rust code is an easy > > process (compared to other programming languages). Given the small > > size of the rendering engine it seems that implementing it from > > scratch in C inside FreeType isn't too hard either. Though I don't > > know if there is any advantage to doing that? The dependency issue > > maybe? > > Please always have embedded systems in mind. On such platforms it's > rather unlikely to find a Rust compiler, thus a conversion to C sounds > sensible. > Yes, that's a good point. Although Rust is gaining popularity in Embedded Systems, most systems still don't have Rust Compilers. > I don't have any special tips or requirements for a proposal. :-) > Gonna start working on it then. :-) I have come up with an extremely good algorithm for cubic to linear > conversion, it's at https://levien.com/tmp/flatten.html. The lyon people > have ported this to Rust, see https://github.com/nical/lyon/pull/552. > It's based on ideas from my blog post > https://raphlinus.github.io/graphics/curves/2019/12/23/flatten-quadbez.html > but > goes beyond it. I believe that this algorithm is very near optimal in both > speed and quality. If selected as a mentor, I will write it up as a paper > (ideally for submission to jctg), and there would be an opportunity for the > student to coauthor that. > This is pretty cool. I'm gonna take a close look at this soon. Just a few days ago I was looking at Inkscape's code. It does path set operations (union, intersection, etc), offsetting, smoothing and tweaking by converting curves to polygons and back. This can be very useful in such applications. Moazin
Re: GSoC 2020 - Porting font-rs rendering engine to FreeType
I agree that for FreeType it makes more sense to port the algorithms to C than to complicate the build system by bringing in Rust. (I think Rust has a lot of potential for this kind of work, but I see that as a quite separate project). I have come up with an extremely good algorithm for cubic to linear conversion, it's at https://levien.com/tmp/flatten.html. The lyon people have ported this to Rust, see https://github.com/nical/lyon/pull/552. It's based on ideas from my blog post https://raphlinus.github.io/graphics/curves/2019/12/23/flatten-quadbez.html but goes beyond it. I believe that this algorithm is very near optimal in both speed and quality. If selected as a mentor, I will write it up as a paper (ideally for submission to jctg), and there would be an opportunity for the student to coauthor that. Experience on resvg is a good qualification for this work :) Raph On Wed, Mar 25, 2020 at 7:42 AM Werner LEMBERG wrote: > > Hello Moazin, > > > > I am applying to GSoC this year as well and I am particularly > > interested in the project "Port the font-rs/fontdue rendering engine > > to FreeType". > > Great! > > > Firstly, I saw that the project obviously requires knowing Rust. > > While I am not a Rust programmer, I do know many of the basics due > > to my experience with `resvg' last year. I'm able to easily read > > and understand Rust code. I'm also going to be improving my > > knowledge of Rust as I further prepare the proposal. I guess this > > should be sufficient? > > Yes, I think. > > > [...] The actual raster part is mostly in `src/raster.rs' which is > > quite small. Also, creating a C wrapper for Rust code is an easy > > process (compared to other programming languages). Given the small > > size of the rendering engine it seems that implementing it from > > scratch in C inside FreeType isn't too hard either. Though I don't > > know if there is any advantage to doing that? The dependency issue > > maybe? > > Please always have embedded systems in mind. On such platforms it's > rather unlikely to find a Rust compiler, thus a conversion to C sounds > sensible. > > > Another thing I saw was that this engine can't handle Cubic Bezier > > curves, only Quadratic. FreeType does support font formats which > > use Cubic Bezier curves. So maybe I can add this functionality to it > > as part of this project. (unless there is something in the > > algorithm that can't be applied on Cubic curves or other font > > formats in general) > > I think this would be a very useful addition. Raph? > > > I think that porting can be done by: > > > > 1. Creating a C wrapper for font-rs (for the rendering part at > >least). > > Well, *only* the rendering part, since the rest is done by FreeType > already. > > > 2. Creating a new rendering module in FreeType that can provide the > >necessary "glue" code. > > Yes. As mentioned above, a conversion to C would be useful, too. > > I don't have any special tips or requirements for a proposal. :-) > > > Werner >
Re: GSoC 2020 - Porting font-rs rendering engine to FreeType
Hello Moazin, > I am applying to GSoC this year as well and I am particularly > interested in the project "Port the font-rs/fontdue rendering engine > to FreeType". Great! > Firstly, I saw that the project obviously requires knowing Rust. > While I am not a Rust programmer, I do know many of the basics due > to my experience with `resvg' last year. I'm able to easily read > and understand Rust code. I'm also going to be improving my > knowledge of Rust as I further prepare the proposal. I guess this > should be sufficient? Yes, I think. > [...] The actual raster part is mostly in `src/raster.rs' which is > quite small. Also, creating a C wrapper for Rust code is an easy > process (compared to other programming languages). Given the small > size of the rendering engine it seems that implementing it from > scratch in C inside FreeType isn't too hard either. Though I don't > know if there is any advantage to doing that? The dependency issue > maybe? Please always have embedded systems in mind. On such platforms it's rather unlikely to find a Rust compiler, thus a conversion to C sounds sensible. > Another thing I saw was that this engine can't handle Cubic Bezier > curves, only Quadratic. FreeType does support font formats which > use Cubic Bezier curves. So maybe I can add this functionality to it > as part of this project. (unless there is something in the > algorithm that can't be applied on Cubic curves or other font > formats in general) I think this would be a very useful addition. Raph? > I think that porting can be done by: > > 1. Creating a C wrapper for font-rs (for the rendering part at >least). Well, *only* the rendering part, since the rest is done by FreeType already. > 2. Creating a new rendering module in FreeType that can provide the >necessary "glue" code. Yes. As mentioned above, a conversion to C would be useful, too. I don't have any special tips or requirements for a proposal. :-) Werner
