revision 12945 broke image import

[David Mathog]

Revision 12945 broke image import.

Both indirectly (as read from an EMF file, which is where I first saw it) or directly from a png file.

Try to import any image and all that shows up as a "linked image not found" image. Look at the SVG and the target PNG is nowhere to be found. To test:

start inkscape
file->open
select a png image (embedded)

result: as just described.

Bad bad bad bad bad bad.

Please roll this back asap!!!

[su_v (suv-lp)]

See also duplicate report bug #1270335 (AFAICT the regression was introduced in rev 12942).

[su_v (suv-lp)]

@Martin - could you please revisit the recent changes wrt to the <image> element which likely trigger this regression?

[Martin Owens (doctormo)]

Thanks for finding this clanger suv, totally missed that call name and assuming they were all the same call caused the issue. Please see r12954 for the fix to the embedded image issue.

[su_v (suv-lp)]

Actually David discovered it first… ;) Thx for the quick fix!

@Martin - any idea about the change of format I mentioned in my duplicate report (bug #1270335)? The XML Editor no longer displays the name 'xlink:href' in the attributes list for a selected embedded image…

[Martin Owens (doctormo)]

I saw the attribute name was further down in the list. I wonder if the text in that box is super big would it break the gtk list.

[su_v (suv-lp)]

> I saw the attribute name was further down in the list.

Confirmed - the attribute name is centered (vertically) in the cell. Hard to find with larger embedded images… maybe the text (attribute name) could be aligned to the top of the cell?

> I wonder if the text in that box is super big would it break the gtk list.

No idea - what I do recall is a rather huge performance hit in trunk's dockable XML Editor with large embedded images which had been created with stable or earlier trunk revisions (all image data is on a single line; may also hit recent libxml2 limit, bug #1243011). The new format created with rev >= 12938 (image data split on multiple lines) seems to avoid or reduce that performance issue.

[su_v (suv-lp)]

> any idea about the change of format I mentioned in my duplicate report

Nevermind - I didn't test carefully: the format appears to change once an image is reloaded from disk (from multi-line image data block to a single long line), and happens with older and latest revision. Sorry for the noise.

[su_v (suv-lp)]

@Martin - the fix in revision 12954 introduces a new regression (crash on load if linked bitmap images are missing, bug #1273244). The issue currently can't be further investigated because of the later regression (bug #1272649).

[Martin Owens (doctormo)]

Understood. Please bare with me while I refactor the code, there's more changes in the pipe.