OpenLayers: handle resizing of the map DIV correctly

[rsimon]

Via @klokantech: "[...] while testing I have realised Annotorious is not able to handle resize of the DIV with the map - which is quite bad for our fullscreen layouts."

Root cause is that the HTML element needs to be told the absolute width and height in pixels. A "percentage" width/height is not supported by design. I'll address this in two parts:

• correct reset of width/height after resizing the browser window (which should handle most use cases)
• correct reset of width/height after resizing a (resizable) DIV element within a page (while the browser window stays the same)

The second part is likely not part of release 0.7!

[rsimon]

Note: for OpenLayers, the best strategy would be to change the way the Canvas is added to the map: Annotorious should not create another wrapping DIV, but attach the canvas directly to the original map DIV.

[rsimon]

As reported by @gergely-ujvari, the same issue applies to normal images that are resized dynamically. It should be possible though to attach a Window resize listener, and recalculate image pixel width on resize. Only needs a good test case & example page.

[dwhly]

Rainer, this may be a good example page too: http://ajw.asahi.com/article/0311disaster/fukushima/AJ201311030016

If I create an annotation when the image is small, like so: http://image3.dokku.hypothes.is/a/LqyVp8eRTPe4qK9tQtFxZg

And then click the "expand" icon at the upper right of image, then the selector does not refer correctly to the same part of the image.

I'm using the image annotator available via the bookmarklet at the bottom of our test server here: http://image3.dokku.hypothes.is/

[rsimon]

Hi Dan,

wow - that's a pretty tricky example & I'm surprised this works this well at all. I couldn't figure out what exactly happens on that page (lack of time). But apparently, clicking the "expand" button "transplants" the image DOM element from one DIV into another.

But it seems to pick up the surrounding Annotorious wrapper correctly, so the main issue is indeed the image resizing. Some thoughts:

• I don't know whether it's possible at all to attach a DOM listener that could give us a handle on the DOM manipulation event. If that is possible (ideas anyone?) a simple workaround would be to reset (i.e. remove and re-attach) the Annotorious annotation layer. The standalone version has a global anno.reset() method for this. I think you are still working with the annotator objects directly, rather than re-using the whole system, right? So you'd have to replicate the behavior yourself. But it's really a matter of destroying the annotator object by calling .destroy() and then re-creating a new one on the image.
• One issue that's causing mayhem is the absolute sizing on the surrounding absolute DIV. I need to check whether that's at all necessary. If not, it could safely be removed from the template the surrounding DIV is based on. And that would be one step towards the solution.
• The second - more problematic issue - is that the <canvas> element always needs absolute dimensions set in pixels (because it operates in a coordinate space decoupled from the rest of the page). In other words: there absolutely needs to be a JavaScript "intervention" following the image resizing that recalculates the new dimensinons of the image and updates the width & height attributes of the <canvas> accordingly. If it is not possible to catch the resize event with a listener (cf. first bullet item), I'm somewhat out of ideas on this (except for a polling loop - which would neither be particularly nice nor performant...)

[rsimon]

Note: changes to the DOM can be monitored (on most browsers?) it seems! See:

http://www.quirksmode.org/js/events/DOMtree.html http://davidwalsh.name/dom-events-javascript

I.e. a possible fix could therefore be to attach a DOM Tree Event listener, and reset Annotorious whenever the DOM is modified - or, ideally, only the subtree(s) containing the annotated image(s) - if it is possible to determine this.

[rsimon]

Continuing the discussion in Issue #86, since it is actually becoming quite distinct from the original scope of the original (OpenLayers-related) issue.

[rsimon]

Last commit fixes this issue to the extent required for Release 0.7!