Howdy, Stranger!
Categories
- 4.4K All Categories
- 33 Introductions
- 3.4K Typeface Design
- 719 Font Technology
- 995 Technique and Theory
- 542 Type Business
- 417 Type Design Critiques
- 515 Type Design Software
- 29 Punchcutting
- 123 Lettering and Calligraphy
- 73 Technique and Theory
- 50 Lettering Critiques
- 425 Typography
- 271 History of Typography
- 104 Education
- 50 Resources
- 458 Announcements
- 68 Events
- 101 Job Postings
- 142 Type Releases
- 146 Miscellaneous News
- 255 About TypeDrawers
- 51 TypeDrawers Announcements
- 109 Suggestions and Bug Reports
Open sourcing VTT
Rob McKaughan
Posts: 39
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:
But: does anyone out there want this? Would anyone actually make use of it?
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.
But: does anyone out there want this? Would anyone actually make use of it?
Tagged:
3
Comments
What about the whole thing, though? The ui needs some love too
(I have done so for the FontLab TTH compiler already
While working on the opened Font Validator (you have all heard of it. right?
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.
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.
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.
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).
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.
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)
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.
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).
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.
Here's the Wayback Machine's index of all captures of that page.
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.
It appears that we've never published the TSI* table specifications. Obviously, we'll have to change that before open sourcing the compiler.