DO NOT REPLY [Bug 45021] New: updateRenderingTransform() shifts "xMidYMin" image off top of screen with window resize

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=45021

           Summary: updateRenderingTransform() shifts "xMidYMin" image off
                    top of screen with window resize
           Product: Batik
           Version: 1.7
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Bridge
        AssignedTo: batik-dev@xmlgraphics.apache.org
        ReportedBy: archie@dellroad.org


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 Bug #45012 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).


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org