[ft] [GSoC-2017] Adding support for Type 1 fonts to Adobe CFF Engine

[Ewald Hew]

Hi all,

I am Ewald Hew, and I have been involved in FreeType development as a
participant of GSoC.
Over the summer, I have been implementing support for Type 1 fonts in the
CFF engine that Adobe has contributed, and have achieved improvement in
hinted
output for Type 1 fonts similar to that for CFF fonts.

Working branch:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/log/?h=GSoC-2017-ewaldhew-wip
Full diff:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/diff/?id=423d7cf&id2=a650c95^

Following is an overview of changes made and challenges faced:

1. Moving the Adobe engine from `cff' to `psaux' modules. (a650c95~2cef133
<http://git.savannah.gnu.org/cgit/freetype/freetype2.git/diff/?id=2cef133&id2=a650c95^>
)
- This was important to move the engine from a CFF-only component to an
inter-module service.
- I was relatively new to the codebase then, unfamiliar with the pseudo-OOP
in C, and faced initial difficulty following code paths and finding
separation points between the engine and module.
- I succeeded through a mix of cross-referencing, discussion, and checking
compiler errors.

2. Make Type 1 and CID glyph loading use this new service. (d6983de~a4b0acf
<http://git.savannah.gnu.org/cgit/freetype/freetype2.git/diff/?id=a4b0acf&id2=2cef133>
,
46a062c~aedfc70
<http://git.savannah.gnu.org/cgit/freetype/freetype2.git/diff/?id=aedfc70&id2=46a062c^>
)
- The new engine had to accept objects for glyph loading whether Type 1 or
CFF,
which had subtly different structures. The modules had to access the new
service, a single API, in the same way.
- A significant challenge was implementing "polymorphism" for the loading
objects in the new engine, while keeping old APIs the same if possible.
- I decided to use wrapper objects that simply copied over relevant fields,
thus keeping the Type 1 vs. CFF stuff outside the interpreter.

3. Extending the interpreter to understand Type 1 charstrings.
(7927aff~150c989
<http://git.savannah.gnu.org/cgit/freetype/freetype2.git/diff/?id=150c989&id2=a4b0acf>
)
- Now that Type 1 data would be routed through the new engine, it had to
accept
Type 1 charstrings, which have different rules and operations that were
removed in the Type 2 specification.
- This step required a lot of referencing the spec, and adapting operations
to
match the engine's underlying logic to achieve the correct results.
- Ensuring edge cases were properly covered was a challenge, but the
detailed
tracing output and simple but functional `demos' test suite helped a lot.

4. Testing, debugging, cleaning up. (57b7f9f~423d7cf
<http://git.savannah.gnu.org/cgit/freetype/freetype2.git/diff/?id=423d7cf&id2=aedfc70>
)
- The final step was ensuring that everything works and confirming the
rendering improvements.
- A particularly bad hinting issue was found, caused by a conflict between
hint
declarations in Type 1 and the single-pass hinting engine.
- It was decided to add an extra pass for best hinting results, rather than
to
disable the function and get not as good hinting.
- I also did some other minor fixes to code and comments.


I also went on to investigate an outstanding issue regarding performance of
the
new engine (bug #43248). I achieved some initial success (commit c48e55b
<http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?h=GSoC-2017-ewaldhew-wip&id=c48e55b738b5a3cc57f20eb7b949fcfec5ca9dd4>)
but
I think that further improvement is possible. This will be a continuing
effort
and I do intend to continue contributing to the FreeType project.

I wish to thank my mentors and the rest of the community who participated
in
discussions and helped me refine my solutions and making GSoC with FreeType
a
truly engaging and great learning experience.

Ewald