On 10/14/05, bulia byak <buliabyak@...400...> wrote:
On 10/14/05, jiho <jo.irisson@...400...> wrote:
The problem is with the file. It has:
<image id="image3264" ...
which is a (missing) image whose transform= stretches it to insanely huge size. So from Inkscape viewpoint, the entire drawing includes this as well, which is why it zooms out trying to fit it in.
So the real bug is in how this bogus transform came to be. If you can reproduce the editing operations that resulted in it, we would be able to fix that.
I agree that Inkscape should not emit bounding boxes with bogus transform matrices, (and this is a defect which should be identified and fixed), but I think that this report is partly an acknowledgement/heads up that such files might exist in the wild, and if they meet the SVG specification should be at least importable and viewable by Inkscape and it may be about two or three other possible/actual defects:
1. Missing images should not be selectable and/or 2. The bounding box of a missing image should be ignored and/or 3. Zoom to selection should only respect visible objects and/or 4. Zoom to selection should ignore bitmaps
I suspect that if (1) or (2) were put in, then there would be other breakage, (when compiled for debugging there might be warning on absurdly large bounding boxes) and I wonder about (3) is it too close to magic or DWIM? (4) is probably not a good idea.
Personally I would be happy to have (3) in, especially if there were also a means to 'zoom to page' and 'zoom to all' (Freehand does this, though 'zoom to all' IMHO misbehaves in single page documents), for the benefit of people who really do want a vector graphic of some monstrous freak of nature.
It can be useful to have zoom to fit all really mean all, as this is a good way to identify and remove spurious curves and points.
I am not sure that this is needed for 0.43 (and I am not sure that it would be accepted, of course), but if someone could point me to the relevant file, I will submit a patch.
Ben