freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ewald Hew
Subject: [ft-devel] [GSoC-2017] Adding support for Type 1 fonts to Adobe CFF Engine
Date: Mon, 28 Aug 2017 09:55:49 +0800

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)
- 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
46a062c~aedfc70)
- 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)
- 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)
- 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) 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]