Re: WOFF and extended metadata

On Jun 9, 2010, at 2:45 AM, Sylvain Galineau wrote:

> I have asked for examples of usage of this format with real fonts.
> Nothing. All I get is assertions that it exists and it might therefore
> not be worth anyone's time to provide me with that data.

I can't give you data that I don't have or don't have the rights to distribute. I can give you notes about my real world experience on this: I have had foundries come to me and tell me that they are shipping/going to ship WOFF. I have been asked to test the validity of WOFFs. I can say that each of these fonts had metadata that followed the structure defined in the spec. They did not all have all of the elements. Only one of them did not adhere precisely to the metadata spec. This was a mistake and the, as yet unreleased, font was subsequently revised to bring it into compliance. I can't turn over files, information or the contents of private discussions. I'm more than happy to make test cases that echo what I have seen in practice. I haven't done so because we don't seem to be at that point yet. If you need to see some shipping files, you should contact some foundries directly.

I don't know if this would help or not, but here are the elements in the main spec, notes about why we included them and an example from one of my own fonts:

uniqueid
This grew out of my work on the technical side of font production. Often times, we revise fonts, make particular versions for specific clients, etc. We need to be able to tag these for many reasons. Unique IDs have existed in other formats. Type 1 has an integer. OpenType has a string in the name table.

	<uniqueid id="com.typesupply.torque.bold.1.0" />

vendor
This is the name and the URL of the vendor of the font. The OpenType name table has a similar field.

	<vendor name="Type Supply" url="http://typesupply.com" />

credits/credit
This is a list of credits for the font—designer, etc. OpenType has a "designer" field in the name table. This has proven to be insufficient as fonts have grown in scope. Often, there is an art director, more than one designer for each script, a hinter and more. This was also inspired by libre font communities where more than one person works on the same font.

	<credits>
		<credit name="Tal Leming" url="http://talleming.com" role="Designer" />
	</credits>

description
This is a description of the font. The OpenType name table has a similar field.

	<description>
		<text lang="en">
			Torque began its life as an amalgamation of an American
			athletic lettering style and classic “space” lettering styles.
			...more text...
		</text>
	</description>

license
This is the license text and url. The OpenType name table has similar fields.

	<license url="http://typesupply.com/license" id="typesupply-woff-1.0">
		<text lang="en">
			Type Supply LLC
			WOFF Font Software End User License Agreement
			...more text...
		</text>
	</license>

copyright
This is the copyright for the font. Type 1 and the OpenType name table have similar fields.

	<copyright>
		<text lang="en">Copyright 2009 Type Supply LLC. All rights reserved.</text>
	</copyright>

trademark
This is the trademark for the font. The OpenType name table has a similar field. I think Type 1 does too, but I haven't looked at that spec in a long time.

	<trademark>
		<text lang="en">Torque is a trademark of Type Supply LLC..</text>
	</trademark >

licensee
A string representing the licensee of this particular copy of the font. I won't say more than that because it brings back bad memories. :-)

	<licensee name="...as needed..." />

I haven't localized any of my strings because I haven't needed to at this point. (And, I don't have the funds to hire a bunch of translators right now.) However, I have seen OTFs that do have localized information.

Do any of these seem unnecessary to you?

Regarding the extension block: I haven't defended its existence because it wasn't my invention. All I did was try to bring it in line with the rest of the spec. I can't give you specific examples of what the extension block will be used for, but I can come up with some hypothetical examples off the top of my head:
- Legal statements required in the future that are not of the license, copyright, trademark variety.
- Parametric font description data.
- Client specific data.
- The EPAR/EEULAA info that has been kicked around for years.

Maybe some of the other font vendors here can add some of their own ideas to this list.

Tal

Received on Wednesday, 9 June 2010 14:23:14 UTC