Hi list,
this file http://jo.irisson.free.fr/dropbox/schema_bilan.svg was completely made in inkscape with version 42-2-2 on mac os X. Then it was edited with latest CVS on linux and after that: - zooming to fit content in window zooms out to 1% - selecting all and zooming to selection produces the same result both on stable or latest cvs inkscape on os x or linux.
(NB: the same problem was also remarked in other files, converted from eps to svg with pstoedit such as this one: http://jo.irisson.free.fr/dropbox/sampling.svg it might be that the eps was corrupted in the first place or that pstoedit job wasn't perfect because there are other problems with this file: any new path/tex created is huge, no dashes can be applied to some imported path or to any new path created etc. But I mentioned it in case the zooming problem is the same.
Nevertheless, the point is that previous file (schema_bilan.svg) was entirely made in inkscape so there is no incriminating pstoedit or the software which produced the eps in previous case.)
in addition, the first file (schema_bilan.svg) does not display properly on os x (stable or cvs) anymore: all shapes are there (selectable), their fill and stroke attributes are still correct but they are not displayed.
I know that the zoom has been changed a bit lately. might it be related to this? I submitted a bug to the tracker: [ 1326574 ] maximum zoom out when zooming to fit in window I hope this will be easy to fix. I am naturally ready to test anything you'll need.
JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/
On 10/14/05, jiho <jo.irisson@...400...> wrote:
Hi list,
this file http://jo.irisson.free.fr/dropbox/schema_bilan.svg was completely made in inkscape with version 42-2-2 on mac os X. Then it was edited with latest CVS on linux and after that:
- zooming to fit content in window zooms out to 1%
- selecting all and zooming to selection produces the same result
both on stable or latest cvs inkscape on os x or linux.
The problem is with the file. It has:
<image id="image3264" transform="matrix(-8.000000e15,0.000000,0.000000,-8.000000e15,1.000000e18,1.000000e18)" height="250.00000" width="250.00000" sodipodi:absref="/Volumes/files/work/enseignement/lpd_perpi/figures/synth_prot/schema_bilan.svg-text326 xlink:href="schema_bilan.svg-text3260-4294966489.png" />
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.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 10/14/05, bulia byak <buliabyak@...400...> wrote:
<image id="image3264" transform="matrix(-8.000000e15,0.000000,0.000000,-8.000000e15,1.000000e18,1.000000e18)" height="250.00000" width="250.00000" sodipodi:absref="/Volumes/files/work/enseignement/lpd_perpi/figures/synth_prot/schema_bilan.svg-text326 xlink:href="schema_bilan.svg-text3260-4294966489.png" />
Judging by the name of the png file, it was created by Inkscape itself by "Create bitmap copy" command. Perhaps you pressed Alt+B inadvertently. And the bogus transform can be explained by it being unable to read the bbox of selection at that point. I'll add a guard to "Create bitmap copy" so this never happens again.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 10/14/05, bulia byak <buliabyak@...400...> wrote:
<image id="image3264" transform="matrix(-8.000000e15,0.000000,0.000000,-8.000000e15,1.000000e18,1.000000e18)" height="250.00000" width="250.00000" sodipodi:absref="/Volumes/files/work/enseignement/lpd_perpi/figures/synth_prot/schema_bilan.svg-text326 xlink:href="schema_bilan.svg-text3260-4294966489.png" />
Judging by the name of the png file, it was created by Inkscape itself by "Create bitmap copy" command. Perhaps you pressed Alt+B inadvertently. And the bogus transform can be explained by it being unable to read the bbox of selection at that point. I'll add a guard to "Create bitmap copy" so this never happens again.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 14 oct. 05, at 20:05, bulia byak wrote:
On 10/14/05, bulia byak <buliabyak@...400...> wrote:
<image id="image3264" transform="matrix (-8.000000e15,0.000000,0.000000,-8.000000e15,1.000000e18,1.000000e18) " height="250.00000" width="250.00000" sodipodi:absref="/Volumes/files/work/enseignement/lpd_perpi/ figures/synth_prot/schema_bilan.svg-text326 xlink:href="schema_bilan.svg-text3260-4294966489.png" />
Judging by the name of the png file, it was created by Inkscape itself by "Create bitmap copy" command. Perhaps you pressed Alt+B inadvertently. And the bogus transform can be explained by it being unable to read the bbox of selection at that point. I'll add a guard to "Create bitmap copy" so this never happens again.
this is probable as I never exported or imported any bitmap to this file (you can see comments in the bug tracker. Ben Fowler identified this too). I guess you got the issue right. I will try to do that again and see if anything happens. the selection was some text apparently. I have font issues with fonts converted to TTF which might explain why the bounding box was not found. or maybe text elements do not have bounding boxes...
thank you for this.
JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/
On 10/14/05, jiho <jo.irisson@...400...> wrote:
this is probable as I never exported or imported any bitmap to this file (you can see comments in the bug tracker. Ben Fowler identified this too). I guess you got the issue right. I will try to do that again and see if anything happens. the selection was some text apparently. I have font issues with fonts converted to TTF which might explain why the bounding box was not found. or maybe text elements do not have bounding boxes...
Actually yes, the filename tells you as much: schema_bilan.svg-text3260-4294966489.png means the selected element was the one with id="text3260" when you did alt+b. Currently there's no such element in the file (you can search for ID by Ctrl+F) but maybe you have an old version saved anywhere?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
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
On 10/15/05, Ben Fowler <ben.the.mole@...400...> wrote:
- Missing images should not be selectable and/or
Then it's impossible to delete such an image from GUI.
- The bounding box of a missing image should be ignored and/or
Basically it's the same as 1 from Inkscape viewpoint.
- Zoom to selection should only respect visible objects and/or
This is the case now, but the concept of "invisible" does not include missing-href images.
- Zoom to selection should ignore bitmaps
I don't think so. The root of the problem is not bitmap or missing href. The real problem is the insane bbox. I think this may happen to other elements too, for any number of reasons. So perhaps the best way to address this is to ignore anything which is larger than, say, a million px in any dimension. For example scaling by keyboard already has the 1 million upper limit. However I'm reluctant to do that, as you never know what weird files people would want to edit. This arbitrary limit may bite us sometime.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 10/15/05, bulia byak <buliabyak@...400...> wrote:
On 10/15/05, Ben Fowler <ben.the.mole@...400...> wrote:
- Missing images should not be selectable and/or ..
[Good stuff snipped]
That is exactly what I was thinking when I posted.
Personally, I think that there there is going to be a bit of a surprise: we open the file and zoom to selection expecting a zoom of around 66% and actually get 1%. Once zoomed out, the canvas looks funny and it is a fiddle to get back.
I am not sure how to deal with this.
The SPItem object has an 'isHidden' property, rather than an 'isVisible' one.
desktop.cpp around line 818 calls selection->bounds(&d); to get the bounds of the selection, and selection.cpp around line 307 iterates through the list of items.
Assuming that in general we cannot expect Inkscape to determine whether or not a bounding box is insane, I was thinking that we might exclude some items from the bbox estimation to make the behaviour less surprising.
If this is too intrusive (it would need a change to SPItem, I think), then another possibility would be to document 'zoom to selection' as never zooming out beyond 'fit to page' or 'fit to page width'. If someone is editing files with objects bigger than this (he or she probably couldn't print the file to his or her satisfaction anyway), and needed to zoom out further, then he or she would have to use the zoom tool. I don't think that this would be a big surprise (or a big burden, or needed often), but there is obviously room for several opinions there.
It is a cop out, but there coiuld be a preference: Limit automated zoom out to Page vs Always zoom all the way.
Adding a preference is nearly always wrong and I don't like this one, and whilst the 'iron is hot' we should put in a correct solution.
What do other apps do?
As I said, Freehand can be persuaded to zoom out further than I think it should.
Note that the method Selection::boundsInDocument (selection.cpp around line 326 is never called so far as I can tell and should be slated for removal.
Ben
participants (3)
-
Ben Fowler -
bulia byak -
jiho