this question is relevant to the full-issue pdf files of tugboat, as made available for electronic reference or download. all articles are always posted individually, but a single front-to-back pdf file is much more convenient for downloading.

a single issue of tugboat will always contain items prepared with plain tex, pdflatex and usually xetex, and there may also be items prepared with context or otherwise requiring lua(la)tex. thus it is impossible to prepare a full issue as an unbroken unit. also, the table of contents is always on the back cover.

a recent (sensible) suggestion was to package the electronic issue with the toc at the front, followed by the rest of the contents in the same order as the print edition.

the tool now used to package the full-issue pdf is ghostscript [9.21]. this merely concatenates the separate article files. it does not create bookmarks or any links; to add these would place an unreasonable burden on an already overworked volunteer.

after issue 38:2 was packaged in this manner, i noticed while checking the pdf that the page numbers indicated in the box between the navigation arrows and the "page mm of nnn" message did not correspond to the numbers on the actual pages. since one purpose of a toc is to show starting page numbers, the ability to type in a page number to access a particular item directly is highly desirable.

i use acrobat to read pdf files; karl berry, who prepares the output files, does not, and when i mentioned this disconnect, he didn't know what i was referring to -- his pdf reader, xpdf [v.3], displays the page information in a somewhat different way.

finally, the question: what (freeware) tools are available for which at least a starting page number can be specified so that the logical page number of a page in the pdf file will be the same as the page number shown on the page image as viewed on the screen?

addendum: in response to a (now deleted) comment asking why we don't ask for source files for tugboat submissions, we do! the whole excruciating process of putting together a tugboat issue has been detailed in the "production notes" column that appears in the TUG@BachoTeX 2017 proceedings issue. (this link goes to the issue toc; the referenced article appears on page 263.)

addendum #2: in answer to a request for details on how the page numbers appear in the two mentioned browsers, here they are:
- xpdf: Page 1 of 183
- acrobat: 284 (1 of 183)
the arrangement of pages in the file is as follows:
  cover 4 (toc), cover 2, 109 (title page) - 288. cover 3

  • 2
    Exactly ho are the pdf merged? Does the online version contain hyperlinks? Are there any data others (members perhaps) can play with? And at least learn new tricks. I usually use pdfpages but that might not be flexible enough. – daleif Sep 7 '17 at 16:33
  • A few of the articles are already accessible without TUG membership, including the referenced article on TUGboat “Production notes”. It mentions “To do the concatenation, we’ve used a variety of tools, most commonly Ghostscript and pdfjam (ctan.org/pkg/pdfjam) of late. ConTEXt and pdftk have also been useful. Different tools are needed as years go by and software and systems change (for no convincing reason).” I think it would be worth mentioning exactly what was the discrepancy seen between the page numbers, in acrobat and in xpdf. – ShreevatsaR Sep 7 '17 at 16:52
  • we have some success at converting to postscript, adjusting links, (eg changing cross document links to internal links within the concatenated files) just using sed, then making some other sed script replacements and then distilling the whole lot back to pdf. – David Carlisle Sep 7 '17 at 18:05
  • I don't quite understand. The numbers of the content pages are running from 109-288, yet you want the numbers Karl sees, which run from 1-183 rather than (the admittedly even more confusing) 284 (1 to 183) - what? Is the last page 288+183 (183 of 183)? – cfr Sep 7 '17 at 22:38
  • 2
    @cfr -- the contents page (the first page in the concatenated pdf file) is cover 4 of the print version; it has not been redone for the electronic file. the second page is cover 2 of the print version. the third page is the title page of the issue which has the assigned number 109, but this number is not printed. ordinary numbered pages (from the print version) run from 110-288, and cover 3 is the last page in the concatenated file. the total number of pages is 183. (issue 1 had 108 pages, and the printed page numbers run continuously through the year.) is this clearer now? – barbara beeton Sep 8 '17 at 2:23

Page labels are added as array in the /Catalog of the PDF file. Since the PDF file is generated by ghostscript, it can be set by the pdfmark operator in a PostScript file and added to the input files for ghostscript, for example:

gs -sDEVICE=pdfwrite -dBATCH -dNOPAUSE -sOutputFile=combined.pdf pagelabels.ps file1.pdf file2.pdf file3.pdf

File pagelabels.ps:

  {Catalog} <<
    /PageLabels <<
      /Nums [
        0 << /P (cover ) /S /D >>
        2 << /S /D /St 109 >>
        182 << /P (cover 3) >>
/PUT pdfmark

The following syntax elements of PDF are needed:

  • Numbers (0, 2, 109, 182)
  • Names are preceded by a slash (/PageLabels, /P, /S, /D, /St)
  • Strings can be given in parentheses ((cover ), (cover 3)).
  • Arrays use square brackets as delimiters ([ ... ]). The array elements can be of any object type.
  • Dictionaries use double angle brackets (<< ... >>). They contain key-value pairs. The keys are always names, values can be any object. For example, the fourth object in the /Nums array is a dictionary << /S /D /St 109 >>) with two keys /S and /St. Values are /D for key /S and 109 for key /St.
  • Comment character is % as in TeX.

The elements in the /Nums array in the dictionary /PageLabels declare the page labels. A zero-based index is followed by a dictionary defining the page labels for the pages starting with this page. The keys in the dictionary:

  • /P specifies a prefix.
  • /S sets the style for the page number. The styles with their LaTeX equivalents:

    • /D\arabic
    • /R\Roman
    • /r\roman
    • /A\Alph
    • /a\alph
  • /St sets the start page, default is 1.

The specification from above generates the following page labels:

  • 0 << /P (cover ) /S /D >>:

    • Page 1: cover 1
    • Page 2: cover 2
  • 2 << /S /D /St 109 >>:

    • Page 3: 109
    • Page 4: 110
    • ...
    • Page 182: 288
  • 182 << /P (cover 3) >> or 182 << /P (cover ) /St 3 >>:

    • Page 183: cover 3

Further reading:

However, page labels are not supported by all PDF viewers.

  • Viewers with support for page labels:

Hint: Some viewers (Okular, for example) do not reserve much space for the labels. The labels should be pretty short to prevent the need for horizontal scrolling to see all of the label.

  • Viewers without support, that only show the absolute page number:

    • xpdf v3.04
    • Google Chrome (builtin viewer) v61
  • If you know, could you add Okular to the appropriate list since it is the equivalent of Evince on KDE-based systems? – cfr Sep 8 '17 at 1:21
  • @cfr I have tried the Cygwin port of Okular, version 17.04. The loading time of about 70 seconds is much too slow for practical usage. Also the place for the page labels is pretty small, only about four chars can be seen without the need for scrolling, even if there is more than enough place left and right of the page number display. – Heiko Oberdiek Sep 8 '17 at 7:21
  • Okular is my default PDF viewer .... But I am running it on a different OS, I guess. – cfr Sep 8 '17 at 13:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.