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

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 https://github.com/microsoft/VisualTrueType/blob/7559fcb2d7d560cae62c195d13e5c92d4f7afabc/src/TTFont.cpp#L1929 which passes in a tag of 1835104368 (maxp) and gets back a zero.

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

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.

This PR adds Markdown formatted documentation for the current docx content. This was a pandoc conversion to GFM with Markdown / HTML manual edits for consistent code blocks across the docx and md documents. There were no content edits.

Mostly these are fixes for compiler warnings; the changes in getopt.h looks large, but actually just for correcting misleading indentations.

There is a bug fix for error reporting on failing to open files - the code keeps a reason, in the GUI probably would be caused a pop-up, but the command-line tool just throws it away; this is now corrected, and failure-to-open reasons are printed on the console.

This is the final part of the open compiler changes, I think.

-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"?

The test case in issue 20 uncovers 3 problems:

• Microsoft compiler treats %s passed to wprintf(), different from everybody else. So we need to special-case Microsoft compiler with one wide-string-format specifier, and everybody else with a different one. (and vice versa for narrow string - but there is only one case, in main()).

• After fixing the truncation, I found a missing null termination problem with the previous work-around for unix systems lacking a wctime() function (and need to call ctime() then convert from narrow to wide).

• and a similar problem with earlier long to int32_t, needs to replace a lot of %li by %i to not implicit convert to 64-bit long.

I only replaced %li in TTEngine.cpp ; the other seems to affect user messages (if error) and not critical.

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

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 :-)

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.

…se-variants

Done with: sed -i -e 's/Illegal/Invalid/g' *.cpp *.h sed -i -e 's/illegal/invalid/g' *.cpp *.h sed -i -e 's/ILLEGAL/INVALID/g' *.cpp *.h sed -i -e 's/legal/valid/g' .cpp .h sed -i -e 's/Illegal/Invalid/g' doc//.html

Fixes https://github.com/microsoft/VisualTrueType/issues/24

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.

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.