Details
-
Bug
-
Status: Open
-
Resolution: Unresolved
-
1.7
-
None
-
None
-
Operating System: Linux
Platform: PC
Description
1. Load an SVG document in Squiggle with these attributes:
viewBox="0 0 400 400" width="400" height="400" preserveAspectRatio="xMidYMin meet"
2. Squiggle will display it normally in a 400x400 window
3. Pull the corner of the the squiggle window directly downward (vertically) until the window is now 400x800
4. Squiggle continues to display the image more or less correctly, top-justified vertically (due to "YMin" and/or bug#45102)
5. Now Resize the window to 800x400
6. BUG: Squiggle displays only the bottom half of the image. Instead, it should be displaying the image centered horizontally and top-justified vertically.
Why I think this is a bug: simply resizing a window should not cause the SVG specification rules regarding how the viewbox is mapped into the rendering area to be violated.
There are two related "window resizing" bugs; the first is BATIK-829 and this is the second. There seems to be confusion because several pieces of information are all glommed together (cumulatively) in the rendering transform (viewbox transform, preserveAspectRatio behavior, any zooms or pans, etc.) and there is a loss of information.
For example, once the image is loaded, the fact that preserveAspectRatio says that the image should be left (or top, or whatever) justified is forgotten. In other words, it is just assumed that because it was properly justified in the beginning, it will stay that way. But this cannot be the case when the window is resized with a different aspect ratio without explicitly tracking the justification requirements. For example, when the window is resized, the justification translation could be factored out, then the window resized, then factored back in (it will be different now).
Nice idea maybe, but then what if you have zoomed in? The current behavior (ignoring preserveAspectRatio after initial load) works better if what you want is for the thing you've zoomed in on to stay there after a resize. Re-applying the justification translations after a window resize might cause a zoomed-in view to suddenly jump to another part of the canvas.
So I'm not sure what the right answer is. Here's some vague thoughts. I think the important thing we need to do is to separately keep track of the various stuff that today we're glomming together.
Possible fix idea(s):
1. Store the cumulative zoom and pan in a separate matrix that is applied to the viewbox transform only (before the rendering transform). In other words, think of zoom and pan as applying to the viewBox rectangle itself, causing a "new" viewbox to be used.
2. When the window is resized, recompute the rendering transform from the (zoom/pan modified) viewBox transform, while also factoring in "preserveAspectRatio" and the new window size.
3. Recompute the rendering transform from scratch each time instead of carrying it along. I think there are some rounding errors that creep in over time (just a suspicion).