pdfpc export does not use correct page labels

[tingerrr]

Touying uses LogicalPage pdfpc metadata to identify which slide a speaker note goes to such that a note is associated with the correct slide, regardless of animation. However, these labels refer to the labels in the PDF specified by /PageLabels. Typst will export these only if page.numbering is set to a valid numbering pattern, i.e. arabic, roman, alphabetic (see page.rs).

Touying doesn't seem to ever set page.numbering to anything, which means that the labels are not exported. This, in turn, means that pdfpc (among many other readers) assumes the default labels of 1, 2, 3, ..., which, combined with the logical numbering assumed by touying will cause pdfpc to associate the notes to the incorrect slides once any animations are involved. (Here's a relevant upstream issue on the pdfpc repo)

I've patched touying locally to write the label when it encounters a Idx pdfpc metadata like so:

--- src/pdfpc.typ	2024-10-14 13:38:47.640696159 +0200
+++ src/pdfpc.typ	2024-10-18 09:44:21.940388007 +0200
@@ -23,8 +23,10 @@
     for item in slide {
       if item.t == "Idx" {
         page.idx = item.v
+        // NOTE: fix for lacking /PageLabels export of typst, resulting in incorrect page labels
+        page.label = str(item.v + 1)
       } else if item.t == "LogicalSlide" {
-        page.label = str(item.v)
+        // page.label = str(item.v)
       } else if item.t == "Overlay" {
         page.overlay = item.v
         page.forcedOverlay = item.v > 0

This would not work, if a user sets the numbering themselves, but I included it as a workaround for others who may need a fix. I believe, touying must retrieve page.numbering to set the correct labels when placing LogicalSlide and fallback to Idx + 1 where it is none, but I have no time to create a PR for this right now.

If this patch causes conflicts or other problems for you, I've applied this to 0.5.2 because I ran into a regression with 0.5.3, which I want to come back to next week.

[robamler]

A very simple fix for this issue that doesn't require any patching is to set page-config(numbering: "1").

• Theme authors can do this directly in the theme when inheriting from touying-slides (i.e., in the statement show: touying-slides.with(...) in the definition of their theme).
• Users of themes which don't implement this fix can provide page-config(numbering: "1") as an additional argument in the statement #show: ⟨theme-name⟩.with(...) that's usually near the top of a presentation.

You might also want to specify a different numbering style for the title page (e.g., page-config(numbering: "i")). Otherwise, the title page will end up getting the same number as the first slide following it (assuming the function title-slide sets config-common(freeze-slide-counter: true), which seems to be common).

IMO it would be great to include this fix in the next version of official themes, and to maybe document it in the "Build Your Own Theme" section of the tutorial because many theme authors will probably not be aware of the effect that setting a page numbering style has in some PDF viewers. Apart from lining up presenter notes with slides, this fix also ensures that drawings with the pen tool in pdfpc persist across subslides within each slide. Without this fix, the pen tool in pdfpc is essentially unusable in touying presentations because anything you draw on a slide will disappear as soon as the next part of a slide gets revealed.