This is fantastic! I will add it to the epar spec., thanks.

Does anyone know if and video formats allow font embedding or linking?

Cheers!

If the text isn't in the HTML at all, then the image-centric nature of it cripples accessibility.

>Does anyone know if and video formats allow font embedding or linking?

Yes, that the need for font embedding, streaming and compression in video is the primary reason the OpenType spec ended up being standardized by the ISO MPEG group.

I remember that now! So, are we going to have a OpenType for a web standard then?

Cheers!

For anyone who cares. Seems as if the format is being opened up - http://www.engadget.com/2009/10/13/apple-says-itunes-lps-dont-cost-label... - looks like everyone's EULAs will need to rev'd to allow or deny iTunes iLP iEmbedding ;-)

>Seems as if the format is being opened up

And here it is...

http://www.apple.com/itunes/lp-and-extras/

right now the whole LP thing is lame.

From Apple's "Design Best Practices" document:

      Fonts and Scrollbars

      •  Don’t use Open Type. When using fonts, use SVG fonts, which
      are small, render quickly, and scale better. The fonts to be turned
      into SVG fonts need to be legally cleared for use within the iTunes
      LP or iTunes Extras, and should be distributed in the package as an
      SVG font to restrict consumer usage of the font.

      However, it is often better to use images rather than SVG fonts.
      See the next two suggestions.

      •  Use buttons instead of live text for menus. Use images for menu
      buttons, instead of an SVG font. This has a couple of advantages:

      » Rendering is the same on all platforms (Mac, Windows, Apple TV).
      » You have more control over spacing of text since you can use kerning
      and other ways to make the text smaller or bigger, depending on how
      much space the design allows.
      » No potential fonts rights issue.

      •  Use a JPEG for large blocks of text. Instead of using live text from a
      font for a song list or lyrics, make the list or lyrics an image.

      You have more control over sizing and spacing, which can be useful on
      lyrics pages where space is limited or for long, one-line lyrics that
      might not fit.

      JPEGs are smaller than fonts and compressed, so one small image gets
      loaded into memory instead of larger-sized font elements.

      By putting lyrics in an image, the text can’t be copied and pasted (legal
      considerations).

      Rendering is the same on all platforms.

      No fonts rights issue (if there ever would be one).

"Use a JPEG for large blocks of text"

Seems like a big step backwards.

So far I’ve only seen one iTunes LP, and the booklet was a PDF. Seemed like a much more sensible solution than all this HTML and rasterization stuff.

Kent, thanks for digging through the documents. Interesting that they suggest avoid using real fonts due to rendering issues, including cross-platform issues. Parallels to the Web, and other open systems where font rendering is left to the viewing app.

> they suggest avoid using real fonts due to rendering issues, including cross-platform issues

Yes, and that if fonts are to be used, they suggest SVG. (Is there an actual SVG *font* format?) Why is it SVG can be made to render consistently, but CFF/TTF fonts can't?

> Why is it SVG can be made to render consistently, but CFF/TTF fonts can’t?

CFF/TTF fonts do render consistently (and well enough), if they are used large enough.
And my guess is that SVG fonts, (an actual web font format), will not render consistently, (or well enough) if scaled small enough.
Though this is pretty simple, it ain't been edyoukaded yet.

Cheers!