[luatex] subtle bug in generating PDF outlines

[luigi scarso]

On Sun, 5 Jan 2025 at 20:23, luigi scarso <luigi.scarso at gmail.com> wrote:

>
>
> On Sun, 5 Jan 2025 at 17:03, Werner LEMBERG <wl at gnu.org> wrote:
>
>>
>> > The key point is that with qpdf one can edit the *qdf* file (i.e
>> > notation.qdf in our case) and call
>> >
>> >   fix-qdf notation.qdf > notation-edited.pdf
>> >
>> > to have a pdf.
>>
>> OK – I hope you can find and fix the problem easily.  If this doesn't
>> work I can provide a large tarball with all of the necessary LilyPond
>> input files.
>>
>
> hm, iiuc this is the problem
>  45201 0 obj
> <<
>   /Names [ (Gregorian accidentals and key signatures) 1731 0 R
>       (Gregorian articulation signs) 1733 0 R (Gregorian chant contexts)
>       1729 0 R (Gregorian clefs) 1730 0 R (Gregorian square neume
> ligatures)
>       1840 0 R (Grid lines) 1231 0 R (Grouping staves) 1206 0 R
>       (Guile predicates) 2649 0 R (Guitar) 1542 0 R (Harmonics)
>       1530 0 R (Harp) 1523 0 R (Harp pedals) 1525 0 R (Hidden notes)
>       1223 0 R (Hiding staves) 1212 0 R (Horizontal spacing) 2190 0 R
>       (Horizontal spacing overview) 2191 0 R (Horizontal spacing paper
> variables)
>       2158 0 R (How to prevent sharing of music expressions) 2012 0 R
>       (Hufnagel glyphs) 2509 0 R (Improvisation) 905 0 R (Incipits)
>       1849 0 R (Including LilyPond files) 2004 0 R (Indicating harmonics
> and dampened notes)
>       1544 0 R (Indicating position and barring) 1543 0 R (Indicating
> power chords)
>       1545 0 R (Input modes) 1875 0 R (Input structure) 1876 0 R
>       (Inside the staff) 1219 0 R (Instantiating new staves) 1205 0 R
>       (Instrument-specific markup) 2623 0 R (Instrument-specific scripts)
>       2633 0 R (Instrument names) 1214 0 R ]
>   /Limits [ (Gregorian accidentals and key signatures) (Instrument names) ]
> >>
> endobj
> the keys of /Names are not correctly sorted,
>
>
> /*tex Sort |dest_names| by names: */
>
> static int dest_cmp(const void *a, const void *b)
> {
>     dest_name_entry aa = *(const dest_name_entry *) a;
>     dest_name_entry bb = *(const dest_name_entry *) b;
>     return strcmp(aa.objname, bb.objname);
> }
>
> void sort_dest_names(PDF pdf)
> {
>     qsort(pdf->dest_names, (size_t) pdf->dest_names_ptr,
> sizeof(dest_name_entry), dest_cmp);
> }
>
> /*tex
>
>     Output the name tree. The tree nature of the destination list forces
> the
>     storing of intermediate data in |obj_info| and |obj_aux| fields, which
> is
>     further uglified by the fact that |obj_tab| entries do not accept char
>     pointers.
>
> */
>
> int output_name_tree(PDF pdf)
> {
>     /*tex A flag for name tree output: is it |/Names| or |/Kids|: */
>     boolean is_names = true;
>     /*tex
>         The index of current child of |l|; if |k < pdf_dest_names_ptr|
> then this
>         is pointer to |dest_names| array; otherwise it is the pointer to
>         |obj_tab| (object number).
>     */
>     int k = 0;
>     int b = 0;
>     int m, j, l;
>     int dests = 0; sort_dest_name
>     int names_head = 0;
>     int names_tail = 0;
>     if (pdf->dest_names_ptr == 0) {
>         goto DONE;
>     }
>     sort_dest_names(pdf);
>

(sorry , I pushed  Send too quickly...)
The /Names are not correctly sorted , but output_name_tre in pdfdest.c
calls sort_dest_name.

Can you provide me with the tarball so that I can check it ?

--
luigi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/luatex/attachments/20250105/95d34266/attachment.htm>