Is there a limit to the number of margin notes using Marginalia?

In my Recipe project, which uses Marginalia for margin notes, and is formatted book-style, I have just added four more recipes, two of which have margin notes. The whole PDF runs to 82 pages including the bibliography, with 33 margin notes on the left (verso pages) and 24 on the right (recto pages).

However I am getting warnings of non-convergence now, on both the web-app and Edist… this one on the web-app:

Beyond that. the web-app doesn’t help me at all as it takes me to long strings of layout metrics that I cannot relate to anything.

The same warning on Edist however, takes me to these lines of the Marginalia code:

Since the text seems to have compiled correctly in spite of the warnings, with no reported errors, I am completely in the dark about why I am getting the warnings or where to look to try and resolve them.

Any suggestions or advice would be most welcome.

:slight_smile:
Mark

I have a similar issue with my template bookly. There are several possible issues: the main culprit seems to be book:true. Do you try with book:false. keep-order and shift can also have an influence on the layout convergence.

I had AI take a closer look at the Marginalia source, so I definitely don’t want to take credit for this or pretend I know the package well. I don’t actually use Marginalia myself.

The interesting thing it found is that this probably isn’t a hard limit on the number of margin notes. The warning seems more related to how Marginalia stores note positions in the document-wide _note_extends_left / _note_extends_right states and then reads them back with .final().

Because those states contain information for all pages, a note on one page can end up depending on the final state of notes much later in the document. In a large document, that can apparently make Typst need more layout iterations than the five it allows before reporting non-convergence.

AI suggested that a smaller-scope state, for example one state per page and side, might reduce that dependency quite a bit. Something along the lines of:

let extends = state(
  "_marginalia_note_extends_" + side + "_" + page_num,
  (),
)

instead of keeping all pages in the same _note_extends_left / _note_extends_right dictionary.

I also tested the general idea with the Typst CLI on a synthetic 82-page document with lots of margin notes, and a page-local version converged without warnings. So at least from that test, there doesn’t seem to be a fixed limit such as 33 notes.

Again, this is mostly an AI-assisted investigation rather than me knowing the internals of Marginalia, so please take it as a possible lead rather than a definitive diagnosis. It might be useful to the package author though.

Apologies for the late response.

@maucejo, thank you for your comment; I appreciate it. I’ll try setting it to book: false to see what happens, but I really do want it to print recto-verso… I will send PDFs to members of the family when I’ve done some more (I still need to sort out page headers and numbering on the Outline pages first).

@Sovichea. thank you too for your input, which is much appreciated. I hope that @nleanba will see this thread. I am no coder so would have no idea how to edit the Marginalia package to include that suggestion, so can only hope that, as the author/maintainer, @nleanba will look at it.

:slight_smile:
Mark

Hi, thanks for tagging me :D

Yes, there is no fixed or hard limit on the number of notes, but the situation you encounter can sometimes happen in large documents. I have tried before to try and find a cause, but it proves hard to debug. (I will try again once i have some time to work on it. Splitting the states as suggested might be useful)

I have some thoughts which might help for now:

  • It is very rare that the warning actually leads to notes in the wrong location. This is because the algorithm tries very hard to not have a cyclic calculation (hence the use of “.final” for example). (This is also what makes it hard to debug, because its difficult to see where the divergence happens)
  • In my experience, this situation sometimes happens if there is an “unstable” page break somewhere, which leads to notes switching between pages and messing with the state (as it depends on where the notes are anchored. This means it can help to add manual page breaks near such locations to help typst stabilise those first. (I’ve encountered this for example with a table of contents which only very barely fits onto the page, and during compilation iterations it switches between spilling over to the enxt page and not)

I’m sorry for the inconvenience, and i hope i will figure out a way to make this happen less once exam season is over

4 Likes

Hello,

Thanks for coming in on this.

  • None of the notes are in the wrong location, thus far.
  • I don’t know of any “unstable pagebreaks”; I don’t think any of the notes are linked to a line immediately preceding or following a pagebreak.

Let me know when your exam season is over and you get back to it. If it would help, I’d be willing to let you access the project.

:slight_smile:
Mark