This week Aaron Bell published a liberated Microsoft Font Validator on Github under the MIT libre license:
Buggy fonts benefit no one and having the Microsoft Font Validator available for all foundries and type designers to contribute to keeping updated is great news
I'd like to congratulate Aaron and especially Hin-Tak Leung for making this possible
This tool was developed mainly in the 1990s, and had fallen into an unmaintained state. The version downloadable from the Microsoft typography web site is from 2003 and it performs 177 tests.
Aaron and I spoke about liberating it so it could be brought up to modern standards in NYC last year, and after getting approval from his team I sought out some volunteers to take a look.
The main obstacle to liberating the tool was that it partially depended on the Windows font rendering system which was unlikely to be liberated, and less importantly, parts of MSIE for XML report rendering.
The corresponding libre renderer is FreeType and Hin-Tak Leung, a FreeType developer, volunteered; his experience with Mono, the libre implementation of Microsofts app platform, made the work ahead to make it run with and without Windows somewhat familiar.
Aaron was then able to pass Hin-Tak parts of the source code that was updated inside MS around 2009, for the last OpenType spec being prepared at that time as well as testing for ClearType rasterization. The 2009 code does 194 tests.
Today Mono on non-windows can be used to build and run it, and Hin-Tak is mainly developing it using GNU+Linux, and i works on Mac OS X also.
Hin-Tak did an amazing job and now that it runs, Aaron has been able to finally post it publicly. Also my thanks to Cosimo Lupo at Dalton Maag for testing and verifying Hin-Tak's work along the way
The 189/194 status in the commit message on the MS repo today is a reference to when the code first passed through Hin-Tak's hands, as 5 of the 194 test did not work; Hin-Tak has since got it up to all but one failing, the DSIG digital signature verification. This version is in his fork, https://github.com/HinTak/Font-Validator
Hin-Tak's near-term roadmap is:
However, finishing those and other remaining pieces sounds like a full time job for a few months - so Hin-Tak would welcome interested parties to commission him to continue. Would anyone here contribute to a crowdfund for that?
Also, MS requires contributors to sign their microsoft-contribution-license-agreement.pdf - does anyone thinking of contributing have any objections to doing so?
@SiDaniels VOLT +1
Curious: does the new version still red flag usWeightClass values that are not multiples of 100?
EDIT: and if it is indeed the correct file, what's the password to unzip the binary?
Could You share the password, please.
The relevant code is near OTFontFileVal/val_OS2.cs near line 233. If it doesn't do what you think it should, please file an issue , and please quote a paragraph from the spec when you do. And better still send a patch!
The tool can move faster than the spec and should take into account things like large longstanding platform behavior, to help font developers produce good fonts.
So I would consider anything under 250 to be a bug.
Or not to update at all. As I understand it, the OT and CSS specs are mutually supporting in this limitation, and one can't change one without changing the other, and hence requiring a lot of people to alter how their software handles weight class.
At this point, my inclination would be to freeze these bits of both specs, declare them legacy, and define new common weight scaling data. If we were really bright, we could express this as a ratio of principal stem weight to a given metric height in the font (e.g. the nominal cap height, bearing in mind that for non-European scripts this might not correspond to a particular letter feature), which would enable the weight scaling data to be used in CSS more like font-size-adjust.
When something is broken in a way that no one seems able to agree on fixing, the obvious thing to do is throw it out and start again.
Of course. As I'm fond of saying, all problems are legacy problems. But there's lots of stuff that we handle in this way, replacing older stuff with new and continuing to support the old stuff until we're reasonably sure that almost everyone has switched to the new. Often, the older stuff isn't even broken in the way weight class is: it's just limited in some way that we'd like to overcome. Conversely, incremental fixes or add-ons to older stuff with fundamental flaws just tends to accumulate more and more legacy issues, which is why I tend to favour the amputation solution, even if we have to carry the dead limb around with us for a while,
#!/usr/bin/env bash # Use https://github.com/HinTak/Font-Validator # or http://sourceforge.net/projects/hp-pxl-jetready/files/private-test-data/FontVal-RELEASE_2015_11_12-bin.zip/download # on Mac OS X # # INSTALL # 1. Install http://brew.sh/ # 2. Run in Terminal: brew install mono # 3. Run in Terminal: brew install freetype # 4. Change line 5 of SharpFont.dll.config to: # <dllentry os="osx" dll="/usr/local/lib/libfreetype.6.dylib" /> # 5. Here, set the folder in which FontValidator.exe and fval.xsl can be found: export FVALDIR=/usr/local/mono/fontval # 6. Save this file as /usr/local/bin/fval and do `chmod gou+x /usr/local/bin/fval` # # RUN # Run this as fval myfont1.ttf myfont2.ttf... for p in "[email protected]" do echo "Validating $p..." # This runs FontValidator.exe via mono and outputs the XML report into the same folder as the font mono "$FVALDIR/FontValidator.exe" -file "$p" -quiet -report-in-font-dir # This converts the XML report into HTML and opens it, removing the XML report xsltproc --output "$p.fval.html" "$FVALDIR/fval.xsl" "$p.report.xml" rm "$p.report.xml" open "$p.fval.html" done
Are the opentype specifications updated?
Logically, if there was no expectation of using finer increments, why would weightclass even go in 100s? Why wouldn't it just use single units like widthclass?
So, (1) the spec does not in fact have the claimed restriction, and (2) based on the content of this and neighboring sections, it is entirely reasonable to assume the opposite.
BTW, something else that definitely needs to be updated: FVAL currently red flags newer versions of the OS/2 (v.4) and gasp (v.1) tables.
For a better example - the EBLC/EBDT tables - it states that bit depths of 1,2,4,8 are allowed. The newer CBLC/EBDT says they allow those, in addition to 32. Now what happens if somebody wrote something that 15, 16, 24? You could says well, the X server does 5,5,5, for 15, and 5,6,5 for 16, and 24 for true color; and pixels should be packed contiguously but another person would say, well, 24 should be intepreted as 32 where the higher 8 bits in not used, by the pixels should be padded to 32 bit.
So the correct approach is to warn any non-specified behavior where there is possible alternative interpretation of off-spec-ness. In this case, one person can implement software to process intermediate value as is (which seems to be what you suggest), but another person might read the spec and say, well, intermediate values should be rounded up or down when used. And both are correct, and both could be wrong. So you warn.