View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007389 | Scribus | Canvas | public | 2008-09-13 19:32 | 2016-03-10 14:09 |
| Reporter | BAlpha | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | i686 | OS | Fedora Linux | OS Version | 9 |
| Product Version | 1.3.5svn | ||||
| Summary | 0007389: Choice of page an object belongs to | ||||
| Description | ScribusDoc::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 Reproduce | Create 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. | ||||
| Tags | patch | ||||
| Patch | Yes | ||||
|
|
Using the object center or "barycenter" is mathematically wrong as the barycenter may be postionned outside object shape with complex shapes |
|
|
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." |
|
|
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 |
|
|
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. |
|
|
>> My approach _does_ use the bounding box; its center, to be precise. Same problem as object barycenter, will work very badly with concave shapes |
|
|
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. |
|
|
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. |
|
|
Patch for this feature is part of following patch package : https://bitbucket.org/balpha/scribus-patches/wiki/Home |
|
|
These patches are all GPL 3+ only and hence incompatible with Scribus's GPL 2+. |
|
|
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 ? |
|
|
Certainly, done. I've also added an explicit license file to the repo. |
| 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 |
