Re: One font embedding idea

> If one wants to send  t e x t  l i k e  t h i s, 
> glyphs for "t h" can be generated and such.

But you have no idea where the line breaks are until the document is
formatted on the user's scren.  It depends on the window size in pixels.
So you can't really include spaces unbless they are no-break nonpaddable
spaces.  Well, most HTML browsers right now can't even do full left &right
justification (or quadding, call it what you will), but I am sure they
will do so before long.  Actually MSIE probably does already, now they
have style sheets, but I haven't checked.

I really don't think this approach is worth it.

The bandwidth used by the Web is already large, and if it takes even longer
to download a page than now, embedded fonts won't get very far.  That's a
bit of a dangerous argument, since inline images became popular awfully
quickly in 1993/4 despite complaints of modem users.  But I still don't think
there's any reason to be this extreme.

It also doesn't help.  There is a trivial algorithm to undo it.
If you have bitmaps for [hi] and for [i], you can subtract the [i] bitmap
from the right hand edge of the [hi] bitmap.  If you have several letter pairs,
you can also recover the kerning pairs this way.
If you have [hi] and [in], you can overlap them until the first set bit in
each column in [in], counting from the left, exactly corresponds to the
last unset bit in [hi]; at that point, you have a bitmap for [hin], and can
now invert the [in] bitmap to erase all of the [i] pixels.

Any competent C programmer can do that in under a day.

If they are outlines instead, it's even eaier.

Scrambled encodings with a clear document actually have a similar problem,
but don't waste bandwidth, so I suggested it as a simple step so that the
outline font on its way to the printer can't usefully be reused directly.
Of course, the font should have a normal encoding vector, so it's really
scrambled character definitions.

Neither proposal is sufficient to protect fonts over the web, though.

Lee

Received on Tuesday, 13 August 1996 10:53:20 UTC