Open jamsch opened 3 years ago
Base: 96.31% // Head: 96.55% // Increases project coverage by +0.24%
:tada:
Coverage data is based on head (
4bc8a47
) compared to base (c0c08b0
). Patch coverage: 96.25% of modified lines in pull request are covered.
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
What's the bug this is solving? The data is flipped because that's the format that makemeahanzi uses, although I'm not sure why it uses that format. The positioner corrects the flip and scales the contents to fit the window so the character should appear correctly on the screen. Is the character not rendering correctly in some scenarios?
Not so much a bug fix, but the intention is to make it easier for users to add in their own custom characters without requiring them to write an algo to vertically flip the paths & medians (which has personally been a source of pain for adding in missing Kana and other writing systems). It should also make it easier to export the character data to SVG to be used outside the library (e.g. on React Native) without requiring scaling transforms.
This change comes from a project that now utilizes these normalized characters. It certainly will warrant a major version update to prevent users from loading in the old characters. I'll be happy to close this though if you don't feel that this is part of the scope of this repo.
What do you think about making the data parsing part of the code replaceable? So, instead of it being hardcoded to the makemeahanzi format, you could pass in a character parsing function as an option that would take in the character JSON in whatever format it's in and return a format that hanzi-writer can work with. By default it would use a parsing function for makemeahanzi, but you'd be able to make your own data format and just pass a formatting option so it would work. That way we wouldn't need to make a breaking change, while still allowing for flexibility in how the character data is structured.
@chanind Yep, makes sense. Will add to this PR with your suggested changes soon.
If I'm understanding you correctly, we'd implement a default character parser/transformer (as we're assuming this is used for hanzi-writer-data
/ hanzi-writer-data-jp
character sets) that flips the Y transform and offsets the Y medians so that it can be rendered normally on the Canvas/SVG renderers (as already done in this PR). For users that already have normalized characters they wouldn't need to go through this step unless their character spec differs from a 1024x1024 bounding box.
Yeah I think that's reasonable. For cases where the data is already in the 1024x1024 and pre-flipped format, you'd still need to pass something into the processCharData
option, or whatever we want to call that param, that keep it from doing any transforms. Maybe something like processCharData: data => data
as an identity function? Or maybe we could create a shorthand like processCharData: 'plain'
or something? By default it would assume the data is in makemeahanzi
format, and the default processCharData
function would act accordingly
This is in anticipation of a major version update to the hanzi-writer-data & hanzi-writer-data-jp packages to fix a core issue with path layouts being vertically flipped. After this change, the only assumption left (in regards to character data) will be that the character's bounding box is 1024x1024.
The fix that will be applied to the characters is listed in this repository:
https://github.com/jamsch/hanzi-writer-char-fixer
BREAKING CHANGE: Users will need to update their hanzi-writer-data & hanzi-writer-data-jp character packages