Open sourcing VTT

Rob McKaughan

Is there value and interest in an open-source version of the VTT compiler? 

This would be a command-line compiler that could take a TTF with TSI* tables and compile it down to a hinted TTF (optionally stripping out the TSI* tables). Essentially, that's the same functionality that vttshell.exe provides in VTT 6.3 today. 

It would include:

• The compiler that takes VTT's high-level language, VTTTalk, and produces highly optimized TT instructions (in source-code format).
• The assembler that takes TT instruction source and produces the byte code in in the font.
• The current Microsoft font program and pre-program that support the Res() instructions that adapt automatically to the rendering mode of the rasterizer.

I would guess that this could be useful for automating build processes or integrating into type design tools. This also dovetails with my suggestion after Robothon 2015 that VTTTalk could be adopted as the standard for storing hints in UFOs (with some enhancements to VTTTalk to eliminate glyph ID and point number dependencies). 

But: does anyone out there want this? Would anyone actually make use of it? 

Dave Crossland

I expect that everyone who uses vtt would love this!

What about the whole thing, though? The ui needs some love too

John Hudson

I can see the value in this, Rob. I can imagine, among other things, the potential to script some aspects of workflow that currently rely on the VTT UI, e.g. variable CVTs.

Denis Moyogo Jacquerye

Yes, there is interest. Having an open source version would be more than great.

The UI has its issues (which would be easier to fix if open sourced) but I guess some crucial parts cannot be open sourced. If there was a way to plug in freetype instead that would be great as well.

Dave Crossland

Maybe with this being open we can just jettison the UI and make a be better one that uses freetype and harfbuzz....

Paul van der Laan

Yes. An open source VTT compiler would be of great help for the IBM Plex project.

And it would (hopefully) increase the possibility of a VTT scripting API, which is still an advantage that FontLab’s TTH has.

Lucas de Groot

Yes!

Jens Kutilek

I have had it in the back of my mind to reimplement the VTT compiler in Python for a long time. Open-sourcing the original would save a lot of time on such a project

