Skip to content

Instantly share code, notes, and snippets.

@parthw1
Last active June 4, 2020 01:08
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save parthw1/58a9168cebf79641fe6ce07bd543a2df to your computer and use it in GitHub Desktop.
Save parthw1/58a9168cebf79641fe6ce07bd543a2df to your computer and use it in GitHub Desktop.
Final report of my Google Summer of Code 2018 experience with FreeType.

GSoC 2018:
Integrating VFlib's TeX format drivers into FreeType

Hi all,
I am Parth Wazurkar, I have been involved into FreeType development as a Google Summer of Code 2018 participant. I have been working on the project Integrating VFlib’s TeX format drivers into FreeType. This is the final report of my GSoC experience with FreeType.

Project Details

GSoC Project Link:
https://summerofcode.withgoogle.com/projects/#5826114384035840

Project Abstract:
Over the summer 2018 I have been implementing drivers for FreeType to support TeX's GF, PK, TFM and VF bitmap font formats by using, the support for these formats already present in the VFlib library and the canonical references for the GF, PK, TFM and VF formats provided in the source code of the TeX tools gftype, gftopk, tftopl and vftovp respectively as references. The drivers are implemented on the lines of existing bitmap font drivers already present in FreeType like BDF, PCF and WINFONTS.

Final Work Product:

  1. GF font driver for FreeType which handles METAFONT’s GF bitmap font format.
  2. PK font driver for FreeType which handles TeX’s PK bitmap font format which are generated from 'gf' files by using the TeX tool gftopk.
  3. TFM auxiliary module for FreeType which handles TeX Font Metric or TFM files which are attached to the 'gf', 'pk' and 'vf' drivers.

Working branch: http://git.savannah.gnu.org/cgit/freetype/freetype2.git/log/?h=GSoC-2018-parth
Full diff: http://git.savannah.gnu.org/cgit/freetype/freetype2.git/diff/?id=401ce90&id2=13338ef

Summer Of Code with FreeType

Following are the overview of my work done during the summer with FreeType:

  1. Getting acquainted with the TeX tools’ canonicals and VFlib’s TeX format drivers.
  • Understanding them was the most important thing as these were going to serve as the base for the new font drivers.
  • Got my doubts cleared and created a roadmap for the drivers.
  1. Understanding the existing bitmap drivers in FreeType (BDF, PCF and WINFONTS) and getting familiar with FreeType’s codebase. (13338ef~a11d8d0)
  • The existing bitmap drivers served as models for the new drivers.
  • I succeeded by understanding the functions to be implemented for the drivers and how the pseudo-OOP in C, helps in integrating these drivers with the complete codebase.
  1. Integrating VFlib’s code for GF driver into FreeType. (522853e~f7f6a98)
  • VFlib’s code was integrated into FreeType and driver functions were implemented.
  • I faced an initial problem with the bytes extraction functions used by the TeX font formats, this was solved by re-implementing them using the FreeType’s stream support.
  1. Fixing possible bugs, errors, memory leaks, adding tracing and setting up glyph metric values with 'gftype'
    metrics. (2439cfb~5b32e1a)
  • After the code was implemented, various different errors and bugs occurred which were fixed and the GF driver was running.
  • Later on, the GF services were registered and the GF driver was loading glyphs with the freetype2-demo programs.
  • The rendered glyphs were jumping from the baseline and this issue was fixed by appropriately modifying the glyph metric values. (a6bb748~2f59a4c)
  1. Implementing TFM driver as an auxiliary module. (0f41489~d3a7878)
  • As the TFM data would be used by gf, pk and vf drivers. It was decided to create TFM driver as a auxiliary module on the lines of already existing 'psaux' module in FreeType.
  • After the tfm module was implemented, 'attach_file' function was defined in the GF driver to use this TFM module.
  • A major issue was, that VFlib’s code did not follow the 'tftopl' guidelines properly, this was solved by modifying the module functions as per 'tftopl'. (8d32347~fd2b16f)
  1. Implementing the PK driver. (3959431~fbaaeb8)
  • As most of the things were now clear to me, the PK driver was readily implemented in the same way as the GF driver.
  • The PK driver had some issues with glyph loading, which were later fixed and the PK driver was displaying glyphs with the freetype2-demo programs.
  1. Changing the cmap encoding scheme to load glyphs in the order they appeared in the font file. (743b415~e3a53c1)
  • Initially the GF and PK drivers loaded glyphs in the order of their charcode values, it was fixed by completely changing the encoding scheme for both the GF and PK drivers.
  • Now, the glyphs are loaded in the order they appear in the font file.
  1. Implementation of the VF Driver. (parthw-pk-vf)
  • I started implementing the VF driver by creating a branch parthw-pk-vf into the FreeType repository. I later on found out that it was more complicated than what I expected and could not be completed in the GSoC period.
  • Later on after discussions with my mentors, it was decided to complete the VF Driver after the GSoC period.
  • Currently all the code required for the driver has been accumulated and basic functions have been implemented, there are still some loose ends which needs to be fixed.

Thank You All

I had an awesome experience working with FreeType. I would like to thank my mentors and the FreeType community for giving me all the guidance needed along the way. Working with FreeType was my first experience to work with a open source community. I have learnt a lot from the community. My work doesn't get completed here, it is a continuing effort and I look forward to continue contributing to the FreeType project in the future :-)

Best Regards,
Parth

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment