Hi,

I noticed you changed the Capture feature recently (EO.Total 2016.0.21 - Fixed WebView.Capture not working issue, also enhanced the capture feature to allow capturing anywhere in the page, not just the onscreen area)

Actually, we discovered that this a breaking change for us.
Although we like it and it is very useful.

In fact, using the Capture() method is our main business of using EO WebBrowser.
Our users manipulate the browser, for the sole reason of capturing sections of reports.

So I'm not sure you are aware but the breaking change here was that the Rectangle that is passed to WebView.Capture() now needs to include the scrolling position offset - before it did not.

For example, we used to calculate the position of the Rectangle that the user selected on the WebView (via a bounding box).
We could calculate where the Rectangle was by offseting from the left of the browser control.
It didn't matter if the browser was scrolled left or not.

After this change, the scroll position does matter and will break our old offset code.

Now we have to use the offset PLUS also add the scroll position offset ie document.scrollLeft() - if there is any.
Otherwise if we simply add the offset of the browser window, it is not enough.

I think you will know this, given the changes you made.
I imagine it is probably necessary for capturing something off screen - and that feature is actually very useful to us too.

But I am still having the problem that if the ZoomFactor is not 1 - the Capture() rectangle is now wrong again. By a factor that I cannot work out.

eg when the zoomfactor is 1.5 (150%) my Capture() rectangle coordinates are wrong again, even after making the above described corrections which always work when the zoomFactor is 1...

My captured rectangle is now WRONG (only in the left coordinate) by a factor of approximately 1.158x - in this case.
I see no relation in that number. But I need to multiply my Rectangle's X coordinate by that number - only when zoomFactor is not 1, to get the right capture.

I understand you'll need a test project.
It might take me a while to do it, I suspect.

Hi,

We have looked into this. The rule for this seems to be that:

Scroll: Capturing coordination is unrelated to page scroll position

For example, Capture(0, 200, 100, 100) on Y axis will always capture at 200 pixels from top of the page to 300 pixels from top of the page, no matter where the scroll offset of the current view. If you want to start capture from the current window top, you can do Capture(0, window.pageYOffset, 100, 100). Note here "Capture(0, window.pageYOffset, 100, 100)" is not the actual code, it's just for expressing the idea.

ZoomFactor: All coordination values are multiplied by the zoom factor

For example, in order to capture the same rectangle (0, 200, 100, 100) at zoom factor as 1.5, the coordination must be (0, 300, 150, 150). Note that all values, not just the size must multiply by the zoom factor. As such if you wish to capture from the window top, you can use Capture(0, window.pageYOffset * zoomFactor, 100 * zoomFactor, 100 * zoomFactor). The key is all coordination values are multiplied.

Please let us know if this is consistent with what you see on your end.

Thanks!

Hi,

You must multiple the scroll offset as well. Try to think zoom factor as a coordination multiplier. Internally it is implemented with a scale matrix, which does exactly the same on all coordination values. So you always figure out the unscaled value first, then multiply to get the scaled value, where as the unscaled value = scroll offset + x/y offset. So the final value will be zoom factor * (scroll offset + x/y offset).

Thanks