The tiger renders correct in ksvg, it's just the origin that is off a little bit. I've moved a bit around in inkscape, but I would not replace the original - it is much cleaner code :-)

The second image rendes korrect on my ksvg from rde 3.5.13 and inkscape.

Yes, both render okay here in the ksvg preview plugin. That 'identify' did not like either is why I listed both. The tdesvn svg image stalled identify forever, so something likely was not proper.

E. Liddell found the problem with why identify did not like tiger.svg. :-)

Darrell

...

...

tdegraphics/ksvg/test/tiger.svg

This file appears to have been written by hand rather than saved by a vector editor and may be unidentifiable as SVG to some renderers, as it lacks a namespace statement or any linked DTDs or schemas. If tiger2.svg was not also flagged, that is almost certainly the problem. Open tiger.svg in a text editor, change the <svg> at the very beginning of the file to <svg xmlns="http://www.w3.org/2000/svg"> , and see if Imagemagick accepts it then. If it doesn't, I would suggest deleting the file, as it's really the same image as tiger2 (the latter has been translated down and right so that the entire tiger head falls within the canvas, but that's the only material difference as far as I can tell).

Editing the file did the trick for identify. No complaints. :-)

That the tiger.svg image appears cut-off, as compared to tiger2.svg, probably is not a big deal, although to me, a tad odd.

I notice that none of the images become part of the final tdegraphics package. Thus, in hindsight (I hate hindsight :-)), that image probably was not a big deal. Still, a nice feeling that our files are not corrupt and viewable. :-)

I saved the edited tiger.svg pushed to GIT. Good enough. :-)

applications/tdesvn/src/pics/hisc-action-tdesvnaddrecursive.svgz

Re-saved this one for you. If that doesn't help, I suspect the problem is either whatever spammed the Adobe namespace into the file, or the use of some fancy features (chained clones) and/or the over 600 individual shapes the file contains (that text on the "document" pages?

Thanks for resaving. Strangely, identify still hangs with the resaved file too. I have no idea why that one file causes identify to hang. I waited at several minutes and the command prompt never reappeared in konsole. This is the only compressed svg in the entire source tree that does this.

It's actual text, rendered as shapes, although I'm not sure I even want to know why the original artist had a Spanish-language document on the Atkins diet handy, or why they chose to C&P that instead of something remotely relevant like the text of the GPL . . .)

Yeah, now that I enlarge the image, kind of funny. What was up with that, I wonder? :-)

Anyway, the visual I get from Inkscape matches hi64-action-tdesvnaddrecursive.png, so it's probably correct.

If this doesn't fix it, best thing to do is probably replace the text with horizontal grey bars (it can't be read at icon-size anyway). And not use clones.

Would you do that please? Or convert the text to "greek" text? Whichever is easiest!

Now that I ask that, I see two other svgz images have that same Atkins diet text. Those also probably should get converted to gray bars or "greek" text:

hisc-action-tdesvndelete.svgz hisc-action-tdesvnadd.svgz

BTW, I just discovered a command line utility named ksvgtopng. Packaged as part of tdelibs. Works really slick. If you fix those three svgz files, I can update the associated png files quite easily. :-)

With respect to the remaining png files in my original list, I think they all are hopeless. No original upstream sources and nothing will allow even partial viewing. We have no clue what the images should look like.

Darrell

I have no idea why that would have happened--I glanced at the XML, and as far as I could tell, there was nothing syntactically wrong with the file, it was just bloated with invisible text.

(I do have bigger SVG files on hand, but none of them were intended to be icons...)

The identify command does not like the latest version either. I now suspect a bug with the imagemagick algorithms rather than the file. The file opens fine in gwenview and ksvg plugin viewer. Let's shrug about identify and move on.

And was it something that he owned/had permission to use, or was kdesvn shipping with a bizarre hidden copyright violation for however many years?

I wondered about that too.

...

Now that I ask that, I see two other svgz images have

that same Atkins diet text. Those also probably should get converted to gray bars or "greek" text:

...

hisc-action-tdesvndelete.svgz hisc-action-tdesvnadd.svgz

Please see if the attached file works as needed/intended. If it does, I'll tackle the others.

The image looks great with the gray lines. :-)

I will recreate the pngs from that file and await your wondrous talents with the other two.

So we either draw new ones or replace them with reasonably generic icons from among those already on-hand. Or, if they're never actually displayed anywhere, delete them from the tree, just to be tidy.

I'm a tad embarrassed to say that the png files in tdesdk are not corrupt. Yet the short story is a good chuckle.

Yesterday I could not figure out why the files were corrupt all the way back to KDE 3.0 or something like that. Today I wondered whether I could use the same images from KDE4. The KDE4 images looked fine and they had similar file names as those in Trinity/KDE3.

As I stared at the directory file listing in konqueror, I (finally) noticed the file size of these allegedly corrupt png file: 171 B. Yes, bytes. Every single one, despite the file names implying different icon sizes. I'm a tad slow on some days so I decide to open one them with khexedit.

The allegedly corrupt png files are shells scripts. :-)

When I looked at the code in a text editor, I saw what was happening. The build process grabs copies of png images from elsewhere in the tdesdk sources to build image files. Those image files are not corrupt.

I feel a bit silly about that, but then again not --- why name a shell script with a png extension? Developers can be so freakin' off planet in some things they do.

Anyway, that reduces the original list of remaining corrupt images to the six files in pytdeextensions. All of them produce the same error message from identify: 'improper image header'. Looking at the file sizes indicates only two need to be replaced and the other four are copies of the same. Yes --- I checked the files --- they are not shell scripts. :-)

Darrell