On Sat, Dec 21, 2002 at 10:51:42PM +1030, Darren Freeman spake thusly: ... > But as for eliminating symbols altogether by more intelligent use of > defaults, I'd say: go for it! That will shave off some data. > > But before making the statement definitive, I had another go. I removed > what I thought looked like redundant info, from the already smaller > file. I only touched the tables. I shaved off a further 2.3 kB. But upon > compressing it, I actually added 26 bytes. I have no definitive > explanation for why, but gzip obviously couldn't take advantage of > patterns that were present before. I find this a bit surprising. Especially if it would be typical, which I have difficulty believing.
> So in this very simple example, there was hardly any gain in the > compressed file despite putting in work to shave off up to 5 kB from the > original. It would be very handy if the person coding file I/O could > come up with some real tests on publically available documents to show > how big a saving is to be had by reducing the bloat, if it's going to be > compressed anyway. > Have fun, > Darren As I see it, the default values should be the column values for align, leftline and rightline, and the row values for valign, topline and bottomline (the latter is apparently not done, or at least no advantage taken of it IIUC). It would require some coding I suppose, but that alone would eliminate most of these attributes from the cells. For width and usebox, the defaults should clearly be 0pt and none. And I agree that abbreviating the attribute names and values is not a good idea after all. And the metric we should use for success is what it does to the *uncompressed* file. IMHO. ... Martin
msg50319/pgp00000.pgp
Description: PGP signature
