Legality of metric-compatible fonts?

abattis's picture

Over on www-style, Tom Phinney wrote,

"In the broader universe of fonts, these [divergently proportioned fonts] are not the norm at all. Metrically similar fonts do make up a significant chunk of system fonts, though. (Arial/Helvetica, Times/Times New Roman, Book Antiqua/Palatino, etc.)"
- http://lists.w3.org/Archives/Public/www-style/2009May/0058.html

Could anyone who has produced "metric-compatible" fonts explain how copying the metrics of another font is not copyright infringement? :-)

Don McCahill's picture

I'd suggest that because the metrics are numbers, and not designs, they are not considered art, and therefore not copyrightable. A patent might be able to protect them, but very few fonts are patented, and you would have to show that your metrics are somehow unique in order to get patent protection on them.

Si_Daniels's picture

As the practice pre-dates digital, I wonder if there may be some legal precedent around it? But what’s slightly more interesting, to me at least, is aside from the legal issues, if the layout characteristics of a modern OpenType Pro font could be cloned – given the contextual features, class based kerning, etc., - and still be a successful design.

abattis's picture

The points of bezier curves are numbers. But since choosing these numbers involves "creative choices" they are subject to copyright in the USA - quote at http://scripts.sil.org/UNESCO_Font_Lic

Why are metrics different?

@Sii: I don't know about any legal precedents for this, but since AIUI non-digital technologies were seen in US law as typefaces directly, rather than digital representations of typefaces, I don't think there will be any. I also don't know of anyone making a metrics compatible font and being sued under any law (I understand ITC v Monotype was a contractual despite about letter shapes, not specifically metrics.)

canderson's picture

The case for this is the one you've described. If someone wants to create an open-source application, say OpenOffice, and wants to maintain file format compatibility with, say MS Office, metrically identical default fonts are very useful. I kind-of hope this is not protected by copyright...

abattis's picture

Web fonts with similar proportions (and copied metrics) could be important to stop "page flicker"...

Si_Daniels's picture

>Web fonts with similar proportions (and copied metrics) could be important to stop “page flicker”...

An interesting idea. However, to paraphrase Ambassador Spiekermann from the Helvetica film, it’s not the metrical cloning that most people object to, its metrically cloning a font and coming up with a worse design, especially if it becomes more successful and more widespread. How can you improve on Helvetica? It's perfect. Hence any font based on its metrics will be sub-perfect. This is the main reason no one complains about the fonts placed on Arial's metrics.

Move this logic to the Web fonts space and you're quickly looking at designs based on Verdana and Georgia's metrics. Do you feel it’s possible to make better Web fonts than Verdana and Georgia? Are people willing to put their work up against Matthew Carter and give it a try?

Jackson's picture

How can you improve on Helvetica? It’s perfect ... Do you feel it’s possible to make better Web fonts than Verdana and Georgia?

So basically we shouldn't design any new typefaces.

Si_Daniels's picture

No, all I’m saying is if you're designing a new typeface using an existing font's metrics your font will be judged against the original.

Bert Vanderveen's picture

If one can reverse-engineer it, it‘s okay. In other words: print and measure.

. . .
Bert Vanderveen BNO

Nick Shinn's picture

Do you feel it’s possible to make better Web fonts than Verdana and Georgia?

It's certainly possible to make quite different fonts.
There are large genre gaps, niches not filled by the MS TrueType web fonts and ClearType fonts.

It's also true that fonts optimized for low pixel resolution will tend to look similar when small, but there is plenty of scope for divergence at larger sizes.

For instance at small size a Light or Thin font would look the same as a Regular font, in order to not disappear.

John Hudson's picture

Nick: There are large genre gaps, niches not filled by the MS TrueType web fonts and ClearType fonts.

