# Report for week # 1

1. I added `TTAG_SVG` and `FT_GLYPH_FORMAT_SVG`.
2. I modified the `TT_Face` object to store a new `void` pointer named `svg`.
3. I created an structure called `Svg` which is internal to the `sfnt` module similar to how the `Cpal` structure is. This structure contains very basic things like version, number of svg documents, a pointer to the svg document list (this will be used when finding the document containing a particular glyph). Two more fields that will help in memory freeing later.
4. I added two functions to the `SFNT` interface.
1. **load_svg**: will simply create the `Svg` structure mentioned in (3) and set `face->svg` to the newly allocated structure.
2. **free_svg** will free this structure.

After reaching this point I was quite confused about where the SVG data for a particular glyph will be stored inside the whole face object. At first, I wrote the code to find the particular SVG document containing a particular glyph outside FreeType in a simple C file which had access to the internal objects of FreeType. Once I got it working, I decided to try out the following path. It's just me trying to prototype an idea so I didn't care much about memory handling, styling and error handling. I just wanted to get it running and see if it works. I did the following:

1. Created a `TT_GlyphSlotRec` that inherits from `FT_GlyphSlotRec`. At the moment in `master`, `TT_GlyphSlot` is the same as `FT_GlyphSlot`. This doesn't have to be the case as it is not with `CFF_GlyphSlot`. I added two more fields inside it, namely, `svg_document` which will point to the starting of the SVG document (containing a particular glyph) and `svg_document_length` which will be the length of this document.
2. I later added the same two fields to `CFF_GlyphSlotRec` as well. Because SVG tables can exist in both types of OT fonts, those will CFF outlines as well those with TrueType outlines.
3. I modified the `sfnt` interface to add another function `load_svg_doc` which will take a glyph index and find the svg document for it and populate the newly added fields in (1) and (2). This function takes care of Gzip encoding too. So ultimately, the document gets loaded in plain text regardless of whether it was encoded or not.
4. I added some code in `TT_Load_Glyph` and `cff_slot_load` that checks if `FT_LOAD_COLOR` is set AND the font contains an `svg` table, it'll call the `load_svg_doc` function. On a successful return, it'll set the glyph's format to `FT_GLYPH_FORMAT_SVG`.
5. At this point, I think the Slot is ready to be passed to the SVG Renderer for rendering.

This route did break things of course since I changed a structure but some find/replace operations fixed it along with some one line hacks. If this route is to be taken, I would rewrite that part in a proper way. As an example of what broke, every call of the format `glyph_slot->format` where `glyph_slot` is a `TT_GlyphSlot` broke. So I had to modify it to `glyph_slot->root.format`.

After the fixes, the the code works, for both Truetype outlined fonts as well as CFF outlined fonts.

## Future Plan
Depending on your feedback about the work so far, I will decide what to do next. For now I am trying to understand the modules and specifically rendering modules. How they are written and how they are built. Also trying to create the bare bones of an SVG rendering module. Once I progress there a little bit, I think I will focus on the Callback API design for the `pluggable` part. Feel free to suggest modifications in the plan if you have any in mind.

Hopefully the report above is understandable. If things are unclear, let me know. :)