Microsoft Font Validator lives!

Hin-Tak Leung

Adam Twardoch said:

@Hin-Tak Leung , @Aaron Bell: HinTak's fork https://github.com/HinTak/Font-Validator is missing the Issues tab on Github. Is this a deliberate decision? Is https://github.com/Microsoft/Font-Validator/issues the correct place to file issues, even for Hin-Tak's fork? 

I don't know why mine doesn't have a 'issue' tab - maybe because it is a 'fork' :-). But I seem to get e-mails for all the issues /pull'es filed at https://github.com/Microsoft/Font-Validator/issues anyway. So at least for the time being, you can just file there. Whether I want to /have time to respond, that's a different matter...

Hin-Tak Leung

Paul van der Laan said:

Thank you Thomas, for weighing in (no pun intented).

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.

Current OS/2 is v5. I thought that's mentioned in my pull message: the binary I uploaded would warning anything below v5 as too low, but incorrectly say the current value is v3. The latter is fixed in my post-release commit c3efbe09d627b8d3a745e46a91658f15492e3feb - you need to build from git to get the latter.

I'll have a look at the gasp issue and get back to you on it.

Hin-Tak Leung

Hmm, it looks like some of you like to argue that the spec is wrong, or at least, different/ignorant of existing "common practice". I don't have a strong feeling about the correctness of specific part(s) of the spec. However, the font validator is supposed to tell you how different and in what way is your font different from what the spec says. If you disagree with the spec [specfiic part(s) therein], obviously you are free to ignore the warnings; but it would be incorrect for the validator not to issue those warnings.

Hin-Tak Leung

It is also quite interesting that so far the majority of proposed changes are to *suppress* specific warnings that some people feel not justified.

At least on my current "preoccupation" with the DSIG check, I am going to emit *additional* warnings. The old code (which I don't receive anyway) is just pass/fail, plus without signature or general application errors. I have found a few different ways where it is not quite a pass - for example, the spec certainly says that member fonts in a ttc should not have a DSIG table. The old code does not check that, and pass/fail is purely based on whether the ttc has an overall signature. The version I am working on, will emit a warning if a member font in a ttc contain a DSIG table. I have seen that issue in 5 fonts shipped in Mac OS X - so the old version will says it does not have a signature - the new/incomplete version will also say it does not have a signature, but *in addition*, it will warn that a member font does.

Hin-Tak Leung

@Paul van der Laan The 189/194 version from Microsoft does not understand OS/2 v4 - it supports up to v3 (and refuses to go further for v4). My current HEAD updated that part to to the 2015 spec and v5 is current (prompted by a test font Beddad gave me to implement CBDT/CBLC support). v4 happened a few years ago with otspec 1.6, I think. Current is 1.7.

Hin-Tak Leung

Regarding the OS/2 weight class issue, why bother to have a table of listed values at all, if they are not meant to be the allowed ones? If any values are allowed, there does not seem to be any reason for a table of values. So as far as my reading of the specs goes, *the intention of the author(s)* is fairly clear that it is a list of allowed values. Otherwise the table can simply be removed.

I really think that if some of you disagree with the spec, you should contact the authoring committee to have it changed. Asking the software not to tell you what the specs says, seems to be 'shooting the messenger'.

attar

Hin-Tak Leung said:

I don't know why mine doesn't have a 'issue' tab - maybe because it is a 'fork' :-).

It's desabled by default for forks, you need to enable it in the settings tab of the repository.

Paul van der Laan

Hin-Tak Leung said:
I am inclined to disgree - the tool is supposed to take a pedantic approach, to warn for any indeterministic behavior.

A *warning* (yellow mark) is fine with me in this case. But currently usWeight values that are not multiples of 100 are marked in red as *errors*. Big difference.

Regarding the *purpose* of the usWeight values there is a very clear one: to aid the sorting order in font menus. Many applications, such as Adobe apps, are using this.

Deleted Account

"I really think that if some of you disagree with the spec, you should contact the authoring committee to have it changed. "

Splendid idea. But after a decade of contacting and being contracted by the authors, we made our own system. It uses 1000s of an em to describe the weights and widths of glyphs, glyph groups, considers these down to a single 3 digit value depending on Stuff. This issue, I think, is even more contaminated when one gets to size, which in our system ranges from .1 em or 2pts, to infinity in print and beyond that on the web. Yet there are how many size masters definable in the best optical sizing any OS can muster. 