It is also worth noting that the ClearType fonts are not 'screen fonts' per se (something that some critics seem insistent on getting wrong). They were commissioned as 'document fonts', and the expectation was that the documents would be viewed both on screen and in print, hence the nature of the designs and the compromises they exhibit. They're fonts whose forms are treated kindly by ClearType but, as I told Greg Hitchcock at MS, if we'd been commissioned to design fonts specifically for screen, without the consideration of print, or vice versa, then the results would have been different.

***

The irony of Helvetica/Arial is that Helvetica is terribly spaced due to the inheritance of photosetting unitised widths.

Jackson's picture

No, all I’m saying is if you’re designing a new typeface using an existing font’s metrics your font will be judged against the original.

I think you're forgetting why someone would want to match the metrics of another font. It's entirely about space. In theory, you could design a proprietary Garamond that fits Helvetica's metrics. They would set the same, existing documents changed to the new font wouldn't re-rag, etc. Making formal comparisons between the theoretical new Garamond and Helvetica would be silly and pointless.

Rob O. Font's picture

John:...as I told Greg Hitchcock at MS, if we’d been commissioned to design fonts specifically for screen, without the consideration of print, or vice versa, then the results would have been different.

This becoming a storied evolution — You are aware the fonts are called the "ClearType Collection", and that Cleartype is an innovative and revolutionary font rendering sub-system patented solely for the purpose of improving screen fonts at low resolution?

And also, how do you imagine you would have done things differently? And also when you say "without the consideration of print, or vice versa"... the fonts were designed without consideration for print or screen? I'm confused.

Cheers!

Si_Daniels's picture

>In theory, you could design a proprietary Garamond that fits Helvetica’s metrics.

it's my experience that placing a serif i on a sans serif i's metrics is theoretically difficult in most cases.

>Making formal comparisons between the theoretical new Garamond and Helvetica would be silly and pointless.

Tell that to the people who've made a career comparing Arial with Helvetica. They don't see that as pointless or silly. Likewise I can guarantee the first font made on Verdana's metrics will be compared to Verdana - and I somewhat doubt the comparison will be declared pointless, or silly.

John Hudson's picture

David: This becoming a storied evolution — You are aware the fonts are called the “ClearType Collection”, and that Cleartype is an innovative and revolutionary font rendering sub-system patented solely for the purpose of improving screen fonts at low resolution?

No, not for 'improving screen fonts at low resolution'; for improving fonts on screen at low resolution. You understand the distinction between 'screen fonts' and 'fonts on screen'? ClearType is a technology for making fonts look more like typefaces at low resolutions on screen, and less like brick patterns. It is applied to all TT fonts (and now, in WPF and DWrite, to CFF fonts), regardless of whether those fonts are designed as 'screen fonts'.

The ClearType collection fonts were designed to look good in ClearType rendering. But the design brief was that they should look good on screen and in print, not that they were screen fonts. The fact that one of the primary in-house customers for the fonts was Office should make this obvious: Word continues to be primarily a tool for creating print documents.

And also, how do you imagine you would have done things differently? And also when you say “without the consideration of print, or vice versa”... the fonts were designed without consideration for print or screen? I’m confused.

By vice versa, I meant that fonts would be different than they are if they were designed solely for screen or solely for print. You know this, David, because you were sitting next to me in the lobby of the hotel at TypeCon in Seattle when I explained this to Greg. That's when he mentioned that Bill Gates had initially floated the idea of fonts having two sets of outlines -- one for print and one for screen --, and my estimation of Mr Gates went up considerably. But they didn't do that, and the result is that fonts that try to meet the brief to 'look good on screen and in print' are necessarily compromised and will not be optimised for either medium.

A few days ago, I listened to part of a BBC radio show in which Brian Eno was talking about his experience of producing Windows system sounds. The brief was a document describing how the sounds should be exciting, contemporary, sexy, friendly, and a whole string of other random adjectives, and no longer than 3.4 seconds. I laughed at what is, to me, a very familiar circumstance.

