On 5/21/2010 1:40 PM, Louis Simard wrote:
Err... While I know what you want me to do (you want
Content-Disposition: inline), I don't know how to do that in the Gmail
web interface. Perhaps I'll set up Mozilla Thunderbird, if it can do
that :-)
Heh, yea, I've struggled with this on thunderbird too, which is why I
usually end up submitting patches via something like mime-construct or
some other command line mime editor where I can force it to use
Content-Disposition: inline.
- For PNG: the data used to store some images on the CD is not
compressed to the highest level. OptiPNG takes those files and tries
to recompress them to the highest level, while ensuring that every
pixel's color value ends up being the same.
I believe that PNG applies a lossey compression first, then gzips the
result. It sounds like you are saying that the gzip is done with -3
instead of -9, so you ungzip it and recompress on -9. Is that more or
less correct? If so that sounds pretty good, but like you mentioned
before, should be done upstream rather than only for the livecd.
- For SVG: the data used to store ALL images on the CD is not optimal
for rendering purposes. Inkscape metadata, Sodipodi metadata, ID names
for elements that end up unused, gradients defined dozens of times,
etc., are bloating the files. Scour.py takes those files and removes
this bloat, while ensuring that the new versions render identically to
the original. However, since Inkscape's metadata ends up removed, it
could be more difficult for users to open these new files in Inkscape.
Sounds good, and also would be good to do upstream instead of just for
the lived.
- For XML, as described by Martin Owens: xmllint would remove
everything superfluous from all files on the CD, while ensuring that
the data is parsed identically. I haven't tested this yet except on
one file from the CD (squashfs -
/var/lib/gconf/defaults/%gconf-tree.xml), but that file went from
2,095,034 bytes to 1,779,376 (a savings of 315,658). There's more hope
yet.
I noticed the bloated gconf xml files a few years back myself and
brought it up on the devel list. IIRC I saw even more wasted space than
you mention here, due to 10, 20, even 30 characters of whitespace
indenting each line. This does add a lot of bloat to the files I don't
like to have on an installed system, but once compressed into the
squashfs for the livecd, the whitespace drops out, so there wasn't much
concern about it. At one point I tried just converting the whitespace
into hard tabs and saved quite a bit of space, while preserving the
indentation for human editing.
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
