We are working on a program that needs to distinguish between OpenType fonts to TTF fonts [like the font list InDesign has], but we could not mannge to find the right way to determine if a given font is OpenType format file.
I have found some discussions about it on Stackoverflow - like:
here and
here and
here.
And it seems that they don't have the right answer, cause it does not depend on file extension, for there can be a TTF file that has opentype format.
So my question is - how can i make my program distinguish between OpenType font file to TrueType font file.
Comments
This makes me figure that the distinguish we need is between fonts that have opentype features to other fonts that have no features, for it looks like designers that want to use a font, might prefer those that has opentype features, and that what makes them think "this is an opentype font".
Though i am not sure but it might be the way InDesign do that on there font list.
Back in 1997, when OpenType was announced, the only distinction Microsoft could come up with between a TrueType font and an OpenType font with TT outlines was the presence of a DSIG table, since the OTL tables were all considered optional. So technically, one can have a TTF with OTL tables that is not an OpenType font.
And of course it is possible to make a CFF font with no OTL features, and InDesign will dutifully assign it the OT icon.
It sounds like for your purposes you're going to want to check for the presence of a GSUB table. That's the most likely indicator that a font contains some kind of glyph processing beyond the cmap table.
The comment above that code says "TODO: is this oversimplified?", and judging by the comments in this thread the answer to that is "yes".
For many needs, what Roel does, and what Adobe does, is useful: distinguish between the two different kinds of outlines.
I do not find the approach Windows uses to ever be helpful.
You could try to make some kind of feature-based distinction instead. Depends on your audience and needs, that might be fine. For myself, I don’t find it helpful to have two different fonts with different outline formats to get the same icon/indicator. But it depends on your audience and their needs.
This is not right, in my opinion.
The OpenType fonts that are not TrueType fonts are the "CFF flavor" ones.
I believe that a simple heuristic to answer Yeshurun Kubi's question, "how can i make my program distinguish between OpenType font file to TrueType font file" is by checking for the presence of either a CFF or GSUB table - if either is present, its OpenType, and if neither is present, its TrueType.
Your 'glyph processing' is not exactly exact, by the way, as 'GX/AAT glyph processing' indicates, with 'GX' referring to interpolation of glyphs' outlines and 'AAT' referring to layout or positioning of glyphs.
What I find striking, given above attempts to clarify the meaning of 'OpenType', is just how cleverly vague the term 'OpenType' is, and has been since day one, which makes me wonder if this is intentionally so. For illustration: How to express that a font uses either glyf/loca or CFF[2] tables for outline description – but addresses a different layout technology? Correctly speaking, it would be something like 'based on standard sfnt font data structure', but then ... explain 'sfnt' to a lay or even type designer audience ... so one inevitably needs to resort to a better known term like 'TrueType based' or 'OpenType based'. Yet 'TrueType' most likely bears the connotation of glyf/loca outline description while 'OpenType' is associated with OTL and 'features' in particular. But then, the ambiguity of the data format's (or data formats') name (or names) reflects the mess, or more politely: diversity, of data that one may find inside, so it may be considered appropriate.
The term 'smart font' was common in the introduction of OpenType twenty years ago. I don't recall, but it is quite possible that the term was also used around the introduction of GX fonts. SIL use the term also in reference to their Graphite glyph processing, which I should have thought to include in my diagram. DecoType doesn't have a monopoly on the use of the term or on its interpretation.
I don't think the vagueness of the meaning of the term 'OpenType' is intentional; rather, it is the evolved outcome of the fact that the most distinctive aspects of the format are all optional tables. The name was a compromise, because originally it had been TrueType Open, but when Adobe asked for CFF to be incorporated into the format a new name was needed to indicate that it wasn't just TrueType. Then the problem became how to distinguish between a TrueType font and an OpenType font for trademark purposes. TrueType is an Apple trademark; OpenType is a Microsoft trademark. So when does the MS trademark apply to a font? When the format was first published, the distinction was made based on the presence of a DSIG table, since that was at that time defined as the only new table in the OpenType format that wasn't optional. So there was a definition of OpenType for legal purposes that ended up being completely irrelevant to the use of the term in practice by font makers and users.
As to GX/AAT, I am aware of all this, the old QuickDraw brochure still sits somewhere on one of my bookshelves. But history does not really help with today's 'define the format' effort. There is no monolithic QuickDraw GX plus TrueType GX any more (where outline description, outline variation, line layout etc are part and parcel), as opposed to a monolithic OpenType with Microsoft OpenType Layout technology inside (TrueType+ but unfortunately Adobe brought CFF plus some other tables to the table too, when again one term ended up referring to more than just one specific aspect of it). Things are more fragmented now, and separate ingredients need to be told apart in a meaningful way, ideally by category (outline description? outline scaling? outline interpolation/variation? layout technology?), to make an at least halfway precise description possible.
To allow for more precision, a chart better be structured by way of categories, rather than a list (even if hierarchical):
This allows to choose, per each category, without a risk to make or evoke implicit assumptions about any other category.
* Note how I keep outline data and outline table separate. E.g. URW stored IK, bezier, etc data (almost) the same way. E.g. it has been discussed to store cubic bezier data the same way as quadratic bezier data, in glyf/loca tables.
† Including glyph substitution and positioning.
[Now this is completely outside of the scope of the original question.]
As I wrote earlier, I don't recall whether the term was used around the time that GX fonts were announced, but by the time OpenType arrived there was a need to distinguish between fonts with glyph processing capabilities (smart) and those without (dumb). This was common parlance when talking with folk in the relevant technical teams at Microsoft and Adobe, and the term is intuitive enough — and non-specific in terms of particular technology — that I've never found anyone to be confused as to what it meant. When SIL announced Graphite at the Unicode conference, they used the term 'a smart font technology' and everyone understood it to refer to parallel Graphite to AAT and OpenType.
from NRSI Update #1 – July 1996
I think it is quite possible that SIL personnel first started using the term and the rest of us picked it up from there.
Yes, although technically CFF is not actually PostScript in the sense that Type 1 fonts were.
As far as the convention goes, technically a font could be recognized by older OSs by merely changing the extension at desktop level?