Rob O. Font's picture

John, A great story. I was sitting next to you in the lobby of the hotel. Greg was wearing mismatched tennis shoes. No one ever mentioned that Bill Gates misunderstood the use of TT hints so totally that he thought a second set of outlines would help, instead of a single properly hinted outline! I would have jumped on that idea it 'till t'was completely buried. Is it a good idea now? Was that ever a good idea?

"No, not for ’improving screen fonts at low resolution’..." Yes, John, read the patents! Watch the video! You remember this part? Greg asked, "...and what is print?" I lost interest after that question. Now... I only understand the distinction between people willing to take responsibility for, and fix the trust between developers and readers, and people who are not.

Cheers!

Thomas Phinney's picture

I just want to clarify an error in the quote from me that was used to kick off this thread. It's not a huge deal, but:

“In the broader universe of fonts, these [divergently proportioned fonts] are not the norm at all. Metrically similar fonts do make up a significant chunk of system fonts, though. (Arial/Helvetica, Times/Times New Roman, Book Antiqua/Palatino, etc.)”

"These" refers to fonts that share metrics, the *opposite* of divergently-proportioned fonts.

This was in the context of arguing that you could not, in general, sub out one font for another without getting reflow.

Cheers,

T

John Hudson's picture

David, what do you think ‘improving screen fonts at low resolution’ -- in the context of ClearType -- means?

This is how I analyse it:

First of all, there is no such thing as a ‘screen font’ as a technical entity in TrueType, unlike old Mac Type 1 fonts, so I take screen fonts to mean simply 'fonts on screen'. The other possible meaning of 'screen font', as a typeface designed specifically for reading on screen such as Verdana, doesn't apply since ClearType is applied to all fonts.

Now, in what sense does ClearType ‘improve’ fonts on screen? And relative to what does it improve them?

Perhaps it improves them in terms of legibility? But black and white bitmaps are pretty darned legible, and at very small sizes they're still more legible than ClearType on even a moderately high resolution screen. The trouble with black and white bitmaps, though, is that they don't look like type. They don't look like type in two ways: generally, they lack the character of typographic letters, looking more like brick mosaics, and, specifically, they lack fidelity to individual typeface designs, since the low resolution grid is too coarse to represent detail or curve style. Hence the development of anti-aliasing techniques, which I think reveal the primary thrust of all screen rendering technology developments after the initial development of TrueType: making fonts on screen look more like type.

The trouble with greyscale anti-aliasing, though, is that it reduces stroke density, and this demonstrable impedes legibility, especially at small sizes. And hence the gasp table, and the ability to determine the size at which anti-aliasing kicks in: leaving those nicely legible black and white bitmaps (either hint-controlled or embedded) at smaller sizes. So fonts on screen were legible at small sizes and looked more like type at larger sizes.

Now, again, in what sense does ClearType ‘improve’ on this, if small black and white bitmaps are already legible and large greyscale bitmaps are already type-like? The only way in which the statement can be interpreted as true is to say that ‘ClearType improves the fidelity of fonts on screen to type -- makes fonts on screen more “type-like” -- at smaller sizes while retaining stroke density’. That is what ClearType does: as with other anti-aliasing technologies, its primary purpose, its principle thrust, is to make fonts on screen look more like type, both in a general sense and in fidelity to specific typeface designs.

