View Issue Details

IDProjectCategoryView StatusLast Update
0014175ScribusStory Editor / Text Framespublic2021-12-04 04:38
ReporterJuan Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status confirmedResolutionopen 
Platformx86_64OSWindowsOS Version10
Product Version1.5.3.svn 
Target VersionFuture Release - High Priority 
Summary0014175: Error in page number (“Reference to Mark”) when anchors are in linked text frames
DescriptionReferences 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 ReproduceCreate 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.
Tagsmarks
PatchNo

Relationships

related to 0014181 closedjghali Deleting text with anchor marks triggers crash 
related to 0011812 closedcbradney reference to item marks dont respect the secttion's defined offset for page numbers 
has duplicate 0016216 closedjghali 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) 

Activities

Juan

2016-06-24 13:24

reporter   ~0041708

Last edited: 2016-06-25 12:05

Seems related to 0011812, but this has been closed (?).

PeterBenedek

2016-06-24 14:39

developer   ~0041709

Juan, please upload sample file! Thanks!

Juan

2016-06-24 15:30

reporter  

Juan

2016-06-24 15:31

reporter  

Juan

2016-06-24 15:31

reporter  

Juan

2016-06-24 15:45

reporter   ~0041710

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!

PeterBenedek

2016-06-25 12:12

developer   ~0041711

Tested: Linux Mint 18; Qt5.5.1; Qt5.6.1; r21386

I can reproduce this. And this: 0014181

Juan

2016-12-19 10:23

reporter   ~0043102

Is there any chance of these two issues being addressed in the forthcoming 1.5.3 version? They break important functionality. Thanks in advance!

jghali

2020-04-23 23:39

administrator   ~0047556

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.

xavid

2020-04-24 02:56

reporter   ~0047559

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.

ale

2020-08-19 05:36

manager   ~0047975

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

steve98052

2021-12-02 22:55

reporter   ~0049395

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?

steve98052

2021-12-04 04:38

reporter   ~0049403

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.

Issue History

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