View Issue Details

IDProjectCategoryView StatusLast Update
0007389ScribusCanvaspublic2016-03-10 14:09
ReporterBAlpha Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status newResolutionopen 
Platformi686OSFedora LinuxOS Version9
Product Version1.3.5svn 
Summary0007389: Choice of page an object belongs to
DescriptionScribusDoc::OnPage determines the page that an object is on by choosing the first page that intersects with it. Under some circumstances (see "Steps to Reproduce"), this is not the desired result. I solved the problem for myself by instead choosing the page that the object's center point is on (only falling back on the other algorithm when the center point is not on a page), but I suppose there was a reason not to do this to begin with. However, in my opinion one change or another has to be made.
Steps To ReproduceCreate a new double-sided document, 2 pages, first page left, non-zero bleed. Set Document Setup -> Display -> Gaps between Pages -> Horizontal to zero. Now create a rectangle on the right page, setting its left hand x-coordinate to zero (or anything else less than the bleed). As can be seen in the Outline window, Scribus assumes this object to belong to the left page (because the bleed area of the left page intersects with the right page), which is clearly not intended, and is really annoying when you try to move around pages.
Tagspatch
PatchYes

Relationships

has duplicate 0010071 closedjghali Frames Don't Move to Correct Pages 
has duplicate 0012303 closedjghali Image gets listed on wrong page in overview 

Activities

jghali

2008-09-19 09:36

administrator   ~0020273

Last edited: 2008-09-19 09:37

Using the object center or "barycenter" is mathematically wrong as the barycenter may be postionned outside object shape with complex shapes

BAlpha

2008-09-19 12:56

reporter   ~0020275

That is true, but holds for the current algorithm as well: My exact sentence should have been "... by choosing the first page that intersects with its bounding box."

jghali

2008-09-20 14:56

administrator   ~0020289

Yes, this is a known limitation, using the bounding box works however better across cases than the center. Using the bounding box instead of the real shape is also a matter of efficiency. Testing that an arbitrary shape intersect a specific page can be a very costly operation, which should be consequently avoided

BAlpha

2008-09-20 15:35

reporter   ~0020290

I totally agree with sentences two and three. However, you say "using the bounding box works however better across cases than the center". My approach _does_ use the bounding box; its center, to be precise. You can also describe it as "choose the page that has the largest area of intersection with the objects' bounding box" (except for the fallback case).
I would think that in most cases, this should work better than choosing the first page that intersects with the bounding box _at_all_, which is a quite arbitrary choice.
Of course, you cannot just change this, as it would break backwards compatibility; but maybe the choice of which way to use could be part of the document properties, defaulting to the current implementation.

jghali

2008-09-20 15:55

administrator   ~0020291

>> My approach _does_ use the bounding box; its center, to be precise.
Same problem as object barycenter, will work very badly with concave shapes

BAlpha

2008-09-21 17:36

reporter   ~0020304

Last edited: 2008-09-21 20:15

Maybe I didn't make my point too clear. I do not necessarily want my solution to be implemented; I am just saying that the current way of handling the placement is definitely not the best choice. Besides the fact that it does not solve the "concave shape problem" you mention either, it also leads to the kind of problem I described in my "Steps to reproduce."
More generally, if an object (and let's assume it's a rectangle, to leave out the concavity problem for now) is one percent on page 1, one percent on no page, and 98 percent on page 2, I see no reason to assign this object to page 1. If I later say "Move Page 2 to End of Document", I want the rectangle on the last page.
An idea for the long run: Maybe, for any case, there could be a way to manually set the page (maybe even pages?) one wants an object to belong to. This way, if (whatever algorithm is used) Scribus makes the wrong decision (as in: not the one the user wants), it's still possible to get what is wanted.

JLuc

2013-12-13 15:13

developer   ~0030916

Last edited: 2013-12-13 15:45

To stress the interest of this proposal i'd say that many of the on-more-than-one-page overlapping frames have an "obvious" main page and only their borders are overlapping on other pages.

Most of the time, for rectangle frames (and most other shapes aswell probably), using the "center page" as the object's page will fit user expectancies.

For other cases, i'd say that the fact that concave shapes might have no part at all on this page is not more worrying than the fact that there might only be a very little surface of the shape on the first intersecting page.

However with very big frames overlapping on many pages, the "center" might not be so obvious to the user. But this is probably the most rare of the situations.

JLuc

2013-12-13 15:15

developer   ~0030917

Patch for this feature is part of following patch package : https://bitbucket.org/balpha/scribus-patches/wiki/Home

christoph_s

2013-12-14 06:40

administrator   ~0030918

These patches are all GPL 3+ only and hence incompatible with Scribus's GPL 2+.

JLuc

2013-12-14 18:01

developer   ~0030919

to BAlpha : would you mind changing to GPL 2+ the licence of your "Scribus patches" code, so that some of your patch could be merged into scribus trunk ?

BAlpha

2014-01-23 09:49

reporter   ~0031177

Certainly, done. I've also added an explicit license file to the repo.

Issue History

Date Modified Username Field Change
2008-09-13 19:32 BAlpha New Issue
2008-09-19 09:36 jghali Note Added: 0020273
2008-09-19 09:37 jghali Note Edited: 0020273
2008-09-19 12:56 BAlpha Note Added: 0020275
2008-09-20 14:56 jghali Note Added: 0020289
2008-09-20 15:35 BAlpha Note Added: 0020290
2008-09-20 15:55 jghali Note Added: 0020291
2008-09-21 17:36 BAlpha Note Added: 0020304
2008-09-21 20:15 BAlpha Note Edited: 0020304
2011-06-24 17:05 jghali Relationship added has duplicate 0010071
2013-12-13 15:13 JLuc Note Added: 0030916
2013-12-13 15:15 JLuc Note Added: 0030917
2013-12-13 15:45 JLuc Note Edited: 0030916
2013-12-14 06:40 christoph_s Note Added: 0030918
2013-12-14 18:01 JLuc Note Added: 0030919
2014-01-23 09:49 BAlpha Note Added: 0031177
2014-01-23 12:14 JLuc Tag Attached: patch
2014-05-12 12:01 jghali Relationship added has duplicate 0012303
2016-03-10 14:09 Kunda Patch => Yes