The current argument parser in subset.py must strip out spaces in values,
in order to allow specifying comma- or whitespace-separated lists (for
example, cf. [line 2289](https://github.com/behdad/fonttools/blob/master/Lib/fontTools/subset.py#L2289))
Because of that, users cannot correctly specify table tags whose length
is less than 4 by enclosing the space in quotes.
For example, 'SVG ' table will be alwyas dropped even if I pass
`--drop-tables-='SVG '` and `--no-subset-tables+='SVG '`.
As a workaround, this patch removes the spaces from the 'SVG ' and 'cvt '
tags in the constant lists of the Option class, and it only tests that
`tag.strip()` is contained in those list.
Of course, this also means `--drop-tables-='SVG '` is now the same as
`--drop-tables-='SVG' as far as the subsetter is concerned.
Fixes https://github.com/behdad/fonttools/issues/376
Related https://github.com/behdad/fonttools/issues/265
Resolves https://github.com/behdad/fonttools/issues/355
For making sure that `pyftsubset` still works after this change,
I have done the following steps:
* invoked Adobe's `makeotf` tool to build a custom font with a
MultipleSubst lookup. This lookup decomposes two two ligatures,
`c_t` and `f_f_i`, into their respective components.
* invoked the `pyftsubset` tool to produce a subset font with just
the `c_t` ligature;
* checked with `ttx` that the newly produced subset font contains
the requested `c_t` ligature and its components `c` and `t`,
but does not contain not any of `f_f_i`, `f`, or `i`.
Previously, if a subtable's data was shared amongst two different encodings,
the second one being loaded was getting a cmap member assigned while retaining
its data item. If we subset the cmap and then save that subtable, the original
unsubset data will be written out. Fix, but removing data when assigning cmap.
Explains and obviates mystery hack in subsetter.
This reverts commit 72f72d3c3fff3eea38ae41b86a10a78d8460e09d.
This broken subsetting of cmap, as privately reported by Adam to me.
Investigating some more. I think I actually know what's going on.
Followup fix from 13d48da3a91e7ac005f31b0f4dbca01cae7adbd7
When avoiding redoing the same lookup, we should only do that within
each run over all lookups.
Fixes issue where closing glyphs over NotoNastaliq was unreliable and
returning different results (which was caused by items in our frozenset's
being walked over in different orders).
Slows down closing over NotoNastaliq from 5s to 16s. Speedup fixes coming
soon.
modify scripts to work as setuptools 'console_scripts', where the main
function takes no arguments;
add empty identifier "" in 'packages' argument of setup, to install the
standalone sstruct.py and xmlWriter.py for legacy support;
remove py2exe since it is made redundant by setuptools 'console_scripts';
remove custom 'build_ext' command since the eexecOpmodule.c is no longer
present.
The Python style (outside of Google) is four spaces for indentation.
After this change, pylint still has complaints about this file,
but these formatting changes will probably improve the health
metrics of landscape.io. Personally, I couldn't care less about
whitespace, but it is hard to spot actual problems in a sea
of lint warnings.
If a contextual lookup recurses twice on the same index, that index
most be marked chaotic for the second recursion.
Also, when a non-1-to-1 recursion happens, only mark glyph locations
after current to be chaotic, not everything.
I believe this fixes a bug that before we were not inclusive enough.
Now we might have introduced more false positives, but we are at least
correct.
Improves NotoNastaliqDraft closure_glyphs() time from 60s to 50s.
This was originally introduced in 1d4fa13b4. I'm fairly confident
new code is correct.
This seems to both make the font smaller for small subsets, and works
around a bug in our CFF hint stripping logic.
So, if you are passing --no-hinting, do pass --desubroutinize.
