Whitespaces are correctly handled in bookmark labels

[gsnedders]

Something like:

        <h1>
            <span>Foo</span>,
            <span>
                Bar
            </span>
        </h1>

Seems to get turned into a bookmark with a label of:

            Foo,
            
                Bar

This is… unexpected, as it doesn't match the rendering at all. (i.e., I'd expect Foo, Bar with no more whitespace.)

I guess technically we probably want to take the white-space property into account here?

[Tontyna]

@gsnedders -- where does whitespace in bookmark labels distract you? My PDF reader's bookmark-tree is normalized by the readers, never ever realized that there was superfluous whitespace at all.
And why/where would the white-space property be of use?

Could create a PR which removes the whitespace, like that:

bookmark_label = ' '.join(bookmark_label.split())

[gsnedders]

@Tontyna In Okular they aren't normalised.

As for white-space, I was thinking of something like:

<h1><pre>foo
bar</pre></h1>

where it would seem semantically wrong to collapse the whitespace (and, of course, pre gets that behaviour purely based on the white-space property).

That said, that's mostly a hypothetical case; collapsing whitespace always would seem better than current given having a descendant of a heading with white-space set to something that isn't normal is decidedly unusual.

[Tontyna]

Not shure how to deal with this. The current implementation with all the space from the source included, conforms (almost) to the definition of textContent. Normalizing the whitespace and taking white-space into account would be innerText aka the element's text content "as rendered".

But I think none of the above is correct, the bookmark-label should contain the content(text) of the element, specified as

The string value of the element, determined as if white-space: normal had been set. This is the default value.

But. WeasyPrint's implementation of content(text) doesnt normalize whitespace. I'd say: Thats why @liZe added the bug-label. Am I right?

[liZe]

collapsing whitespace always would seem better than current given having a descendant of a heading with white-space set to something that isn't normal is decidedly unusual.

The spec actually says that white spaces have to be handled by CSS properties in <content-list>. A bit strange, but this case won’t happen in real cases.

The solution is simply to normalize white spaces before calculating bookmark labels (and named strings).