While I like to see this happening, I don't see it happening any time soon. Considering how much grief it was with discussions involved with the rasterizer backend of font validator (which is overlapping in scope to this discussion, in terms of both concerning specifically the Microsoft font rasterizer/renderer, and generally font technology Microsoft unlikely to release in source form) for the last 7 years. What I think Microsoft could/should consider, is to modular the proprietary part, and release it in binary pluggable form, as a reference, to enable a drop-in compatible open replacement with side-by-side comparison to happen.

Cc @davelab6 .

a 🦝 can dream :)

But seriously, while I recognize the utility of having the compiler up on GitHub, there's not too much I can do with it without the ability to write VTT instructions. Which requires MS's GUI VTT.

We would like to include all of VTT in open source including the GUI. The problem as HinTak suggests is issues concerning the rasterizer. Removing the rasterizer and providing it in library/binary form has merit and is a possibility worth considering.
Thanks

Could just release the rasterizer too ;-)

I mean, does Microsoft really think that DPI's are going to remain low in most consumer tech? And if not, is ClearType gaining or losing relevance? And if it's losing relevance, then what's the harm?

But again, more dreams.

It is not as simple as that. Firstly there are cleartype patents, although most of them expired(?), the actual know-how still consider a business advantage by some (especially and understandably by those Microsoft folks who were involved in developing them); there is also the vulnerability of giving bad guys ammunitions on how to attack the graphic sub-system. So there are advantages of not release the code, and perceptible risks of releasing it.

Beyond that, having thought about it for a good part of almost 7 years, let me share my understanding of it (and I welcome comments / corrections from Microsoft folks): the rasterizer used in the font tools are special enhancement variants of the OS's. For obvious reason they needs to be similar, and yet bundled and also specialized / adapted for the needs of thefont tools as opposite to routine font-rendering. For routine font rendering, you want to do it fast but quiet and doing "reasonable best effort recovery on broken font". For font tools, you want it thorough and verbose. In the case of rasterizer for font validator, it is the addition of detailed diagnostics (diagnostics slows down rendering so obviously you don't want this in OS usage); in the case of rasterizer for VTT, you want the capability of stopping / starting rendering and tracing mid-character (there is no reason to want half-drawn characters in the case of OS usage, but quite reasonable for a font editing GUI). So those are the additional diffs, versus arguing for releasing the rasterer/renderer.

I have somewhat given up on seeing the code itself, but seeing binary components / dlls for them is not a bad outcome. With that, there is the practical requirement of Microsoft devoting some man power to modularize components that way, to separate the parts which are clearly happy to release and those which are not. That's practicality - a paid Microsoft staffer working on a task merely to please the open community (without obvious direct financial reward to the company).

Cc @davelab6

Of all the things I'm known for, practicality really doesn't rank high. So I definitely won't "[give] up on seeing the code itself", and the addition of binary blobs to the font compilation toolchain is a red line for me. I would never release a font that requires binary blobs to build, or that was developed with closed source GUI's.

And, yes, all the notable ClearType patents are expired.

So, we have this compiler, and the freeware VTT. I could probably—through analysis of the freeware VTT, and FontForge's TT debugger, and other sources of knowledge / truth about expected I/O, come up with some kind of FOSS VTT. Just, Microsoft isn't typically known for this kind of thing anymore, burdening the community and making it rewrite code it has no practical reason at all not to release.

Last year I had some good discussions with some WineHQ developers about possibly funding some of their work to make the freeware VTT run better in Wine. Of course, if it ran better, I or someone else could also reverse engineer it better.

How open does MS want OpenType to be? Clearly with the waning relevance of low DPI displays, they could do the right thing and just release it, which would win them good will. Is there really that much to be made with their patents/licensing their rasterizer to embedded low DPI displays? Such idea seems absurd to me, that that's a legitimate revenue stream for them.

Or they could continue being intransigent and some day someone like me will get so fed up—and want to work on a font meant for small display at low DPI—that they do the reverse engineering and all of this debate will become moot. Indeed, their intransigence helped bring about HarfBuzz, why shouldn't it continue to "inspire" other developers?

