by Michael S. Kaplan, published on 2008/07/03 10:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/07/03/8682763.aspx
Previous blogs in this series:
One of the first things people do when they enter the room is make themselves known.
If everyone knows everyone else they don't even need names, otherwise they give their name.
If they are twins (and this has happened to me, within the last few years!) the twin who is there will identify which "version" they are.
The version thing is pretty important, as you can see.
Now version information is pretty straightforward in Windows....
Hell, I can't even say that with a straight face.
You can look at Raymond Chen's Blog, and blogs like this one and that one and this other one if you want a hint about how complicated it is.
If you are internal to MS you might have seen the dozens of small utilities put up by developers and testers over the years, almost all of which properly update at a maximum just one of the two items to update (the string version of the resources and the binary one), and some did not even get one of them right.
So version stuff on binaries is tough in Windows.
But tough as it is, it is actually a lot easier than the version information in fonts, unless you are writing an application that walks through the font file data ad its purpose in life.
Because in order to get the font version information, you have to walk through font file data.
Specifically, you are looking for the name table.
This table, this name table, has an entry in it that specifies the version.
The entry might just be 1.0. Or it might be 1.0.3. Or it might be 867.5309. Or even 3.1415926.
Crap, it could be Version 3.14. Or it could use the word Versio, or Versión, or Versione. You get the point.
Or really anything -- it is a string, after all.
Maybe we can hope for valid characters....
The exact format of the string can be anything, and a font vendor/foundry can even change the format they use between versions, if they want. If they do they might even have a good reason for wanting to do that. But even if they did not, they can still do it.
Hell, two different fonts from two different places can have the same name and the first of many comparisons you might do is with the name and the version. Just dig right in, like I did in Getting all of the localized names of a font but perhaps much more efficiently. :-)
If you are building something that has the job to install a font and you need to know if a font already there is a prior version or a later version, you have to be able to parse that information so you can compare the two (and decide which one is newer).
I find myself grateful about the fact that the twins I referred to previously were in two different disciplines - development and test -- and therefore I did not fancy heuristics to tell them apart; merely listening to what they opinions were would often quickly identify the one present, if the meeting itself did not!
No such boon can be assumed with fonts. Your generic awesome font installation code needs to assume the worst.
Since the worst can indeed happen.
Okay, this seems like a fair enough start, hinting at inner depths. Next time I'll dig into some of those depths a bit....
This blog brought to you by f (U+FF46, aka FULLWIDTH LATIN SMALL LETTER F)
referenced by
2008/09/08 On installing and removing fonts, Part 8: Sometimes being selfish makes you more trustworthy
2008/07/30 On installing and removing fonts, Part 7: What was the question, exactly?
2008/07/14 On installing and removing fonts, Part 5: The takeaway from that is...
2008/07/11 On installing and removing fonts, Part 4: The easiest part is the addition!
2008/07/08 On installing and removing fonts, Part 3: I'll love you forever, or at least for this session.
2008/07/07 On installing and removing fonts, Part 2: Are you done using me yet?