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
_______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
