[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GSoC 2020 - Porting font-rs rendering engine to FreeType
From: |
Werner LEMBERG |
Subject: |
Re: GSoC 2020 - Porting font-rs rendering engine to FreeType |
Date: |
Wed, 25 Mar 2020 15:42:41 +0100 (CET) |
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