microsoft / visualtruetype

Microsoft Visual TrueType(VTT) command line compile tool and Python interface.

Project

Microsoft Visual TrueType(VTT) is a professional-level tool for graphically instructing TrueType and OpenType fonts. For details on the tool visit https://docs.microsoft.com/en-us/typography/tools/vtt/.

Visual TrueType compiles binary from source formats included in the fonts that are instructed with Visual TrueType.

This repo contains the source for the compilers of Visual TrueType. The compilers can compile the high level VTT Talk source to a lower level assembler source and then can assemble that source to corresponding binaries. Since VTT can also generate variation 'cvar' data for variable fonts, the compilers can also produce 'cvar' data from a source format. File management functions are included to prepare a font for production and to strip source formats for a final 'ship' font binary.

The source in this repo can be compiled and used in two different ways.

First is VTTCompile which is a standalone tool can VTTCompile that runs on the command line. The interface for VTTCompile is similar to VTTShell which is included in Visual TrueType download package.

Second is VTTCompilePy which is Cython based Python extension that exports interfaces enabling a Python program to compile and assemble TrueType data. This extension also provides a command line interface to the Python interface. VTTCompilePy is available on PyPi, please visit https://pypi.org/project/vttcompilepy.

The source code in the repo is mostly a subset of the source code of Visual TrueType as needed to produce VTTCompile. However not all of the source code included in the repo is necessary to produce VTTCompile but we optimized for including as complete source files as possible to make future maintenance easier.

For documentation of the Visual TrueType source formats visit https://docs.microsoft.com/en-us/typography/tools/vtt/tsi-tables.

Building

In the "vttcompile" folder, there is a Visual Studio Solution for Microsoft Visual Studio users, and an Xcode Project For Apple Xcode users.

For unix users (including Linux and Apple command-line), cd src && make should work. You can also cross-compile for 32-bit windows with cd src && make CXX=i686-w64-mingw32-c++, for 64-bit windows with cd src && make CXX=x86_64-w64-mingw32-c++; and use clang, enabling all the recommended warnings with cd src && make CXX=clang++ CXXFLAGS=-Wall. Build as 32-bit on 64-bit systems with cd src && make CXXFLAGS=-m32. You may need to do cd src && make CXXFLAGS="-std=c++14" to explicitly request support for the 2014 ISO C++ standard.

In the "vttcompilepy" folder is the Cython source for the Python extension but the build is done through the setup.py file in the main folder.

Setup a Python environment including dependencies in requirements-dev.txt.

To build the extension on local machine use "Python setup.py build". To install the built extension into current Python environment use "Python setup.py install". To create a distribution package for current system use "Python setup.py bdist_wheel".

The workflow Python Extension uses ciBuildWheel to build the extension across multiple platforms and optionally upload result to PyPi.

The minimum compiler requirement is support for the 2014 ISO C++ standard plus amendments.

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Trademarks

This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.

visualtruetype's Issues

Please go farther—open source the GUI.

My mingw-port branch - using mingw gcc to build, instead of visual studio.

The earlier changes are just building on case-sensitive file systems, the rest shouldn't break visual studio build either.

https://github.com/HinTak/VisualTrueType/tree/mingw-port

on the way to making it work on linux, I thought it is easier going via mingw first.

Add memory interface example to pypi page.

VTT legacy compile option not exposed through command line interface

Legacy compile option for 'old' fonts compiled with old versions of VTT is not available via command line option.

linux port now on my opencompiler-port branch (the default)

It probably would work with mac too. native compile just do "cd src; make". For cross-compiling for windows, make CXX=i686-w64-mingw32-c++ (32-bit) or make CXX=x86_64-w64-mingw32-c++ (64-bit).

https://github.com/HinTak/VisualTrueType

vttcompile can't find maxp table

