Implement plugins to support (subset) fonts in standalone CFF1 and Type1 format #704
Conversation
This reverts commit cc7715a.
| @@ -317,7 +317,7 @@ function addGlyphNamesAll(font) { | |||
| const c = charCodes[i]; | |||
| const glyphIndex = glyphIndexMap[c]; | |||
| glyph = font.glyphs.get(glyphIndex); | |||
| glyph.addUnicode(parseInt(c)); | |||
| glyph && glyph.addUnicode(parseInt(c)); | |||
There was a problem hiding this comment.
you already used the optional chaining .? syntax early on,
so keep it unified (I have no preference, so it's up to you to chose one :) )
There was a problem hiding this comment.
Oh, did I use optional chaining? I thought that would throw an error with the current reify setup... I'll take a look at it!
There was a problem hiding this comment.
| @@ -0,0 +1,33 @@ | |||
| export const plugins = []; | |||
There was a problem hiding this comment.
would it be cleaner to abstract/hide this plugins array with a registerPlugins
so we could do all the registration check (typeof == function etc...) at registration time
(just a suggestion)
There was a problem hiding this comment.
I thought about that as well, but then we'd also need methods to unregister a plugin and change the execution order in case two plugins modify the same entry point data. I think everyone should be familiar with modifying an array, so we should be fine leaving this without abstraction.
| let isResponsible = new WeakMap(); | ||
|
|
||
| const plugin_cff1file = { | ||
| parseBuffer_signature: function(returnData, params) { |
There was a problem hiding this comment.
I think there are two ways of declaring a method:
parseBuffer_signature: function(returnData, params) {parseBuffer_signature(returnData, params) {one of them bind the this at creation , the other at runtime
(maybe this would help avoid using those .call() usage ?)
There was a problem hiding this comment.
Good point, I'll take a look at it
Description
This PR implements a simple yet flexible plugin API and demonstrates its use with two plugins for parsing additional font formats, as well as some fixes.
The plugin API has not been documented in the README yet. It may still change drastically before we finally release 2.0.0, as we should figure out in which other places plugin hooks make sense and what data to supply to each entry point.
buildanddistseparate plugin filesMotivation and Context
My PR #648 tried to achieve the graceful parsing by implementing a custom logger functionality, but that idea didn't seem to get any traction. This PR now achieves the same by logging warnings and errors to the console instead of throwing excepions in several places.
How Has This Been Tested?
Added new test fonts and tests for the plugins.
Screenshots (if appropriate):
Types of changes
Checklist:
npm run testand all tests passed green (including code styling checks).