# OpenType SVG support to FreeType
## Report Week # 2

I started the week with creating the barebones of a new module in FreeType, which is supposed to be a Renderer. The commit [6b4d097](https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?h=GSoC-2019-moazin&id=6b4d097bf881bcce1c5f53e99bf9e72bb8d77e23) shows this. I struggled with creating a new module. The FreeType build system is quite complicated and my knowledge of Makefiles is weak. But looking at how other modules did it, I got mine working too.

Instead of just creating an FT_Renderer (aka FT_RendererRec*) I created a new structure `SVG_RendererRec` that inherits from `FT_RendererRec` and adds two more fields `loaded` and `hooks`. `loaded` is a simple flag I am using and `hooks` is just an structure containing the hooks. I could of course store these hooks in `FT_Face` or somewhere else. But I felt like it's better to keep this in the module itself, since the hooks weren't going to be used anywhere else.

Within this time, I also spent a lot of time rendering different SVG glyphs from various freely available fonts using `resvg` and `librsvg`. Tried to observe how these libraries behave in various cases, bounding box features they had, render by ID functions etc. I wrote code that could render SVGs tightly along with giving `bitmap_left` and `bitmap_top` values outside FreeType. I also initiated the discussion in the list.

After having done this, it was time to create the mechanism for hooks. Decide on what hooks will exist, how they'll behave and how a client is supposed to plug them from outside. For now I am ignoring the part about a default one coming out-of-box with FreeType. Once everything is decided, that can be added too. The commit [9eef232](https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?h=GSoC-2019-moazin&id=9eef232ca1e2a1a8f0950a839f4f67f1e1516926) shows this work.

Temporarily, I have only created three hooks.
* For initialization that will be called only when the first SVG is to be rendererd.
* For cleanup that I haven't filled in yet.
* For rendering that just takes the GlyphSlot and fills the bitmap in.

This is just temporary and is going to be under discussion soon.

### How the Rendering works

* The module stores the hooks which at the moment are three function pointers only.
* This module exposes an interface via `module_interface`, which at the moment only contains a single function, `set_hooks`, which can be called to inject the hooks.
* A new API function `FT_Set_Svg_Hooks` can be used to inject the hooks. This function ultimately finds the Renderer, gets its interface and uses `set_hooks` to inject the hooks.
* The `render` function of the Renderer, simply relies on the third hook. Just passes the whole Slot to it. This is again, temporary. Everybody is most welcome to start discussing this.

### A temporary port for testing

I started working on a temporary rendering port based on `Resvg`. Ultimately plugging it in, I got it working and rendering an SVG, at multiple sizes too. :) `bitmap_left` and `bitmap_top` are not being filled in at the moment. I am trying to study Toshiya's point about the bearings being the same in SVG Glyphs as they are in the corresponding CFF/TTF outlines in the same font. Will let you guys know about my findings.

I am attaching a zip file and a shell script, if you place the script as well as the zip in one new folder and run the shell script, it might compile and work. IMPORTANT NOTES ABOUT THIS:

* Only works if you have the latest Rust kit installed. Get it via Rust Up.
* Only works on Linux.
* Libaries are hard coded in Makefiles. You might need to add or modify stuff to make it run. Sorry about this. This is just something very temporary and I don't want to spend too much time learning `Make` and creating a good build system. Will do that sometime soon.