This is a half measure, and I personally won't accept another half measure that burdens us with undebuggable binary blobs to "fix" it.

Security concerns in ClearType didn't seem to affect other projects they released. Patch Tuesday will always be a thing, are we saying we prefer to be ignorant about ClearType 0-days? Perhaps intelligence agencies would prefer that, seeing as they trade in such, but I wouldn't.

Hmm, I see another fanatics. I'll just paraphrase for its absurdity of approach, that of undermining others' value in the hope of cooperation:

"How open does MS want windows 11 to be? Clearly with the waning relevance of windows 11, they could do the right thing and just release it, which would win them good will".

The rasterizer code is part of the OS, although it is bundled/varied in two different forms, with two font tools.

Cc @davelab6

The font rasterizer is not part of most OS, and if it's part of the Win32 kernel, that's a design flaw. Your analogy is weak, as Windows' relevance is not at all declining.

But I won't deny being a FOSS “fanatic”. I'm ideologically opposed to proprietary software in the font development toolchain, with a particular focus on removing it from the compilation procedure of fonts described as being free or open source. I won't pretend my position is something it isn't, and I don't view that label as being at all negative.

Good news Microsoft, you can win $7,000! 😉

(And good news for everyone else, as they can work on this problem and be compensated.)

https://mfek.org/foundation/grant/2022/04/23/visual-truetype-rewrite.html

Whereas, OpenType fonts are the main type of font used in computing today;

Whereas, despite the increasing acceptance of high DPI screens, such screens have not totally overtaken the market as was once predicted;

Whereas, even high DPI screens still require hinting for best display;

Whereas, TrueType hinting remains the best way to hint OpenType fonts in the sense that it gives the most control to the font developer;

Whereas, Microsoft developed in the 1990’s a programming language known as VTTTalk;

Whereas, VTTTalk instructions are written as UTF-8 into the OpenType font table marked TSI3;

Whereas, Microsoft has open sourced the compiler which converts VTTTalk into TrueType instructions;

Whereas, despite this act, however generous it may be on the surface, Microsoft refuses to provide to the community a way of generating VTTTalk instructions (the VTT GUI);

Whereas, the Modular Font Editor K Foundation, Inc., opposes in principle the necessity of proprietary software to create fonts in open file formats,

Then, therefore, The Modular Font Editor K Foundation, Inc. opens for bids from the public the following signed grant proposal dated this 22nd of April, 2022, entitled “Visual TrueType GUI Rewrite” and with the reference code MFEK Foundation Grant № 6, Series of 2022.

[…]

Signed,
Fredrick R. Brennan
Chairman of the Board
on behalf of the MFEK Foundation, Inc.

As far as see, the font rasterizer code is built as a static library, then seperately linked into the win32 kernel, Font Validator, and Visual TrueType. @paullinnerud can correct me if I am wrong.

While I am glad you managed to raise $7000 US for the GUI effort; from past experience, it took about 3 years on-and-off to rewrite the Font Validator's usage of the Microsoft rasteriser backend into FreeType, and I would say the effort is worth about $40,000 US (cc @davelab6 ) and still considered somewhat incomplete, although it is an improvement against the original, being now cross-platform. So I reckon, even if Microsoft @paullinnerud are willing to co-operate and release Visual TrueType GUI code minus the font rasterizer library linkage, it would take a somewhat larger effort than Font Validator's, to re-make it functionally complete with open-components. This is based on VIsual TrueType having a more complicated and interactive GUI than FontVal. Two months and $7000 is a gross underestimate. Of course your aim (compared to the full functionality of Visual TrueType GUI) might be a lot lower.

In the very long term, I would like the Microsoft folks to consider release the Font Validator's backend as a binary backend. To that end, there is https://github.com/HinTak/fscaler/ - this is the FontVal<->MS font rasterizer interface as it was at the beginning (and been changed to fit FreeType more, since, in the last 7 years). I hope to convert the current FontVal FreeType-based code back to using some wine bits, and allowing Microsoft to ship a binary backend if they are willing. While FreeType is good, unfortunately font designers/ etc still want exact MS font rasterizer behavior, and in the end of the day, FreeType is not MS/Apple's fscaler library. @paullinnerud @davelab6

