W3C home > Mailing lists > Public > www-font@w3.org > July to September 2009

Re: A way forward

From: Robert O'Callahan <robert@ocallahan.org>
Date: Sat, 25 Jul 2009 10:19:27 +1200
Message-ID: <11e306600907241519t73758eabj2ae7ff4ea91ff518@mail.gmail.com>
To: Sylvain Galineau <sylvaing@microsoft.com>
Cc: www-font <www-font@w3.org>
On Sat, Jul 25, 2009 at 10:00 AM, Sylvain Galineau

>    On Sat, Jul 25, 2009 at 6:41 AM, Sylvain Galineau <
> sylvaing@microsoft.com> wrote:
> To make sure we are on the same page, EOT-Lite means:
> 1. Raw font files are prefixed with a well-known binary header;
> 2. The user agent reads the parts of the header necessary to:
>        a. Determine its length;
>        b. Verify its validity e.g. ensure the rootstring field is null;
> 3. The user agent then proceeds to skip this header and treat the remainder
> of the resource as
> it would a reference to its raw equivalent.
> Is "XOR encryption" permitted by EOT-Lite? Because Ascender's
> just-announced "EOT Lite Wrap Tool" optionally applies "XOR encryption", and
> presumably authors will expect the results to still be "EOT Lite".
>  It seems to be the case in Ascender’s initial iteration. Can you
> elaborate on the concern ? I’m not attached to it, personally.

I'm just trying to identify precisely what EOT-Lite is. There seems to be
some confusion among its proponents. You've been telling us all we have to
do to process EOT-lite is check and skip some header bytes, Ascender says we
may have to XOR the payload as well.

"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
Received on Friday, 24 July 2009 22:20:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:32 UTC