And, there has been a request for valid "error" filtering, since FV was first released 200 years ago. Type designers go through hundreds of checklists on thousands of elements, and adding 50% fluff or semi-fluff to a list at the very end of what is often a long torturous march through technology-over-mind-infested swampland, to me, has always seemed a bit insensitive to the delicate orchids of type.

Thomas Phinney

What's indeterministic about a number without a label? I suppose it's "indeterministic" if your environment requires numbers==labels, but that's an implementation error. There's no "interpretation" involved if you accept that arbitrary numbers are possible.

The EBLC/EBDT case is not comparable.

John Hudson

Given today's emphasis on Web typography, there's not a lot of point in considering the OS/2 weight class specification independently of the CSS font-weight property, whose authors clearly interpreted the former as being limited to that discrete set of multiples of 100. Changing the OT spec without also changing the CSS spec seems pointless at this stage, and changing the latter will reportedly break a bunch of stuff. Hence the persisting deadlock.

Adam Twardoch

@John Hudson, 

CSS, just like other client implementations, used to make a lot of naive assumptions about aspects of the OpenType spec, and probably still does.

Quite obviously, CSS lifted the 100-900 idea from the OT spec, not the other way around. CSS codified what they thought was sensible common practice, but did so without much consultation with font vendors. 

So the OT spec should lead the way, and other derived implementations should then follow. 

Adam Twardoch

But admittedly, the usWeightClass description in the OS/2 table is weak. It defines it an unsigned integer and the cites 9 values in a table labeled "Comments". It's not entirely clear if the spec sees these values as "mandatory" or "exemplary". 

I think we should define an all-new SFNT table with sensible typographic design parameters for a font, taking multi-script aspects into account. Numerical descriptors are a reasonable thing but the old OS/2 structures have outlived its usefulness, I think. The new thing could be merged with the EPAR effort, and learn from the PANOSE experience. 

John Hudson

Coincidentally, Sairus Patel from Adobe has today submitted for feedback a proposal to revise the OT specification re. weight classes. Feedback should be posted to either the OT font developer list or to the mpeg-OTspec standardisation list, although I'll also point Sairus here.

There are several aspects of OS/2.usWeightClass http://www.microsoft.com/typography/otspec/os2.htm#wtc that have been problematic for many years now:

1. Granularity: Only 9 values are listed (though other values aren’t explicitly prohibited). A finer granularity is desired in order to express the full richness of typographic weight variance. Note that the CSS4 draft https://drafts.csswg.org/css-fonts-4/ allows font-weight values in the range [1..999].

2. “GDI skewing”: Values < 250 are sometimes set to 250 by the font designer to avoid GDI synthetic emboldening. Other issues with weight class on the upper limit and with style linking may be involved as well. See https://rawgit.com/adobe-type-tools/afdko/master/FDK/Technical%20Documentation/WinWeights.html, which may be a bit dated, but much is still valid. Also see John Daggett’s post: https://lists.w3.org/Archives/Public/www-style/2015Jan/0076.html. 

