On Sat, 4 Jan 2025 at 18:14, Werner LEMBERG <w...@gnu.org> wrote: > > Folks, > > > please have a look at this Ghostscript bug report > > https://bugs.ghostscript.com/show_bug.cgi?id=708234 > > which describes in great detail how the PDF outline as constructed by > luatex contains a buglet: the mandatory `/Limits` array computes its > end element incorrectly, apparently not using 'lexical' (i.e, > byte-oriented) comparison. The thing is that some PDF viewers like > `evince` and `okular` seem to ignore the `/Limits` array (all links > work just fine), while `acrobat` does not, as explained in the report. > > This error does not happen with pdftex (from TeXLive 2024) – a > compilation of LilyPond's Notation Reference, followed by calling > > ``` > gs -dNOPAUSE -dBATCH -sDEVICE=pdfwrite \ > -sOutputFile=notation.pdfwrite.pdf notation.pdf > ``` > > doesn't report an error (I can send the resulting PDF to interested > people off-list). Note that the old PDF driver of GhostScript (from > version 9.52, for example) is not as strict as the current version and > the above call actually succeeds. > > I used versions the following versions. > > luatex: Version 1.18.0 (TeX Live 2024), Development id: 7611 > gs: self-compilation from current 'ghostpdl' git repository > mutool: self-compilation from current 'mupdf' git repository > > The uncompressed PDF version referenced in the bug report can be > created with > > ``` > mutool clean -d notation.pdf notation.uncompressed.pdf > ``` > > Alas, I don't know how to create a small input file that you can > actually use as a test – unfortunately, the creation process of the > LilyPond's Texinfo documentation is extremely complicated, making > simplifications a nightmare. > > Ok I am checking it now.
-- luigi
