On Mon, 16 Dec 2013 13:52:55 -0600
"Darrell Anderson" <darrella@...> wrote:

> >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?

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.

> >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. :-)

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. :-/

> >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.

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