View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0014175 | Scribus | Story Editor / Text Frames | public | 2016-06-23 14:17 | 2021-12-04 04:38 |
| Reporter | Juan | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | confirmed | Resolution | open | ||
| Platform | x86_64 | OS | Windows | OS Version | 10 |
| Product Version | 1.5.3.svn | ||||
| Target Version | Future Release - High Priority | ||||
| Summary | 0014175: Error in page number (“Reference to Mark”) when anchors are in linked text frames | ||||
| Description | References to marks (anchors) work correctly, inserting the number of the page where the anchor is, but as soon as the text frame containing the anchors is linked to another text frame, the page number changes to that of the first text frame. | ||||
| Steps To Reproduce | Create a new file. Add several pages (three or more). Add a text frame in each of the pages. In each text frame except the first, insert anchors (Insert > Marks > Anchor Mark). In the text frame of the first page, insert references to these anchors (Insert > Marks > Reference to Mark): page numbers are correct. Then, link the text frames containing the anchors: all page numbers in the first frame change to that of the first linked text frame. Then, unlink the text frames containing the anchors: all page numbers in the first frame change to reflect the correct page number. | ||||
| Tags | marks | ||||
| Patch | No | ||||
| related to | 0014181 | closed | jghali | Deleting text with anchor marks triggers crash |
| related to | 0011812 | closed | cbradney | reference to item marks dont respect the secttion's defined offset for page numbers |
| has duplicate | 0016216 | closed | jghali | Reference to mark point to the start of the chain, not to the mark's position |
| child of | 0012496 | acknowledged | Metabug: Marks & Footnotes & Weld (1.5.0.svn) |
|
|
Seems related to 0011812, but this has been closed (?). |
|
|
Juan, please upload sample file! Thanks! |
|
|
|
|
|
|
|
|
|
|
|
Thanks for your attention, Peter. Here you have three files, created as follows: 1. Create file “References to anchors - Unlinked Frames.sla”, composed of four pages with one text frame each, containing two anchors at the beginning of two lines, then create a kind of TOC in the first page by inserting references to each anchor. Result: Page numbers (Insert > Reference to Mark) are correctly displayed and updated automatically (e.g.: add a page in the middle, delete it…). 2. Copy the file and name it “References to anchors - Linked Frames without Frame Breaks.sla”. Proceed to link frames on pages 2, 3 and 4 (which leads often to a crash, but that is another story…). After this, reflow the text between pages as it was before by adding paragraphs until all anchors are in their original page. Result: Page numbers in TOC change to 2 (the first linked frame) for all references to anchors, disregarding their real position. 3. In the file “References to anchors - Linked Frames with Frame Breaks.sla”, reflowing of the anchors is done by inserting frame breaks instead of paragraphs. Result: same issue with page numbers. Hope it helps! |
|
|
Tested: Linux Mint 18; Qt5.5.1; Qt5.6.1; r21386 I can reproduce this. And this: 0014181 |
|
|
Is there any chance of these two issues being addressed in the forthcoming 1.5.3 version? They break important functionality. Thanks in advance! |
|
|
I had a look at this issue and fixing it will be a bit difficult in the context of Scribus. In order to know the proper page number corresponding to each anchor, we basically need to perform the layout of the frame where anchors are located before layout of the frame where the reference marks are located. In the use case presented here, the frame where the reference marks are inserted are positioned logically before the frames where anchor marks have been inserted. So frames where references marks are inserted will be layouted before frames on following pages. So layouting text in such case would need at least multiple passes. Possible in software such as Latex, hardly in Scribus for obvious performance reasons. If reference marks are located in the same text chain as the anchors, this even leads to a chicken and egg problem : to know the text to insert for reference marks, we need to layout the text located afterwards, but to perform the layout of the portion of text containing anchor marks, we need to perform layout of the preceding portion of text containing the reference marks. |
|
|
Would it make sense to have some manual operation one could trigger to update page references based on the current layout? That'd avoid the performance impact of doing two passes all the time while allowing someone to get the correct page references before printing without needing to unlink everything. |
|
|
as far as i can tell, in almost all cases, scribus will do the right thing in a single pass. there are cases, where two (or more?) passes might be needed. scribus can detect them by checking if during the layout the frame breaks have changed. in this case scribus could trigger a warning in the verifier and suggest a manual update. (contains marks + layout has changed during the last update) finally, there can be cases where it might be impossible to achieve a stable state (i guess that this will "only" happen when the chain goes backwards...). personally, i'd love to have - a way to make the marks "visible". - a context menu on the marks to trigger the update of the single mark / all marks (of the same type). - a way to update the layout of a single (chain of) frame(s). but for a first improvement a solution that relies on the preflight verifier might be the simplest solution to get something that - works in almost all cases (but, probably, RTL) - makes the user aware of possible issues |
|
|
I'm asking for clarifications here, not just to help clarify the bug report for developers (who presumably know what's going on pretty well), but also because this bug report is the most informative page that comes up from a web search user documentation on how to use anchors and hrefs. (I'm using HTML terms because I don't know the Scribus terms.) Answers to my clarification requests may serve as interim documentation of these features, as well as a guide for documentation that needs to be written (and a starting point for a documentation bug report). If I understand this bug report correctly, it shows up when there's an anchor in a block of text that flows across more than one text box, particularly when text flows across page boundaries, and an href points to it. For example: Initially: Page 1 contains text box 1. Page 2 contains text box 2. Page 3 contains text box 3. Page 4 contains text box 4. Text span 1 is entirely inside text box 1. It contains href 1, which points to anchor 1. Text span 2 flows through text boxes 1, 2, and 3. It contains anchor 1, initially inside text box 3. So, when initially created, does href 1 correctly point to anchor 1 in text box 3 on page 3? Or the beginning of text span 1 in text box 2 on page 2? After revision: As I understand the bug, if text span 2 is revised so that anchor 1 moves to text box 3 on page 3, it incorrectly updates to point to the beginning of text span 2, in text box 2, on page 2. Related question: If the same four pages contain the same four text boxes, but each text box has its own separate text span, do hrefs and anchors function correctly. For example: Initially: Page 1 contains text box 1. Page 2 contains text box 2. Page 3 contains text box 3. Page 4 contains text box 4. All text boxes contain independent text spans. Text box 1 contains href 1, which points to anchor 1. Text box 3 contains anchor 1. After revision: Suppose an additional page is inserted between page 1 and page 2, causing pages 2 and 3 to become pages 3 and 4. Will href 1 still point, correctly, to anchor 1 in text box 3, on the page 4 that had initially been page 3? Or will it continue to point to the page 3 that had initially been page 2, losing the connection to text box 3? My understanding is that this bug report refers to generation of text links (such as "see page 3"). Do these problems also exist in the type of links that can be generated in PDF output? |
|
|
Answering myself on the "Related question": Anchors and marks work just fine when they stay put within a single text box that changes pages due to inserted or deleted pages. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-06-23 14:17 | Juan | New Issue | |
| 2016-06-24 13:24 | Juan | Note Added: 0041708 | |
| 2016-06-24 14:39 | PeterBenedek | Note Added: 0041709 | |
| 2016-06-24 15:30 | Juan | File Added: References to anchors - Unlinked Frames.sla | |
| 2016-06-24 15:31 | Juan | File Added: References to anchors - Linked Frames without Frame Breaks.sla | |
| 2016-06-24 15:31 | Juan | File Added: References to anchors - Linked Frames with Frame Breaks.sla | |
| 2016-06-24 15:45 | Juan | Note Added: 0041710 | |
| 2016-06-25 12:05 | PeterBenedek | Note Edited: 0041708 | |
| 2016-06-25 12:12 | PeterBenedek | Note Added: 0041711 | |
| 2016-12-19 10:23 | Juan | Note Added: 0043102 | |
| 2016-12-19 13:29 | Kunda | Relationship added | related to 0014181 |
| 2016-12-19 13:30 | Kunda | Tag Attached: marks | |
| 2016-12-19 13:32 | Kunda | Status | new => confirmed |
| 2016-12-19 13:32 | Kunda | Target Version | => Future Release - High Priority |
| 2016-12-19 13:33 | Kunda | Relationship added | related to 0011812 |
| 2016-12-19 13:37 | Kunda | Relationship added | child of 0012496 |
| 2020-04-23 23:39 | jghali | Note Added: 0047556 | |
| 2020-04-24 02:56 | xavid | Note Added: 0047559 | |
| 2020-08-17 10:07 | jghali | Relationship added | has duplicate 0016216 |
| 2020-08-19 05:36 | ale | Note Added: 0047975 | |
| 2021-12-02 22:55 | steve98052 | Note Added: 0049395 | |
| 2021-12-04 04:38 | steve98052 | Note Added: 0049403 |
