16 Dec
2013
16 Dec
'13
5:40 p.m.
On Mon, 16 Dec 2013 13:52:55 -0600
"Darrell Anderson" <darrella(a)hushmail.com> wrote:
Unfortunately no--I'll just say "personal issues" and leave it at that.
I think a large part of the problem is that whoever drew the bloody
things was treating them like logos and not icons. There's detail in
all of them that's just going to be lost at typical icon display sizes
of no more than 128 x 128px, and so ends up being more purposeless
file bloat. I'm not even 100% certain that cutting the clipping, masking,
etc. would shrink the files, although it would make the display
process less complex, and therefore likely faster.
Probably a good place to start. If KDE4 displays them at a
decent speed on the same hardware, dissect KDE4, since its
structure is still going to be somewhat more like Trinity's than
Gnome.
Another possibility would be to do some sort of prerender-and-
cache-as-raster, although that's probably adding needless complexity
to the system.
Or we can just hack the Kicker code to discard all libreoffice*.svg
files and drop to the raster versions--crude, but doesn't require
cooperation from anyone else. We then ship a prerendered set
of PNGs matching what LibreOffice was using at the time of
release, and call it good . . . and hope that no one else decides
ridiculously oversized icons are a good idea. :-/
Not that difficult to overcome--list the directory and apply a regex
to get a list of matching files for each icon, then overwrite or delete
as appropriate. <20 lines of Perl, and presumably possible in Bash.
The tricky part is to get it set up to run as a postinstallation hook
for LibreOffice.
I don't think they're likely to change the icon set with every update
to LO, so we can just check and update whenever *we* make a
new release. Only a few people are likely to notice or care (unless
this also affects another DE's default icon set).
E. Liddell
The problem is
just that they're very large and complex files,
from
the looks of it. Lots of shapes, lots of gradients, lots of
(unnecessary,
IMNSHO) clipping and masking. The SVG icon files that ship with
Trinity are mostly ten percent or less of that size, and much less
complex. Even in Inkscape on my quad-core, the LO files take
several seconds longer to load than, say, the old
crsc-app-openoffice.svgz icon that ships with our Crystal theme.
The optimum solution would be to clonk whoever created the files
over the head with a blunt object and get them to redo them as
straightforward stacks of shapes and gradients without all the
unnecessary file-bloating crap.
With your understanding of svg file formats, do you feel
comfortable contacting the LO team and ask them to consider
releasing palatable icons? The code to
look at in TDE is
the stuff related to clipping, masking, and cloning in SVGs, but
it
may never be possible to make these files open acceptably fast on
a slow machine. They're just not made with that in mind.
This likely is the best solution. Use more recent svg algorithms
that do not suffer the same rendering problems. What algorithms are
being used in other desktops? --- Take advantage of GPL code
sharing practices. :-) The only
workaround that occurs to me at this time is overwriting
the files with something simpler after LO is installed, or else
deleting the SVGs outright and (hopefully) forcing the system to
fall back on the raster versions of the icons.
A challenge to that idea is the LO devs name the icons with the LO
release number in the file name. Maintaining our own png icon set
would be overwhelming because with each LO release a new Trinity
icon set is needed. Not to mention all past LO icons sets as well
because they have included the release number in the file names for
a long time now.