Trying to run vttcompile -a in.ttf out.ttf where in.tff is in.zip (compiled from https://github.com/daltonmaag/ubuntu/). It seems to fail getting at the maxp table. I'm looking at

VisualTrueType/src/TTFont.cpp

Line 1929 in 7559fcb

long offs = this->GetTableOffset(tag);

which passes in a tag of 1835104368 (maxp) and gets back a zero.

Compiled commit 7559fcb on Fedora 34 x86_64, gcc version 11.2.1 20210728 (Red Hat 11.2.1-1)

Can‘t install with PIP on M1 MacBook

Hi! It seems that installation process fails when I try to install on my Macbook M1 MacOs Monterrey.

DEPRECATION: Configuring installation scheme with distutils config files is deprecated and will no longer work in the near future. If you are using a Homebrew or Linuxbrew Python, please see discussion at https://github.com/Homebrew/homebrew-core/issues/76621
Requirement already satisfied: pip in /opt/homebrew/lib/python3.9/site-packages (22.1.2)
Requirement already satisfied: install in /opt/homebrew/lib/python3.9/site-packages (1.3.5)
Collecting vttcompilepy
  Using cached vttcompilepy-0.0.1.4.zip (217 kB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  error: subprocess-exited-with-error

  × Getting requirements to build wheel did not run successfully.
  │ exit code: 1
  ╰─> [16 lines of output]
      Traceback (most recent call last):
        File "/opt/homebrew/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 363, in <module>
          main()
        File "/opt/homebrew/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 345, in main
          json_out['return_val'] = hook(**hook_input['kwargs'])
        File "/opt/homebrew/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 130, in get_requires_for_build_wheel
          return hook(config_settings)
        File "/opt/homebrew/Cellar/[email protected]/3.9.13_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/setuptools/build_meta.py", line 177, in get_requires_for_build_wheel
          return self._get_build_requires(
        File "/opt/homebrew/Cellar/[email protected]/3.9.13_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/setuptools/build_meta.py", line 159, in _get_build_requires
          self.run_setup()
        File "/opt/homebrew/Cellar/[email protected]/3.9.13_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/setuptools/build_meta.py", line 174, in run_setup
          exec(compile(code, __file__, 'exec'), locals())
        File "setup.py", line 12, in <module>
          with open(os.path.join(here, 'pypi.md'), encoding='utf-8') as f:
      FileNotFoundError: [Errno 2] No such file or directory: '/private/var/folders/b_/wzl4jsl97mz4mvk2bj0363x40000gn/T/pip-install-94e_fpdi/vttcompilepy_e11fbc250c4245a481ad1e46771024ab/pypi.md'
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× Getting requirements to build wheel did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

[notice] A new release of pip available: 22.1.2 -> 22.2.1
[notice] To update, run: python3.9 -m pip install --upgrade pip

include test files and tests in the bundle.

I have included all the non-executable files (the release notes, the chm files also, plus the sample ttf and templates) in my opencompiler-port, but it would be better if Microsoft staff do it officially.

Found one bug while testing; the fix is in the pull.

Mac terminal port

Once Windows dependency is removed, add a Mac XCode terminal project.

./vttcompile -a fails on the vttdemo.ttf on linux

Just trying vttcompile on the vttdemo.tff shipped with VTT. -s -b and -c completes with success, but -a fails with:

$ ./vttcompile -a ../Sample/vttdemo.ttf /tmp/t.ttf

Microsoft Visual TrueType Command Line Interface Version 6.35 
Copyright (C) Microsoft Corporation. Licensed under the MIT License.
....................
...............
Glyf Pgm, glyph 341 (Unicode 0xb8), line 10: NN

Can not complete compile operation! 

This is after #17 and fixing #19 . Given #19 (it was surprising to see vttcompile failing on the shipped ttf with the maxp error, and that turns out to be a genuine bug), I'd assume the vtt shipped vttdemo.ttf should be valid and can be used as input to vttcompile for all operations. If it isn't, it should - that's still a bug, but a bug in the font, so the issue should still be reported.

Code formatting

The code format is a bit messy. I could make a clang-format file that is close to what most of the code looks like?

Test infrastructure needed

Build a Python test infrastructure to test built VTTCompile output against known good state.

Include open sourced Selawik font and use fonttools TTX to dump relevant tables then use built VTTCompile to rebuild all and dump relevant tables to compare with original.

Automated Build

Automate build of VTTCompile using MSBuild.

Composite guard feature not exposed through command line interface

VTT has a feature where with a variable font if the source for a composite glyph changes the composite definition binary an error will occur because it's potentially destructive to change the definition of a composite glyph in a variable font. Expose this feature to the command line interface.

Clean up version number handling for Python extension

Currently version number is set in setup.py which is used when extension is built and vttcompilepy/_version.py that is used in response to --version argument. Combine and/or use use_scm_version to reconcile version number.

File.cpp includes 'windows.h'

File.cpp uses Windows functions so is not platform independent.

Rewrite to remove the 'windows.h' dependency.

illegal → invalid

A minor thing that always bothers me in software mostly coming from the US: It's the constant mis-use of 'illegal' where it should be 'invalid' instead.

I thus ask that you do such a replacement :-)

different outcomes between vttcompile and vttshell, on vttdemo.ttf

-g0 -r100:

@@ -471,7 +471,7 @@
   </OS_2>
 
   <hmtx>
-    <mtx name=".notdef" width="1322" lsb="0"/>
+    <mtx name=".notdef" width="197" lsb="0"/>
     <mtx name="A" width="1321" lsb="24"/>
     <mtx name="AE" width="1762" lsb="24"/>
     <mtx name="Aacute" width="1321" lsb="24"/>
@@ -747,7 +747,7 @@
     <mtx name="seven" width="1104" lsb="98"/>
     <mtx name="six" width="1104" lsb="111"/>
     <mtx name="slash" width="798" lsb="1"/>
-    <mtx name="space" width="561" lsb="0"/>
+    <mtx name="space" width="197" lsb="0"/>
     <mtx name="sterling" width="1104" lsb="120"/>
     <mtx name="t" width="694" lsb="43"/>
     <mtx name="tbar" width="694" lsb="43"/>

-g200 -r300:

@@ -767,7 +767,7 @@
     <mtx name="uhungarumlaut" width="1159" lsb="144"/>
     <mtx name="umacron" width="1159" lsb="144"/>
     <mtx name="underscore" width="850" lsb="50"/>
-    <mtx name="uni000D" width="199" lsb="0"/>
+    <mtx name="uni000D" width="156" lsb="0"/>
     <mtx name="uni00AD" width="819" lsb="144"/>
     <mtx name="uni00B2" width="995" lsb="0"/>
     <mtx name="uni00B3" width="995" lsb="0"/>

-b, -c, -s, and also no arguments:

@@ -471,7 +471,7 @@
   </OS_2>
 
   <hmtx>
-    <mtx name=".notdef" width="1322" lsb="0"/>
+    <mtx name=".notdef" width="197" lsb="0"/>
     <mtx name="A" width="1321" lsb="24"/>
     <mtx name="AE" width="1762" lsb="24"/>
     <mtx name="Aacute" width="1321" lsb="24"/>

So the summary is that -a gives identical results (other than checksums and dates), most other switches (including no passing any) disgrees by the width of .notdef, and with -g... -r..., not only .notdef, but also space and uni000D (carriage return). @paullinnerud : this looks like another issue along the line of "rasterizer removal"?