BTW, VTT Talk was called Royal, or RoyalT(?) I think, and was licensed to Microsoft by Apple, I believe. It isn't an entirely Microsoft-original creation. Again, @paullinnerud can correct me.

And BBTW, besides Microsoft's win32k.sys, FontVal, Visual TrueType, some Apple font tools in the past (and maybe some current ones), variant of the same font library was licensed to Adobe and linked into some Adobe font related tools / software too.

@paullinnerud Have you tried at least building the rasterizer as a dll, and having VTT depending on that dll ? I have been trying to recreate the older interface used by Font Validator when it was still using the MS rasterizer - these are the routines https://github.com/HinTak/fscaler/blob/master/fscaler.def actually used by FontVal. I am 100% that 9 routines can be (partially) emulated by FreeType, because it is already done :-(. In Font Validator, there used to be a mixed-mode assembly which sits between the C#-based GUI and the rasterizer. The mixed-mode assembly + rasterizer was eventually (re-)implemented with P/Invoke and FreeType, partly because P/Invoke is more cross-platform, partly because I never had access to the rasterizer dll itself alone, even in binary form. Perhaps I don't need to go into too much details on this with you, since you are the author AFAIK of a large part of what constitutes that mixed-mode assembly!

@ctrlcctrlv substantial part of the rasterizer, and the earliest VTT itself perhaps, I think, were Apple-licensed tech, dated back to Apple's system 7 era. Dynamic libraries just weren't "a thing" on System 7. Quite interesting enough, Apple had an official accompanying font editor, RoyalT, I think it is called, probably a very distant ancestor to VTT. The Apple rasterizer was designed from day 1 to cater for being used by a font editor in mind, and tight coupling with it too, and without consideration of it ever as a separate/standalone dynamic library, since it was before dynamic libraries of any form and description was popular, and on a platform (System 7) which didn't(?) support that kind of usage. Font Validator - when it was under MS - uses the editor-related/centric functionality in the rasterizer, so if the rasterizer is ever available as a standalone dll, could be used as is by FontVal too (or eventually).

cc @davelab6

Wait is that all we need? Those routines? That's all?

Sorry, I understand now.

Maybe @paullinnerud could be so kind as to share C ABI definition of every fscaler.dll function called by the GUI? If I knew the API I could probably re-implement it in FreeType easily.

The apple/MS rasterizer has less than two dozen public routines, so that 10 or so listed is about 1/2 of it. FreeType has about 210+, the last time I counted. Very different beasts.

Edit: "public"

@HinTak I understand that you're also interested in MS's validator (I'm not, but maybe I can be convinced in its modern value?), but the unreleased VTT GUI might be calling private routines. I wonder if MS would let me sign an NDA to see.

I am 100% sure that private routines are not needed / essential to VTT GUI. There are a few routines in the current public command-line version of vtt code which are split out that way. Already done.

It took 3 years of on-off work to get FreeType to support (partially) emulating those 10 or so routines, equivalently. I would say it was 6 months of full-time work. Vtt is harder. Already said above, but I could be proved wrong :-).

I checked the dates - FreeType 2 was released in 2000. Two projects I know, Ghostscript and TexLive, continued to bundle a static/private copy of FreeType 1 until the 201x, for another decade (in the former case, heavily customized, until ghostscript 9; in the latter case, the texlive people maintained a mirror of the official repo of FreeType 1, I think, and continued to contribute to FreeType 1 development; I was CC'ed on it towards the removal). The MS/Apple rasterizer AFAIK is always used like FreeType 1, and have some limitations regarding its suitability as a dll. It hasn't made the freetype v1 -> v2 transition regarding separating public & private data structures. It was designed with an accompanying font editor in mind from day one in 198x, and FreeType 1 or 2 were not. So to support VTT, probably will mean FreeType v3.

That said, I am also interested in seeing the incomplete VTT gui code, minus bits that I shouldn't see.

Cc @davelab6

@HinTak can we schedule a call? I think we have more common ground than you think but due to disability don't want to type so much. It'd be over Jitsi Meet. Email me if that's fine. I can even do tonight EST.