Issue 60757

Summary: Difficult to anchor images to text located in nested tables
Product: Writer Reporter: raindrops <na1000>
Component: editingAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: issues
Version: OOo 2.0.1   
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Description Flags
sample document none

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

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
Closing duplicate.
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 4 michael.ruess 2006-01-19 09:48:56 UTC
Created attachment 33368 [details]
sample document
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

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.

Comment 7 Marcus 2017-05-20 11:19:34 UTC
Reset assigne to the default "".