So, what are the ClearType Collection fonts? They're a response to the observation of how ClearType works, rather than to an understanding of what ClearType does. If that sounds like someone, somewhere is confused, that's because someone is. It's either me or Microsoft, and I think it is Microsoft. They have a technology that makes fonts on screen look more like type, but they are trying to understand that technology in terms of readability. I can see the justification for this relative to other forms of anti-aliasing and, e.g. contra Apple, who have decided to completely avoid the question of readability by freely anti-aliasing everything at every size and in every direction. But this -- along with an internal market for particular kinds of fonts -- leads Microsoft to demand contradictory things from type designers. On the one hand, they have a technology that, justifiably, they can claim makes fonts on screen -- all fonts -- look more like typefaces. On the other hand, this technology works in specific ways that favours certain kinds of shapes and design characteristics, and this suggests that typefaces could be designed to take advantage of how the technology works, with the goal of improving screen readability over the existing MS core fonts. On the third hand, they have internal customers for fonts, such as Word, who want fonts that will be readable on screen but who are still primarily in the business of producing documents for print, who still see fonts on screen more in terms of creating text than reading text, and who are looking to replace Times Roman and Arial as default document fonts. On the fourth hand, they have -- or rather had -- the promise from multiple laptop and monitor manufacturers, almost a decade ago, that they would be standardising on 120 ppi or higher resolution screens, a promise that has not come to fruition as these companies have chosen to keep the price of such screens artificially high by flooding the lower end of the market with cheap crap. And on the fifth hand, they have what seems to be an ingrained and company-wide desire for every product to be all things to all people. With that many hands, no wonder they're confused.

I first saw ClearType on a 200 ppi device -- 8pt Palatino, legible, nice dark strokes, and recognisably Palatino --, which perhaps explains why I blame the companies that make and sell cheap crap monitors for breaking ‘the trust between developers and readers’. They're the ones who failed to follow through. In the past, you've accused me of being elitist because I favour high resolution screens on which ClearType functions better. I'm not elitist: I think everyone should have these screens and that these screens should be affordably priced. I do not believe that the difference in manufacturing costs is fairly represented in the difference in price.

abattis's picture

@Thomas: Sorry for misquoting, my mistake!

Rob O. Font's picture

JohnHudson>First of all, there is no such thing as a ‘screen font’ as a technical entity in TrueType...

With all dying respect, this's true, though it is not correct.

In 1989 Apple asked me to learn TT and I did. In the same year they asked to me instruct some fonts and I learned the tool, (royalT). As I was attempting to prove TT instructing (on the 'standard' pi font), I noticed the glyph window displayed two unnumbered points sitting at the baseline looking suspiciously like side bearing markers. I asked why these points didn't have point numbers, "I want to instruct them!"

Apple tech guys said I could not instruct these 'phantom points' because the metrics were being defined outside of the designer's control as unrounded or rounded pixel values. Back with the Apple font boss I confirmed the specification was to produce fonts at all sizes 8-24 ppm equal in quality to the fonts they were replacing (screen fonts!), which she did. I quit, as neither I nor anyone else could do the job without total control of the character's pixel widths.

Having come from an environment of extreme quality control and user concern for all things fonts, she knew, and rehired me. The engineers then tried to confine me to only instruct to narrower widths than those implied by the outlines, and I refused. Then, Apple appended the point numbers on the end of the glyph's points, (I can see now I should have wanted them accreted to the beginning:(duh), and... Apple made the hdmx table.

TT had the ‘screen font’ as a technical capability from 1.0 on. Still does (http://www.microsoft.com/typography/otspec/hdmx.htm), is one part. Managing the instructions is another part. Designing an outline is the third, optional part.

What happened next (including all the way up to this conversation), is an interesting story. As I've said all along, it is perhaps the most interesting type technology story of all time!

The Superior Way To The Modern Low Resolution User's Reading Organs, Is Through AA shapes, and Aliased, Integer, Discrete, Whole PiXel Widths (choose your term). I have not changed this story one iota since long before CT was introduced to me at a Poynter Institute mini-conference on the subject of higher quality wysiwyg fonts for editors, (just kidding, it was about readability in screen fonts. I guess the MS folks just had this one hammer though, so they brought it).

If there's anything at all you don't understand here, please ask.

JohnHudson>That is what ClearType does: as with other anti-aliasing technologies, its primary purpose, its principle thrust, is to make fonts on screen look more like type...

Be clear... ClearType is not one part. Applied as the parts are, CT makes type on screen look like its printed version. Anti-aliasing technologies do not have to be so limited.

JohnHudson>I’m not elitist: I think everyone should have these screens and that these screens should be affordably priced.

I'm not laughing, (if that's a joke).

