Re: WebOTF Proposal

I'm still left wondering why WebOTF can't be
improved with a simple tweak:

1) Make the directory the same format as
   OTF
2) Eliminate the alignment requirement (table padding)
3) Restore DSIG - it should apply to the classic-OTF
   part of the directory and tables.
4) Compress the whole file in discrete chunks and
   add a separate directory for those

That gets you WebOTF as the concatenation of three
files, plus an optional compression step.  The
compression step and separate directory for random
access is a generic mechanism, even if only fonts
happen to implement it.

It's unfortunate, and I'm still stunned and sad
that gzip and bzip2 never got around to it, that
generic whole-file compression doesn't already
have that indexing feature but there is no reason
to make the problem worse!

Skepticism about the importance and utility 
of the divergence from OTF and media-specific 
compression-scheme is also then "not an issue".

-t



On Thu, 2009-08-06 at 17:51 -0700, Thomas Lord wrote:
> On Fri, 2009-08-07 at 11:32 +1200, Robert O'Callahan wrote:
> > On Fri, Aug 7, 2009 at 11:27 AM, Thomas Lord <lord@emf.net> wrote:
> >         I am curious if you considered a particular
> >         alternative to table compression. Namely:
> >         
> >         Whole file compression is not incompatible with
> >         a degree of random access to a file.  bzip2
> >         and gzip offer support for this.
> > 
> > AFAIK you can only do this by doing Z_FULL_FLUSH periodically *and*
> > storing offsets into the compressed data in an auxiliary table. That
> > is not very different, or much less work, than what ZOT does.
> > 
> > Did you have something else in mind?
> 
> Your question startled me ("why is he asking that?!?")
> because I had the (apparently quite mistaken) impression
> that both gzip and bzip2 had options to build 
> chunk index tables.   I'm quite amazed that they don't
> although while looking for them I did find an (old!)
> developer note for one of the programs that said,
> essentially, "Yeah, we should get around to doing that."
> 
> You answered my question.  Thanks.
> 
> Systems programming is dead, long live systems programming,
> -t
> 
> 
> 
> 
> 
>

Received on Friday, 7 August 2009 01:26:55 UTC