Re: EOT & DMCA concerns

On Wed, Aug 5, 2009 at 1:29 AM, Jonathan Kew<jonathan@jfkew.plus.com> wrote:
> On 5 Aug 2009, at 02:18, Sylvain Galineau wrote:
>
>>> Others seem to view EOT-Lite as a stepping stone format that would be
>>> followed by a better .webfont/ZOT/something-else format.  But another
>>> new format would need to offer a big marginal advantage to offset the
>>> disruption supporting yet another format would cause.
>>
>> I lean towards being one of them. What kind of specific disruption(s) are
>> we
>> Talking about though ?
>
> One concern I have is that if we all implement EOT-Lite (by whatever name)
> now, it will be more difficult for a new and better format to gain
> acceptance, and so we may end up with an inferior format in the long term
> for the sake of short-term gain. If we introduce a format such as
> .webfont/.zot/etc at this point, there's a strong incentive for everyone to
> get on board; this will be reduced if there's EOTL as an available,
> interoperable solution even if it is technically less optimal.

This argument is theoretically sound, but I would prefer to see
something more concrete. In particular,
(a) what features do we think are missing from EOTL that we'd like,
(b) can we implement them compatibly
inside EOTL somehow? (c) is there something other than (a) and (b)
that causes us to not like EOTL?

The only real features I've heard suggested are compression and
subsetting, and better metadata support.
I haven't thought about this at all, but given that EOT had MTX
support, I would assume we could also add
it to EOTL compatibly, no? If not, you can certainly compress the
whole file using whatever algorithm you
like, just like we do with gzip/deflat today. Subsetting can happen at
the OTF level, right, so that can also be done?

That leaves metadata support. I haven't heard anything that says that
the desired metadata fields can't be put
directly into the OTF/TTF files. Am I mistaken? It seems like since
OTF already has extensibility mechanisms,
we should just be using those, rather than trying to recreate them in
a different layer/wrapper. But perhaps
implementors would object because they'd have to parse the OTF format
rather than just handing it to the O/S
to render.

That would seem to leave us with some objection to the wire format
(not XML, not MIME, not .ZIP, whatever).
Frankly, I don't care much about that at all when traded off against
simplicity of implementation and compatibility
gains. It's not like OTF/TTF are human-parsable either, and it's not
like SVG has gained widespread adoption because
it is ...

Are there other concerns?

Again, I am not necessarily voting in favor of EOTL, just trying to
understand what the "newer, better" format would
really offer that couldn't be achieved.

-- Dirk

Received on Wednesday, 5 August 2009 19:21:03 UTC