Issue 60757

Summary:

Difficult to anchor images to text located in nested tables

Product:

Writer

Reporter:

raindrops <na1000>

Component:

editing

Assignee:

AOO issues mailing list <issues>

Status:

CONFIRMED ---

QA Contact:

Severity:

Trivial

Priority:

CC:

issues

Version:

OOo 2.0.1

Target Milestone:

---

Hardware:

All

OS:

All

Issue Type:

DEFECT

Latest Confirmation in:

---

Developer Difficulty:

---

Attachments:

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
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

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

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.

Comment 7 Marcus 2017-05-20 11:19:34 UTC

Reset assigne to the default "issues@openoffice.apache.org".