(I have done so for the FontLab TTH compiler already

Hin-Tak Leung

I'll leave the lobbying and should/shouldn't part of the discussion to somebody else, and just comment on the technical side of the possibility of opening up VTT.

While working on the opened Font Validator (you have all heard of it. right? ) , I did a bit of poking around VTT also, see as it is also Microsoft and etc.

Unlike FontVal (which is a hybrid C/c++ and C# / dotnet application), VTT depends on the Microsoft visual basic runtime, which implies that a substantial part of it is written in visual basic 6 . That's the pre-millennium variant of visual basic. Around the millennium Microsoft released a dotnet variant, visual basic 7.

I don't know how much of VTT core is C/c++ and how much of it is visual basic 6. If the latter is important, you will have to migrate to VB7 first, as there is no open-source tool kit for VB6.

Mono for a long time ships an implementation of a VB7 compiler; also with Mono 5 (and Xamarin being acquired by Microsoft), Microsoft donated and opened their compiler stuff to mono 5 - it is in the same vein as FontVal: the initial opened code have bits removed and hence a bit broken.

With mono 5.x reaching 5.16/5.18 after almost 1.5 years, mono 5 seems to be usable . 

So if VTT is to be opened, you probably want to keep an eye out for mono and especially mono 5. FontVal development has been on the last of mono 4.x because the earlier mono 5.x were buggy... but I have recently needed to look at the late 5.x's.

Rob McKaughan

Hin-Tak Leung said:

I don't know how much of VTT core is C/c++ and how much of it is visual basic 6. If the latter is important, you will have to migrate to VB7 first, as there is no open-source tool kit for VB6.

VTT is 100% C++. You may be thinking of VOLT, which is written in VB.

Rob McKaughan

Regarding open-sourcing the entire app (per Dave's suggestion):

The biggest issue blocking this right now is a contractual one: VTT includes components that are under license to Microsoft, and thus we don't have rights to open-source. One could do some work to port VTT to freetype. This is a bigger effort than it might seem: VTT reaches down deep into the rasterizer to do what it needs to do (it has it's own copy of DirectWrite for that purpose). So, we'd have to figure out if it's even possible to do with freetype (i.e. can an app reach down to that level in freetype?), and if so, do a bunch of work to refactor, etc. Of course, we'd want there to also be a module available (in binary form, due to that pesky license) that gives you a DWrite rendition so you can be certain how a font will render on Windows. All this is solvable, but will be a lot more effort than it would otherwise seem. 

Also, VTT's got quite a legacy: VTT used to run on macos 7. Then it was ported to Windows. A UI abstraction layer was created to run on Windows 95 and macos 7, but was also particular to the capabilities of GUIs in the early 90s. That rickety, ancient UI layer is still there and causes any UI work to take far longer than I estimate. It continues because, the benefit in rewriting it all has never been worth the huge investment in time it would take. Given that, I wonder if the UI side of the app, with all its legacy, is worth something to others, thus worth open-sourcing in the first place. 

I think that open-sourcing the back-end and guts of VTT (which are much cleaner) and having a good API to build on, might be time better spent. Especially if there are enthusiastic people who want to do a modern, cross-platform UI... Or, perhaps, integrate into existing tools.

Rob McKaughan

Speaking of which: I would be curious what the tool folks think. Adam? Tom? Georg? Cosimo? Others?

Rob McKaughan

I don't know if people noticed it, but the latest version of VTT, 6.30, includes a commandline compiler (vttshell.exe). So, for those wanting to do scripting now, if you don't mind doing it on Windows, you've got some functionality right now. 

Hin-Tak Leung

Apologies - after I wrote what I wrote, I remember that VTT is available in both 32-bit and 64-bit, while VB6 runtime, if my impression serves, is not available in 64-bit, so I must be confused about something; I meant to go back to fact-check .

The original rasterization backend of Font Validator seems to share some heritage with win32k.sys, the part of which in turn seems to come from / share some heritage with Apple's system 7 . If you are talking about that particular part (the truetype rasterization stuff Microsoft licensed from Apple and greatly enhanced afterwards in the next two decades, I believe), it took about 2 years on-and-off to retrofit / port to FreeType, although part of the difficulty is that FontVal is part C/C++ and part C#.

So I think it is possible - though the effort it will take are measured in a number of half-year/years.

Belleve Invis

@Rob McKaughan

Maybe you can start with publishing the docs describing VTT's tables (TSI*) languages (ASM and Talk) first, since implementing a compiler using them is not that difficult.
I am really wanting that we could have some more flexibility on handling indexes (point, CVT, function, etc).

Nikolaus Waxweiler

Getting the compiler code would be really useful, we could wrap it in a Python module for easy scripting access.

Hin-Tak Leung

I suspect (re-)implementing the compiler is simultaneously easy and hard, and have the code of VTT released without the rasterizer is perhaps both useful and not so useful.

People wants the compiler code for easy modification and regeneration of fonts. However, I think part of VTT 's usefulness or even most of its value, is visually-assisted hinting from scratch.

That means it has a built-in system of validating/checking/interpreting the correctness of hinting instructions.

If that's removed, then the compiler is likely to be doing garbage-in-garbage-out compilation. A garbage-in-garbage-out compiler is easy to (re-)write, but not really useful.

So I think if/when VTT is opened, it will need months/years to make it as useful as the non-opened one.

Hin-Tak Leung

Went back to poking around VOLT and VTT. Yes, you are right, I was confused by VOLT. VOLT is the one depending on VB6 runtime.

Both the 32-bit and 64-bit VTT, and both the GUI and command line, run well enough in wine (both 32-bit /  wow64 and 64-bit wine). So running it with an Intel/x64 CPU on most OSes is not an issue.

I think as a start Microsoft needs to modularize VTT and sort out which parts are openable and which parts not.

When FontVal was opened, it was already in about 10 dll's. Sources for about 4 of them were not released : the rasterizer/font scaler (called "truetype.dll"/"fscaler.dll"), GUI elements (Win32APIs.dll, file chooser dialog and such), digital signature verification (WinVerifyTrustAPI.dll) and the bridge to IE for report viewing (ieframe.dll and Interop.ShDocVw.dll).

In time they were all replaced by dropped in replacements with open-source bits, with a period of transition of loading the old MS dlls for compatibility testing, etc. This happened over about 2 years.

Perhaps VTT can start by refactoring into modules/dls, by their likelihood/license of being opened, and cross-platform usefulness. At the moment, they are monolithic binaries.

(FontVal on windows continues to be able to load some of the older proprietary dlls, although that's a build configuration that only I use these days, for comparison testing)

Jens Kutilek

Belleve Invis said:

@Rob McKaughan

Maybe you can start with publishing the docs describing VTT's tables (TSI*) languages (ASM and Talk) first, since implementing a compiler using them is not that difficult.

I believe these used to be available, if a bit hard to find. This page doesn't seem to exist anymore: https://www.microsoft.com/typography/tools/vttusers.aspx

I am really wanting that we could have some more flexibility on handling indexes (point, CVT, function, etc).

Yes, symbolic names would be nice.

Btw. there is an open source compiler for TT assembly (htic), just the translation from VTT Talk to assembly is proprietary.

Rob McKaughan

Jens Kutilek said:

Belleve Invis said:

@Rob McKaughan

Maybe you can start with publishing the docs describing VTT's tables (TSI*) languages (ASM and Talk) first, since implementing a compiler using them is not that difficult.

I believe these used to be available, if a bit hard to find. This page doesn't seem to exist anymore: https://www.microsoft.com/typography/tools/vttusers.aspx

Hmm... Those must've gotten lost with the website migration. Let me look around.

Jens Kutilek said:

Btw. there is an open source compiler for TT assembly (htic), just the translation from VTT Talk to assembly is proprietary.

I've not looked at htic, but I do know that VTT does a bunch of optimization, as well as leverage a bunch of cool functionality we have in our font program (like the Res() instructions).

Theunis de Jong

Rob McKaughan said:

Jens Kutilek said:

Belleve Invis said:

@Rob McKaughan

Maybe you can start with publishing the docs describing VTT's tables (TSI*) languages (ASM and Talk) first, since implementing a compiler using them is not that difficult.

I believe these used to be available, if a bit hard to find. This page doesn't seem to exist anymore: https://www.microsoft.com/typography/tools/vttusers.aspx

Hmm... Those must've gotten lost with the website migration. Let me look around.

Is the copy on archive.org complete?

Dave Crossland

Rob McKaughan said:

Regarding open-sourcing the entire app (per Dave's suggestion):

The biggest issue blocking this right now is a contractual one: VTT includes components that are under license to Microsoft, and thus we don't have rights to open-source.

Surely if msft is interested in it, those licensors may be at least willing to explain what incentives would be needed for them to be happy with making it happen.

In the past, when I asked msft people about this, I was told flatly no, what am I crazy, and that was the end of it. Times have changed. 

So maybe the licensors aren't interested in collaboration in any circumstances. That's fine, reasonable people can disagree. 

But maybe it can happen. I don't think it's good to dismissed the possibility out of hand.

Alex Hall

Here's The Wayback Machine's newest snapshot of that page (supposedly describing the VTT tables, though I haven't dug around further to verify that).

Here's the Wayback Machine's index of all captures of that page.

Hin-Tak Leung

With all these discussion about docs and missing docs, I had a quick skim through, and saw that it was explicitly stated in the 4.x release note that VTT include the "... secure rasterizer 1.7 as in windows 2000 ..." .

This was probably derived from code licensed from Apple. In any case, it is unlikely to be opened, as the similar part in FontVal was not opened. Still trying to get a more up-to-date (2009) binary module than the public 2003 one though.

Assuming VTT may evolve into a version where it exists as a separate binary module, in preparation for replacing/dual-backend with FreeType.

Also the copyright notice states that the Window GUI port (from apple system 7, presumably) was done by a 3rd party company. It may be difficult to contact the correct legal party after almost 30 years, even if it is deemed desirable to relicense.

Rob McKaughan

Alex Hall said:

Here's The Wayback Machine's newest snapshot of that page (supposedly describing the VTT tables, though I haven't dug around further to verify that).

Here's the Wayback Machine's index of all captures of that page.

I believe that's got the most recent changes before they migrated the site.

It appears that we've never published the TSI* table specifications. Obviously, we'll have to change that before open sourcing the compiler. 

Saga Söderback

Well well well, after all these years, a dream may come true.

When I was at Ascender, we definitely talked to MS about doing this (or something like it) a lot. I'm very glad to hear it may happen. Undoubtedly many wonderful things could be developed with an open source version of VTT. Dare I say that this could be a renaissance for hinting?

Dave Crossland

Hinting only matters for Windows users...

Jens Kutilek

… which, as we know, are just a tiny minority.

Thomas Phinney

Does most Android text get autohinted on the fly these days?

Georg Seifert

As far as I know, Freetype is respecting existing TT hints but will auto hint fonts without hints. Ttfautohint is just baking the freetype hinting into instructions so that people on windows get the same improvements. So if you run ttfautohint with default settings on font that are only used on mobile devices, you only waist space. 

Khaled Hosny

FreeType has different rendering modes, some of them ignore font hinting completely (with or without auto-hinting) and I think that is what Android is using.