Apache OpenOffice (AOO) Bugzilla – Issue 102061
sc: rfc: proposed cell anchoring and positioning mechanism
Last modified: 2017-05-20 11:27:51 UTC
So issue 28244 and others show some difficulty with cell anchored objects with resizing of rows and columns. Especially when they are affected by collapsing and expanding outlines where the sizes end up sort of "screwy" or the shapes end up stuck to the top of the collapsed region even after re-expansion The .odf format gives... "If a drawing shape is included in a spreadsheet document and if the anchor of the shape is in a cell, then the attributes table:end-cell-address, table:end-x and table:end-y specify the end position of the shape and the size attributes are ignored. The end position is specified using the cell address of the cell in which the end position is located, and the x and y coordinates of the end position relative to the top left edge of the cell." So I suggest we just associate an anchor object with all cell anchored cells which describes the start and end cell which it belongs to and include in that anchor object an offset from the start cell and the end cell. We make the definition of being cell-anchored the presence of that anchor data, being page-anchored otherwise. ScDrawObjData is basically used for something like this already. a) For non size and position protected objects inside a range that's collapsed then we can restore the object's size on expand. b) For size-protected objects we can restore it back to its original location when that position is restored c) Cache inside the anchor data the logicrect of the shape on the last update, so we can distinguish between the shape being moved due to cell/row movement, and being moved around the page. d) Manual movement of the shape "breaks" the anchors and new ones are generated from the position on the page e) If inserted through the uno api (which only takes a single XCell as the reference), or through xml that is missing the end-x/end-y values then we generate the end anchors at insertion time but keep the start ones The plus here is that a) cell anchored objects, resizable + repositionable end up equivalent behaviour as the excel move and size with cells b) cell anchored objects, non-resizable + repositionable end up equivalent behaviour as the excel move with cells As a demo, I attach a .ods which on expansion of the outline should IMO end up with three graphics all at the same visual y position Some open questions though: a) a size and position protected cell-anchored object. That should be size and position relative to the *page* protected right ?, i.e. not really any different to page anchored in how it behaves ? b) What have I forgotten ?, I haven't looked at fixing this up for RTL yet, so I need to check that. But is there other things that need to be handled ?
Created attachment 62368 [details] interim patch for feedback
Created attachment 62369 [details] a basic test-case
Created attachment 62370 [details] real-world example
so do you reckon the approach is useful, i.e. worth me spending more time on completing it ?
From a first look, it seems this might work. Undo for manually moving a shape won't be complete, as the anchor isn't restored, but I suppose we can live with that. Armin, do you see any fundamental problems with this approach?
@cmc: I won't comment on the technical aspect of this (since I'm not that familiar with drawing object handling yet), but just wanted to say that we've also had customers suffering from the same problem in the past, and nailing this down would be definitely well appreciated.
could you please check if issues Controls are loosing their position even if they are move protected http://www.openoffice.org/issues/show_bug.cgi?id=10019 can not set AnchorType of a control in calc via API http://www.openoffice.org/issues/show_bug.cgi?id=33783 will be fixed with your patch too ?
The example of 10019 falls under the open question of "a) a size and position protected cell-anchored object. That should be size and position relative to the *page* protected right ?, i.e. not really any different to page anchored in how it behaves ?" So with this patch those controls stay exactly at the same position on the screen before and after collapsing/expanding the outlines, i.e. the same as if they were page anchored. I *think* that's what we want to happen, but maybe we want something else to happen there. issue 33783 is unchanged by this patch, though looking at that I added an example of how to toggle the anchoring which works right now in 3.1. Improving the uno api is probably out of scope of this impl here, though it probably gives more support for changes.
AW->NN: No principal problems. The SdrObject has an Anchor (used by Calc and Writer currently, SW usage may go away soon). Currently, the SdrObject has a position and size, and the anchor seems to be calculated from this to fit in the correct cell. In principle, those anchor movements, e.g. a column is inserted left of such an anchor, is ignored currently; the correct (new) cell is calculated, the SdrObject did not move. I see no problem when moving cells internally, to check for anchors in this cell(s) and to simply move the SdrObjects accordingly (same new anchor calculation after this, but now with correct new position). Undo and Redo would just do the same, no need to remember the anchor. HTH!
Created attachment 62796 [details] expand test case for rtl example
Created attachment 62797 [details] updated patch
Updated to take care of RTL support and rename the old xml import positioning class to its new reduced functionality. Pretty sure this gives us the behaviour that makes most sense for object positioning and sizing when their range in which it belongs is collapsed/expanded. Though there may be other types of things that can be put into spreadsheets that I don't know about that might not be covered.
Created attachment 65285 [details] update patch to apply against DEV300_m61
Created attachment 65951 [details] update patch to exclude "notes" from getting their anchor position updated from the caption location, as they manage their anchor position themselves
*** Issue 106619 has been marked as a duplicate of this issue. ***
*** Issue 106680 has been marked as a duplicate of this issue. ***
I saw smilar effects as reported in DUP Issue 106619 in Issue 108737 with WIN and LINUX. Can someone please check whether - Issue 108737 is a DUP of this one - This one is also for WIN
Created attachment 69047 [details] update patch to apply against HEAD
cmc->nn: so what do you think ? Good idea, bad idea, any gotchas I'm unaware of ?
Good idea, and not sure about the gotchas. Relying on the view to update the anchors seems a bit ugly from an architectural point of view. New shapes should by default be anchored to a cell. Detective rectangles don't include the last column/row. Some special handling for the "tail" of callouts is still needed. I have a feeling it will still take some time to really finish this. But, again, I think the idea is good.
Created attachment 70592 [details] update patch for 3.3
*** Issue 99244 has been marked as a duplicate of this issue. ***
I'm adding this comment to all open issues with Issue Type == PATCH. We have 220 such issues, many of them quite old. I apologize for that. We need your help in prioritizing which patches should be integrated into our next release, Apache OpenOffice 4.0. If you have submitted a patch and think it is applicable for AOO 4.0, please respond with a comment to let us know. On the other hand, if the patch is no longer relevant, please let us know that as well. If you have any general questions or want to discuss this further, please send a note to our dev mailing list: dev@openoffice.apache.org Thanks! -Rob
Reset assigne to the default "issues@openoffice.apache.org".