3. Sometimes an OS or font engine will not trust the weight class values (perhaps in part, because of #2 above) & resort to heuristics. Mozilla has reported that Apple uses heuristics & doesn’t seem to use the recorded weight class (see John’s post above).

I propose the MAIN PROPOSAL below, which addresses issue #1.

I seek feedback on the POSSIBLE ADDITIONAL PROPOSAL and its VARIANT below, which address issues #2 and #3: are these issues worth solving, & is this the best way to do it?

=== MAIN PROPOSAL (addresses issue #1):

{ Add this clarification to usWeightClass, to the end of the “Description” section: }

Only values from 1–999 are valid.

{ Add this clarification to the start of the “Comments” section of usWeightClass, before the table: }

There may be legacy platform limitations on certain usWeightClass values. The following are commonly set values:

=== POSSIBLE ADDITIONAL PROPOSAL to also address issues #2 and #3:

{ Bump OS/2 version to 6. Add this new field to the end of the table: }

usTypoWeightClass

Format: USHORT

Description: Typographic weight class. Only values of 1–999 are valid. Common values are as listed in the table for the usWeightClass field. The usWeightClass field may have been historically set in some fonts inaccurately, to work around various legacy platform-specific limitations. usTypoWeightClass is free from platform limitations and reflects the true visual weight of the font.

=== VARIANT of POSSIBLE ADDITIONAL PROPOSAL:

Another way to address #2 and #3 instead of a new usTypoWeightClass field:

We could add a  one or more flags to OS/2.fsSelection to indicate, for example, that usWeightClass of 250 really means a weight class of 100. The problem with this approach is that several such flags may be needed since several such values have been distorted (100, 200, perhaps some in the upper range as well), & a mapping needs to be agreed upon e.g. 250 => 100, xxx => 200, … It would be a font and font engine change anyway, so we may as well make it explicit, following the model of the sTypoAscender & similar fields.

Hin-Tak Leung

I rarely look at the reports in the GUI so the error/warning/informative status of a message has no meaning for me - it is just a text (structured xml text) report. If some of you thinks an error (black or red in the GUI? ) should be a warning (yellow?), a warning should be informative (white?), etc, the appropriate place of change is   GenerateFValData/OurData.xml .

As for the weight class issue specifically - two persons reading the spec could one decide to interprete intemediate values as is, while the other thinks values should be rounded up/down to nearest 100. So there is a problem for ambiguity, and a warning is warranted.

Personally I am also not inclined to take accept changes which favourites one reading of the spec over the other.

Hin-Tak Leung

Thomas Phinney said:

What's indeterministic about a number without a label? I suppose it's "indeterministic" if your environment requires numbers==labels, but that's an implementation error. There's no "interpretation" involved if you accept that arbitrary numbers are possible.

The EBLC/EBDT case is not comparable.

One can decide to round values up/down to nearest 100,  while another decides to uses intermediate values as is.

The situation is the same with EBLC/EBDT. If somebody specify a bit depth of 17 - (outside of 1,2,4,8, 32) - do you pad to 32, pad to 24, or truncate to 16 or 8, or allow a continuous stream of 17-bit follow by 17-bits?

Deleted Account

"Hence the persisting deadlock" which is exactly why a tiny group of well-visioned veterans tried to convince you, and others, to update OT for the web before "inventing" Woff. 

The best thing to do now, is get the f out ahead of lilley and the stroke font people before that f-up joins this one.

Dave Crossland

So the OT spec should lead the way, and other derived implementations should then follow. 

Note that the CSS4 draft https://drafts.csswg.org/css-fonts-4/ allows font-weight values in the range [1..999].

I think we should define an all-new SFNT table with sensible typographic design parameters for a font

I think Sairus' new OS/2 table item would be sufficient to address this.

I don't think scope-creep would be helpful, especially since EPAR seems unlikely to ever be acceptable to major tech company legal teams.

Deleted Account

I think OS/2 is fine with Dave, because Dave is deeply embedded. So the term OS/2 itself is an acceptable name for a font metadata table when approaching an unembedded audience.

This thread, is not about permissions! but if one does not think the P in epar like data is acceptable legally, one does not have to use it. I think it pretty Leary, Really Leary in fact, to suggest users of the future not have metadata 'for legal reasons'. 

Thomas Phinney

John Hudson said:

Coincidentally, Sairus Patel from Adobe has today submitted for feedback a proposal to revise the OT specification re. weight classes. Feedback should be posted to either the OT font developer list or to the mpeg-OTspec standardisation list, although I'll also point Sairus here.

I am not convinced this is coincidental.  

Hin-Tak Leung

194/194 build arrives.

I don't want cut-and-paste, so the details is on

https://github.com/Microsoft/Font-Validator/pull/1#issuecomment-158703819

Sufficient to say, I have finished testing the 194/194 build,
which implements the last missing DSIG table test.

People having vintage signed TTC's around the 1996-2001 time frame
which should verify but don't, please send me a copy.

Special thanks for Cosimo.

Ramiro Espinoza

Mac.10.9.test.zip "decompression failed"

Hin-Tak Leung

Ramiro Espinoza said:

Mac.10.9.test.zip "decompression failed"

Wrong file - that's something unrelated. Don't you read the date in the 2nd column??? The most recent uploads are at the top and that's all you need. Why are you trying to download the oldest of it all, something from 2 years ago?

Ramiro Espinoza

...because I am not familiar with Github?

Sami Artur Mandelbaum

Hin-Tak Leung said:

194/194 build arrives.

I don't want cut-and-paste, so the details is on

https://github.com/Microsoft/Font-Validator/pull/1#issuecomment-158703819

Sufficient to say, I have finished testing the 194/194 build,
which implements the last missing DSIG table test.

People having vintage signed TTC's around the 1996-2001 time frame
which should verify but don't, please send me a copy.

Special thanks for Cosimo.

Thank You very much Hin-Tak but some opentype specifications are not updated:

MATH

Error code	Message	Details
I0040	Not an OpenType table, contents not validated

Math table is in the new opentype 1.7 specifications:
http://www.microsoft.com/typography/otspec/math.htm
http://www.microsoft.com/typography/otspec/changes.htm

Hin-Tak Leung

Sami Artur Mandelbaum said:

Hin-Tak Leung said:

194/194 build arrives.

I don't want cut-and-paste, so the details is on

https://github.com/Microsoft/Font-Validator/pull/1#issuecomment-158703819

Sufficient to say, I have finished testing the 194/194 build,
which implements the last missing DSIG table test.

People having vintage signed TTC's around the 1996-2001 time frame
which should verify but don't, please send me a copy.

Special thanks for Cosimo.

Thank You very much Hin-Tak but some opentype specifications are not updated:

MATH

Error code	Message	Details
I0040	Not an OpenType table, contents not validated

Math table is in the new opentype 1.7 specifications:
http://www.microsoft.com/typography/otspec/math.htm
http://www.microsoft.com/typography/otspec/changes.htm

Pushed bare (untested) addition for COLR/CPAL/MATH/SVG for now. If you build from git head it should work, finger-crossed. OTOH, you should file this at the Microsoft github issue tracker, together with providing a URL for such a new font for further work.

CBLC/CBDT was added a few weeks ago, together with OS/2 going up to v5, because Behdad posted one such font on freetype-devel.

Sami Artur Mandelbaum

Thank you again Hin-Tak!
Here is the link for a MATH font: https://github.com/khaledhosny/xits-math
Unfortunately I don't know how to build from git head.
I will wait the next binary update.
Sami

Diego Maldonado

@Adam Twardoch – sorry Adam, I'm a bit of noob on Terminal, I'm trying to read/use your code, but it's not clear to me what should I do. Should I just paste it on Terminal or should I read this comments and do some code customization?

Hin-Tak Leung

I filed
https://github.com/Microsoft/Font-Validator/issues/8
as place holder to track 'update to 2015 spec'.

Instead of posting ad hoc notices about this and that isn't up to current spec, I'd like people to use that as a central place to keep track of issues, and post a brief note, plus possible font samples for testing, at that URL.

I feel that questions and suggestions about how and why certain part of Font Validator is written in certain way in the past, and would like it changed in certain direction, and or pulls in those parts, aren't in my position to respond or act upon. Those should be dealt with by Aaron and folks at Microsoft as they see fit. I don't have any special insights on those - I have a 4-month head start, and I dare say I am more familiar with mono and c# than some of you, but I don't have any secret design documents about it.

So I'd suggest questions/suggestions/pulls about past codes go to Microsoft's issue tracker. I'd open my own issue tracker, so that I can receive suggestions and issues on the parts I added - the OS/2 multi-lingual code page support, the freetype backend, the DSIG check, the Makefile and the build system (there wasn't any - MS removed those before I got it) - I also added bug fixes, etc to specific fonts I see, etc, and questions about those changes can go there also. 'updates to 2015 spec' gets tracked above, and some community members can tackle some of the issues raised.

Where new issues are easy and quick, like adding COLR/CPAL/MATH/SVG as valid table names, I'd just push those out - but I had made a mistake with the small DSIG fix that accompanied that, and had to rebase those two to fix bug on my DSIG fix (the one about TTC DSIG mis-identified as garbage in last table of last member font). Sorry about that if anybody noticed. So I probably shouldn't treat things as too easy even if it might be.

I'd probably (re-)open my paypal donation button, and or put a kickstart project up. There are little thing like packaging a Mac OS X native executable without mono, that I'l like to do, and I know roughly how to do, but just haven't got the time to do.

Dave Crossland

Your own homepage with a paypal subscription and one time donation option, or Patreon, would be better than Kickstarter, as the latter is for one-time funding drives, whereas the former are 'evergreen.'