Cheers

Rob O. Font's picture

Sii>it’s my experience that placing a serif i on a sans serif i’s metrics is theoretically difficult in most cases.
This is theoretically difficult only if you design the sans without a complete specification. :)

Cheers!

Si_Daniels's picture

>This is theoretically difficult only if you design the sans without a complete specification. :)

True, if only Max Miedinger had considered that someone would want to do a Serifavetica he could have certainly made life easier for us.

John Hudson's picture

David: ClearType is not one part. Applied as the parts are, CT makes type on screen look like its printed version. Anti-aliasing technologies do not have to be so limited.

Yes, that's a good statement.

I do think that the primary drive of rendering technologies over the past fifteen or so years has been toward making fonts on screen look more like type, which in most peoples' minds still implies 'like its printed version' or 'like the design you see in the outlines'. I think that has been the case even when some of the developers involved thought they were doing something else, like focusing on readability. In fact, they're treating readability as a quality to be added back into the technology after whatever sacrifices have been made to make the fonts look like type. Apple said, ‘We're going to make fonts on screen look as much like the outline design as our full fuzz renderer can achieve.' Microsoft said, ‘We're going to make fonts on screen look as much like the printed version as possible, and then we're going to try to make them readable too.'

Which led them to start asking questions like ‘What is reading?'

Rob O. Font's picture

>Which led them to start asking questions like ‘What is reading?’

A good point. I think they also started asking questions like "what is type?", "how is it made?", and "why do we have to make it over and over again?"

>they’re treating readability as a quality to be added back into the technology after whatever sacrifices have been made to make the fonts look like type

Another good point. But as I've told them all, this is not the way. You don't take control from the experts and pretend you have not. And if you look at the history of "How to make good screen fonts", (which is written in TT quite clearly), you can see that they can't get 'there' from 'where they are', (unless resolution dramatically increases among ALL users).

So now, having wasted 15 years, what do you think they'll do next? Add an impossibly illegal 'wrapper-without permissions'? propose dozens of hardly useful OT features? distill the use of TT instructions down, down, down to one simple instruction? ;)

Last think... to loop back to the topic... when Apple made TT screen fonts, as we did, and MS cloned them as they did, how did they copy the metrics covered by the hdmx table? Today, I've been told, MS's CT working in 'compatible' mode gets the compatible metrics by rendering the font through a PS interpreter. CT then takes those metrics and forces the CT to render on those widths? why is this better than the hdmx table, e.g.?

Cheers!

John Hudson's picture

David: Today, I’ve been told, MS’s CT working in ’compatible’ mode gets the compatible metrics by rendering the font through a PS interpreter. CT then takes those metrics and forces the CT to render on those widths? why is this better than the hdmx table, e.g.?

To hazard a guess as to why they might do this, I believe subpixel positioning was a primary assumption of the technology, in which case they thought the hdmx table was dispensible; then things got messy because someone at MS -- my guess is Word developers -- wanted full pixel compatible widths. But since the hdmx table data in existing fonts is closely related to the x-direction hinting including deltas -- e.g. a counter is made wider for small ppem b/w rendering and ergo the width is also delta'd -- that hdmx data has to be ignored of one is ignoring the x-direction outline deltas, otherwise you get a mismatch between the CT rendered letter shape and its hdmx-determined width.

I think you and I agree (Cheers!) that the screen font baby shouldn't have been thrown out with the b/w rendering bathwater. A better solution would have been either a new hdmx table version for subpixel environments or, better yet, hdmx subtable formats that would enable the same font to have independently targeted widths for full pixel and subpixel environments.

Syndicate content Syndicate content