Qt SVG renderer

[James Richard Tyrer]

Matthew Woehlke wrote:
> James Richard Tyrer wrote:
>> Matthew Woehlke wrote:
>>> What exactly is the difference between the version you attached 
>>> and the one in svn? All I can tell from a cursory inspection is 
>>> that you ungrouped some objects. While this may reduce the file 
>>> size (and
> could
>>> be considered cruft), it is NOT a collection of additional stray 
>>> elements (i.e. entire unrelated icons) that I was calling "junk".
>>> 
>>> 
>>> I disagree with you disagreeing.
>> I would have thought that a file of less than half the size with 
>> the *exact* same result would be QED to the question of whether 
>> there was junk in the file without any explanation.
> 
> "junk" = things that cause incorrect rendering "cruft" = things that 
> make the file bigger without affecting the rendering
> 
> I was talking about the former, not the latter.

And I am not making this distinction because I do not know if the stuff
I removed from the file was "junk" or "cruft", only that it was not
necessary to the correct rendering.

> Please re-read my previous statement. And you still haven't (in this 
> bit of the thread, anyway) explained *how* you got the difference in 
> file size, which would have been much more useful than making 
> everyone guess.

I am not keeping the differences secret.  Anyone can gunzip both files
and look for themselves.

> (I don't want to get into a terminology fight; the point is you
> ignored me the first time I tried to explain that we're talking about
> different things.)

I do not know if that is the case.  I do not know exactly why the files 
don't render correctly.  Only that they have a lot of extra stuff in 
them.  I do not know if this is the cause or not.  I do know that there 
is no need for it.

> ...and this thread is getting off topic. If you want to discuss 
> reducing the size of our .svg[z]'s, please take it to kde-artists.

And you really think that *the* artist will listen?

>> I did not make a study to see how of these 6154 bytes much were 
>> unneeded definitions, how much was meta data, and how much was 
>> excessive grouping.  But, it should be clear to anyone that if the
>>  file can be cut in half without any effect on the image that there
>>  was junk in the file, which was my point.
<SNIP>
>> I also had to rearrange the definitions with a text editor, but 
>> this had no  significant effect on the file size (actually, it 
>> added a few bytes).
> 
> I'm curious why you should feel the need to rearrange the file...
> 
I can only presume that you did not gunzip the two files.  Something 
that I suggest that you do.  The reason is that an SVG file is supposed 
to have a block:

<defs>

</defs>

containing all of the definitions which this file didn't.

So, I took my own advice and I find that we are probably both wrong here 
because this is a bad example: it is an AI generated file.  The large 
difference in the file size is due to the removal of the Adobe metadata 
block.

I should have realized that this was an AI file because it contained XML 
that InkScape didn't read (displayed as blank lines in the <XML> window).

So, in this case, removing the "metadata" block with a text editor, and 
opening the resulting file in InkScape, deleting all of the XML lines 
that InkScape displayed as blank, and saving as an InkScape SVGZ file 
results in the 5,655 byte file which is attached.  But, this doesn't fix 
the <defs> issue.

Wondering about this I looked at other files which I had worked on. 
Perhaps a better example is: "view-close.svgz".  This file is 11,332 
bytes in TRUNK SVN.  Doing "Vacuum Defs" (which removed > 300 unused 
defs) gets it down to 5849 bytes.  But there is still a lot of unneeded 
stuff in the file.  Removal of this stuff which may, or may not be, 
"junk", and still saving with the InkScape metadata, gets the file size 
down to 3394 bytes [attached].

Clearly, even if it is OT, bloated SVGZ files are an issue that needs to 
be addressed.  Was any of this extra stuff related to the rendering 
issue?  Will someone please test it and see?

-- 
JRT
-------------- next part --------------
A non-text attachment was scrubbed...
Name: media-flash-memory-stick.svgz
Type: application/octet-stream
Size: 5655 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080806/8e8af7d9/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: view-close.svgz
Type: application/octet-stream
Size: 3394 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080806/8e8af7d9/attachment-0001.obj>