[mpeg-OTspec] Draft amendment of ISO/IEC 14496-22 OFF (3rd edition)

[Rob McKaughan]

I agree with John: We shouldn't rush anything into the spec, but instead should take our time to develop something that's thorough and future-proof. I've been working on a proposal, but it is not yet ready.

Thanks
// Rob

-----Original Message-----
From: John Hudson [mailto:john at tiro.ca] 
Sent: Wednesday, June 3, 2015 11:12 AM
To: Levantovsky, Vladimir; Ken Lunde; mpeg-OTspec at yahoogroups.com; Behdad Esfahbod (behdad at google.com)
Cc: Karsten Luecke (karsten.luecke at kltf.de); Rob McKaughan; Eric Muller
Subject: Re: [mpeg-OTspec] Draft amendment of ISO/IEC 14496-22 OFF (3rd edition)

+ Rob McKaughan, Eric Muller


Vlad wrote:

> When I mentioned 'name' table as a unique identifier I didn't specifically consider "font name" to be the one, but rather a collection of Name IDs. Your comment about optical size reference being the only differentiator in a font collection is valid and relevant and it actually brings back the question that was once posed on this list a couple of months ago when Karsten Luecke (https://groups.yahoo.com/neo/groups/mpeg-OTspec/conversations/messages/1281) proposed to introduce new Name IDs for size-aware font definitions. That discussion didn’t yield an agreement, but since this same question was raised more than once by now I am wondering if we can actually get to a consensus decision on this in time for this amendment to be started.

It's possible, if all one wants is a quick solution to a particular identifier issue. This was also discussed during the ad hoc layout engine meeting in Seattle last April. But I'm not happy with the practice by which the name table is increasingly bloated by adding new IDs every time someone wants to address font data in some new way. The existing name IDs are already confusing to both the font makers who have to set them and the software makers to have to figure out which ID to use for a given purpose. As a result there are lots of fonts out there with dodgy name table entries, and examples of software makers relying on inappropriate name IDs for particular purposes.

Rob and I independently came up with models for font attribute data, which would not only be a means to provide software makers with unambiguous means to address fonts in a variety of ways (with side benefits such as enabling users to customise naming and sorting options in font menus), but also to automatically generate clean legacy naming for existing name table IDs.

So while it might be possible to squeeze name table Size ID strings into this OFF spec amendment, I'd rather take the time to think about something better and future-oriented.


JH



-- 

John Hudson
Tiro Typeworks Ltd    www.tiro.com
Salish Sea, BC        tiro at tiro.com

Getting Spiekermann to not like Helvetica is like training a cat to stay out of water. But I'm impressed that people know who to ask when they want to ask someone to not like Helvetica. That's progress. -- David Berlow