-
Notifications
You must be signed in to change notification settings - Fork 483
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(charset): Implemented charset according to specification #616
Conversation
I did a quick review and it looks fine to me, however due to limited time at the moment I might have overlooked something and would like to have another reviewer do a more thorough review and testing. |
I had hoped that this might also fix #117, but unfortunately it does not. Could you take a look at this and see if there's an easy fix for this or if it's a separete problem? |
Thanks for your review, I got it. I will try it. |
I just added the dummy text used to #117 for debugging/fixing |
btw, #117 had a different cause and has meanwhile been fixed |
Understood, this PR is now awaiting review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can't test right now
but found some unnecessary spaces/tabs/newline
and also some unrelated "
to '
changes that would be cleaner if removed.
but otherwise seems good 👍
Thanks for the review. I've got it done. |
What specification was that change from gid* to cid000...* based on? |
@Connum shall we add those test to the CI ? |
I already have a workflow file prepared on my fork that will run the tests for PRs and add a comment with the results, as well as save the report as a build artifact. I just have to think of a way to make sure that it will mark the workflow as failed when a test fails that previously passed. We'll have to store this info somehow. Could do it by automatically updating a file, but that would pollute the commit history, and I'm not sure if we want that. How shall we go about the naming issue? I think we should stay in line with all the other implementations, right? |
I like the idea of a larger test set (even if non-fully-passing) but there is no need for a file to store the delta. just run the test twice:
(more failure = CI return fail) no opinion on the naming, maybe @ln-north have more insight |
That's a good idea. We just have to make sure that it catches when something lets a new test pass but breaks an old one, which would result in no change in numbers, so we'll have to compare the actual test results. |
The notation of 'cid%05d' follows the convention used in major libraries like afdko and fonttools. https://github.com/adobe-type-tools/afdko/blob/master/python/afdko/ttxn.py#L2099-L2101 |
I mean we could probably adapt the script used for rendering the glyphs for the test suite to generate the gid* names for the output, but that doesn't seem to be necessary for any of the other engines. I just want to make sure we don't break anything. |
Description
Implemented Charsets in accordance with the specification
Motivation and Context
How Has This Been Tested?
Types of changes
Checklist:
npm run test
and all tests passed green (including code styling checks).