Fix for #740. #744
Fix for #740. #744
Conversation
|
Cc @readroberts |
|
@anthrotype, should I worry that those AppVeyor tests are failing? I'm afraid I can't make sense of the error details :( |
|
The two additional commits warn when keys are ignored:
|
|
@justvanrossum @anthrotype the setuptools 29.0.0 wheel doesn’t install cli-32.exe anymore. I guess we should stick with 28.8.0 untill setuptools 29 is fixed. @justvanrossum |
|
Thanks Just for looking into this. Don't worry about the appveyor build failing, it seems like a setuptools issue. I'll take care of that later.
|
|
@moyogo beat me to it ;) |
|
Thanks guys, I'll use |
|
on the setuptools Appveyor issue: Just, if you rebase your branch on master, the build should now pass. Denis temporarily fixed that with ea92dd7 |
Commits 3063def and 5b47971 introduced a separate fontDictOperators list for FontDict, only listing those TopDict key/value pairs that are actually used in the FontDict context. It provided a fallback that TTX files containing such "useless" key/value pairs would not be rejected. However, the code still rejected binary fonts that contained such values, even though it didn't before, and yes, such fonts exist. Also: such fonts are not broken per spec, they just contain some fields that otherwise no one ever looks at, so it's a little harsh to reject them. This patch removes most of the special FontDict code, and uses everything from TopDict, *except* the order attribute: it sets that to a list of the relevant keys for the FontDict. The effect of this is that "useless" key/value pairs are ignored, not just upon reading XML, but also upon decompilation and compilation of binary fonts. It improves on the previous XML reading behavior in that it no longer silently ignores key typos in the TTX input. Ideally, we would *output* everything that is actually in the FontDict to TTX, and only ignore the values when compiling, but I didn't find a clean solution for that, so I decided to just fix the issue.
…es to the other issues involved.
…re provided either by an OTF, or a TTX file; It now warns reliably in both those cases.
|
Ugh, getting caught in areas of git-land that I know nothing about. I did |
|
git push -f |
0f23bee to
f713c93
Compare
|
I've disabled force-push on master. Feel free to enable it, do a forced push, and then disable again, as generally it's a bad idea. |
|
It worked anyway, probably because I force-pushed to a non-master branch (the PR branch). |
|
Thanks for dealing with this - I was out for several days. I certainly agree that existing fonts with non-essential FontDict keys should not be rejected. As a background, I made the original change because of complaints from Morisawa and FontWorks about non-essential keys appearing the the CID font FontDicts. |
|
@readroberts, I would love it if you could review my total changes. I think I left all the intentions in tact and just made sure that valid fonts are not rejected. Warnings are issued for redundant keys. |
|
@justvanrossum I would like to tag 3.3.0 with STAT table support. Is this PR ready to be merged? |
|
It is ready, I was hoping for a review from @readroberts, but I think it's good to go. Thanks. |
|
Thanks Just. We can always improve/fix things later. |
This fixes #740.
Commits 3063def and 5b47971 introduced a separate fontDictOperators list for FontDict, only listing those TopDict key/value pairs that are actually used in the FontDict context. It provided a fallback that TTX files containing such "useless" key/value pairs would not be rejected.
However, the code still rejected binary fonts that contained such values, even though it didn't before, and yes, such fonts exist. Also: such fonts are not broken per spec, they just contain some fields that otherwise no one ever looks at, so it's a little harsh to reject them.
This patch removes most of the special FontDict code, and uses everything from TopDict, except the order attribute: it sets that to a list of the relevant keys for the FontDict. The effect of this is that "useless" key/value pairs are ignored, not just upon reading XML, but also upon decompilation and compilation of binary fonts. It improves on the previous XML reading behavior in that it no longer silently ignores key typos in the TTX input.
Ideally, we would output everything that is actually in the FontDict to TTX, and only ignore the values when compiling, but I didn't find a clean solution for that, so I decided to just fix the issue.