Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Difficult to anchor images to text located in nested tables|
|Component:||editing||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description raindrops 2006-01-18 13:13:06 UTC
My odt file (300+ pages) has I have a two-column table: The left column acts as margin; the right column holds the text. Some of the text is contained in nested tables. I place small images in the left column of the outer table, and anchor them to the paragraphs.I can easily re-position them by drag-n-drop method: The anchor point follows the image and snaps to the nearest paragraph. By the dragging the image close to a paragraph, I can snap the anchor point to that paragraph. But it is difficult to move images and anchor them to paragraphs in a NESTED table. During the D&D operation, the anchor point moves in an uncontrollable fashion. The problem is severe when the paragraph is in a right-side column of the nested table. In some cases, when the image has to be dragged across multiple pages, it jumps back to its original position (or worse, to a completely new page). It is extremely tedious to go through several pages to find it out and drag it again (with no guarantee of success this time also!)
Comment 1 michael.ruess 2006-01-18 14:13:05 UTC
MRU->raindrops: as a workaround, use the real Drag-and-Drop mechanism. Select a graphic and then click and hold left mousbutton, so that a Drag-and-drop curso will show up after about 2 seconds. Then transfer the graphic into a table cell. Nevertheless, moving a graphic across a table is kind of painful. it is a known problem; see issue 12952. *** This issue has been marked as a duplicate of 12952 ***
Comment 2 michael.ruess 2006-01-18 14:15:43 UTC
Comment 3 raindrops 2006-01-19 05:30:28 UTC
Like another issue of mine, this too is closed as a duplicate; but I don't see any semblance between the two. I think developers would skip all issues marked "duplicate" and so an important feedback/clue would be lost. As I described, this issue is not about a single table. It is about a NESTED table; and that too when the text is NOT in the fist column of that nested table. Secondly, the issue 12952 does not talk about image jumping back to original location or to a third location. How can this issue be marked as "duplicate" under such circumstances? Let us have a new category called "variant", with the following important differences as compared to a true duplicate: 1. Unlike a duplicate, a variant stays open and get closed together with original. 2. Just in case the root cause is different, the issue can be tackled separately. Currently, as a closed issue, no one will even think about it. It simply drops out of sight. 3. The developer is forced to read a variant separately.
Comment 5 michael.ruess 2006-01-19 09:52:59 UTC
MRU->OD this is quite similar to issue 12952. The anchor even jumps a bit more uncontrollable when moving in tbales with nested tables inside. Please have a look into the methods if this is really not a dup. Thanks!
Comment 6 raindrops 2006-01-19 12:36:12 UTC
Raindrops->OD The sample attached by MRU does NOT have the problem of jumping back to a third UNKNOWN location, SEVERAL PAGES AWAY; which my issue is all about. In MRU's sample, the image stays wherever you drop it. You can see the anchor all the time. The movement of the anchor too seems fairly controlled. The only problem is in pushing it in the right direction, which can be mastered with some practice. (Trolleys used in airports/supermarkets come to mind!) ;) But in the problem I am describing, the anchor is truly wild. It does not even appear in the target cell, and when you release the image, it is sure to go to a third unknown page, several pages away. You have to go looking for the missing image, as it is not to be found at its original location. Probably the reason is that MRU's sample is only one page long, and therefore can't show my problem. Probably the distance from original position to the target position also is a factor. I will try this out on my part. Thanks.