Apparently on some BSD systems man pages go to /usr/man instead of /usr/share/man.
It's too complicated to keep track of all the nuances of Linux distros so package maintainers can simply override the default via a $FONTTOOLS_MANPATH env variable
Fixes#84
it's better to group man pages in a separate sub-folder in case we add alternative doc formats in the future, or if we add additional man pages.
This also allows to read man pages directly from the source tree, e.g. via `export MANPATH=Doc/man`, or `man -M Doc/man ttx`
It's not a good thing that we build different wheel packages (with/without data_files) according to the platform we build them with.
After all, these wheels are meant to be "universal".
Even when manpages can't be used on a target platform (e.g. Windows), their mere presence should not do any harm; they are simply copied to a 'share/man' folder relative to the python prefix. On Unix systems (Linux, Homebrew, etc.) this is usually `/usr` or `/usr/local`, so `man ttx` just works (TM).
Note that other popular python tools like IPython or Sympy also install manpages the same way we do here with ttx, and they do that unconditionally for all platforms.
As regards issue #796, whereby attempting to `sudo pip install fonttools` fails because the manpage file is copied to a SIP-protected location on OSX El Capitan and above:
Users who still wish to install fonttools globally with sudo (and are not scared after googling 'why sudo pip is bad'), can still use the '--install-data' option of setup.py install to modify the data_files base installation directory.
If you install with pip (recommended over `python setup.py install`), you can use --install-option to pass through installation options to setup.py (which is run by pip when installing from source).
For example, to install man pages to /usr/local/share/man/man1/*.1 you could pass "/usr/local" as the base directory for --install-data, like so:
sudo -H /usr/bin/python -m pip install --install-option="--install-data=/usr/local" fonttools
The convention is that sys.exit(...) is called only if a module is run as a script,
and that main() entry points use return statements to report exit codes: 0 (or None)
for successful execution, or any non-zero integer for errors.
E.g. see the console scripts generated when installing with pip.
If a module is run as script, as in `python module.py` or when using
`runpy.run_module()`, then __name__ == "__main__".
So when we instantiate modules' loggers with `logging.getLogger(__name__)`,
those loggers' name may become "__main__" when run as scripts, and hence
fall outside of the "fontTools" logging namespace.
fontTools.configureLogger() by default only configures the "fontTools"
library loggers, anything outside of it (e.g. logger called "__main__")
is not attached a handler.
So here I name loggers explicitly instead of relying on __name__, but
only for modules which can be run as "__main__".
Fixes#801
Fixes https://github.com/fonttools/fonttools/issues/797
Although for the XML->binary case, that bug was already fixed
on master because of the XML populate-default changes.
This adds extra protection!
OpenType TupleVariations can be used in two places:
* In the `gvar` table, they modify glyph contour points by shifting
them towards a point in 2D space.
* In the `cvar` table, they modify constant values.
Before this change, we only had code to handle the `gvar` version
which shifts points around by delta values.
After this change, the XML parsing and generation routines of
TupleVariations can handle deltas that modify constant values in the
CVT table, as used in `cvar`.
An upcoming change will add support for the binary encoding of
TupleVariations as needed for `cvar`.
In the OpenType 1.8 specification, this is called TupleVariation
so let's be consistent with the spec. (The initial implementation
in fonttools pre-dates OpenType 1.8).
