Problem with flow-with-text

C. Boemann cbo at boemann.dk
Tue Nov 8 07:38:24 GMT 2011


On Tuesday 08 November 2011 05:37:23 Sebastian Sauer wrote:
> Aloha,
> 
> ===== Preamble =====
> 
> I am writing this to our mailinglist to have the discussion and a
> possible outcome of it achieved.
> 
> ===== The problem =====
> 
> The textlayout-library hardcodes the position of each rootArea (aka page
> in Words) and that leads to problems with the flow-with-text
> implementation.
> 
> More concrete in KoTextDocumentLayout.cpp we do something like;
> rootArea->setReferenceRect(0, size.width(), d->y, d->y + size.height());
> d->y = rootArea->bottom() + qreal(50);
> 
> That means we assume the x-position is 0. This is not the case with
> facing pages (2 pages side-by-side - not done yet but it's a requirement
> I've still on my todo-list).
> 
> It's already a concrete problem with columns where we can have >1
> rootArea per page and there x-position==0 is just wrong.
> 
> Beside us assuming that there is only one column of pages we also
> hardcode the distance (50px) between them. That is wrong cause Words
> uses something different already (the configurable
> KWViewMode::ViewMap::distance) plus we may have additional space between
> pages (or to be more correct page-bodies) occupied by
> headers/footers/footnotes.
> 
> That means our referenceRect().top() has wrong values and we are
> applying those wrong values now, with the flow-with-text implementation,
> in FloatingAnchorStrategy::checkLayoutEnvironment as boundaries.
> 
I believe you are mistaken here. The textlayout coordinates are different from 
document/flake coordinates.

No matter where the shape is placed those textlayout coordinates remain the 
same. so it doesn't matter if the text shapes are placed side by side or even 
on top of each other.

The 50 px hardcoded distance is not related to pages or columns in words, but 
is a distance in textlayout coordinates between rootareas to avoid font stems 
overlapping and being visible when paragraphs is broken over two rootareas.

> ===== The Effect =====
> 
> It seems to work fine for the first page cause there we are indeed
> dealing with the correct values. But all following pages have wrong values.
> 
> That is the reason that at some documents anchored images which have
> flow-with-text=true have wrong positions now. As higher the page-number
> those images are on as more wrong is there position.
I'm not saying theres isn't a problem similar to what you describe  but I 
don't believe your analysis is correct, and the cause must be found somewhere 
else.
 
> ===== Solution =====
> 
> That is what I like to talk about. Personally I think;
> 
> 1. We should apply a fast workaround first. That means disabling the
> FloatingAnchorStrategy::checkLayoutEnvironment logic for now till we
> have something that works as expected. I think the problem is to major
> to have it in the next Calligra releases. Instead it's imho better to
> not ship with support for flow-with-text till we have something that
> works as expected.
Let's give it some more time before we make such a decision

> 2. I think what we should do is to let the application define the proper
> positions and not hard.code it in the textlayout-lib.
> 
> 3. The hard part is to keep those values synchronized. That means if the
> application does shape->setPosition() or shape->setSize then the
> referenceRect needs to be automatically adjusted. In the best case in a
> way that does not force additional "update-logic" in the application
> code. Maybe we can use the shape's model for it?
As your analysis is wrong these proposals are also wrong

> 
> So, what do you think?



More information about the calligra-devel mailing list