GNU TeXmacs - Bugs: bug #36301, Unstable typesetter flip-flops...
You are not allowed to post comments on this tracker with your current authentication level.
bug #36301: Unstable typesetter flip-flops forward references
Submitter: | Sam Liddicott <samjam> | ||
Submitted: | Wed 25 Apr 2012 01:54:26 PM UTC | ||
Category: | Typesetter | Priority: | 5 - Normal |
Item Group: | Error | Status: | Wont Fix |
Privacy: | Public | Assigned to: | vdhoeven |
Originator Name: | Open/Closed: | Open | |
Release: | None | Release: | |
Fixed Release: | None | Fixed Release: | |
Keywords: |
Fri 23 Jun 2017 05:56:33 PM UTC, comment #4: |
Joris van der Hoeven <vdhoeven>![]() ![]() |
Thu 26 Apr 2012 07:42:33 AM UTC, comment #3: Trimming the document, it seems like there may be two possible triggers
1. The trigger may be a single trailing paragraph on the page.
On the following update it seems to remember to avoid the trailing paragraph and tighten the spacing.
On the following typeset it either forgets why it did that or finds things to squashed and so the paragraph ends up alone again.
2. Page headers.
I insert a label start of a chunk and also at the end of the chunk. I then compare the page numbers that the labels occur on. If the page numbers are not the same, then I <set-this-page-header|...> to be identical to the chunk header.
This allows chunks that span a page break to have a code header on the new page (instead of the page header).
I figured this should be safe as I don't change the size of the page header (I thought).
But if I don't set the page header, then the problem does not occur.
The implication that in a run of pages up to a page break, setting the page header for a single page in the run can affect typesetting.
I need a way to set the page header without changing it's size.
I altered the code that sets the page header to be:
and the problem still occurs, so I need to find out if setting the page header triggers any particular typesetting effects or actions. |
Sam Liddicott <samjam>![]() |
Wed 25 Apr 2012 02:20:46 PM UTC, comment #2: Opening another window onto the same view/buffer (even at page 1) prevents the flip-flopping.
Weird.
Closing the extra window doesn't re-start flip-flopping unless document-update-all is done.
|
Sam Liddicott <samjam>![]() |
Wed 25 Apr 2012 02:06:16 PM UTC, comment #1: I'm still doing more investigation on this, I post it here as a discussion point. |
Sam Liddicott <samjam>![]() |
Wed 25 Apr 2012 01:54:26 PM UTC, original submission:
See the attached document (and stylesheet).
It has professional typesetting algorithm set.
At the bottom of page 26 there is a forward reference to 27a
Look at the top of page 27, the chunk is called 26f but should be 27a.
Click on Tools->Update->Styles
Now the chunk from the top of 27 has moved to the bottom of page 26 and should be called 26f but is now called 27a.
We can talk about the mechanism for a macro working out what page it is on (it inserts a label and then reads the binding to get the page number), but that's not the point; it would work if the paragraph didn't keep switching around.
The label business aside, if the paragraphs keep flipping around then there is a good chance that a new edition of an article or book that fixes a spelling on the last page could have other paragraphs on different pages than the previous revision.
Most interestingly as I try to document this I find that exporting a pdf makes the layout stable for a few iterations (or maybe until I do "document->update-all") at which point it becomes unstable again.
I will try and find a workaround for reseting counters each page, but the issue here is the flip flopping.
I realise that sometimes use of a reference whose label changes size can materially affect the typesetting if the label text size changes as the page number changes, e.g. 99 to 100, but that isn't happening here as far as I can tell. |
Sam Liddicott <samjam>![]() |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 8 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2017-06-23 | vdhoeven | Item Group | None | ![]() |
Error |
Status | Need Info | ![]() |
Wont Fix | ||
Assigned to | None | ![]() |
vdhoeven | ||
2012-04-25 | samjam | Status | None | ![]() |
Need Info |
2012-04-25 | samjam | Attached File | - | ![]() |
Added fangle.ts, #25734 |
Attached File | - | ![]() |
Added fangle.tm, #25735 | ||
Attached File | - | ![]() |
Added fangle-1.pdf, #25736 | ||
Attached File | - | ![]() |
Added fangle-2.pdf, #25737 |
I fear that this bug is somewhat hard to prevent. It seems like trying to meet several contradictory constraints at the same time. So I guess that some flip-flopping at such occasions should be allowed, as long as it does not induce any segfaults. We might wish to issue a warning though.