WeasyPrint icon indicating copy to clipboard operation
WeasyPrint copied to clipboard

Position of list marker is wrong after a page break

Open craigbass76 opened this issue 5 years ago • 4 comments

I'm not sure what the problem is here. When an ordered list is going over a page break, the text is bumped up a bit. See list item #4. list-over-page-break

I was trying to manually put a page break in there, but then this item#4 kept becoming a new Item#1.

craigbass76 avatar Feb 11 '20 17:02 craigbass76

Is there a workaround for the time being?

craigbass76 avatar Feb 19 '20 21:02 craigbass76

If it helps, it looks like this only happens with the list item in question is more than a line long.

No, scratch that. I got my hopes up...

craigbass76 avatar Feb 24 '20 15:02 craigbass76

Some problem here. I have produced a minimal example: the problem seems to occur (both with ordered and unordered lists) when the item contains a paragraph:

<li><p>List item</p></li>

but not if the item cointains only text:

<li>List item</li>

Perhaps this will help to hunt down the bug?

GiovanniSalmeri avatar Jul 26 '20 18:07 GiovanniSalmeri

I got the same problem. If an <ol> or an <ul> contains <li><p>...</p></li> elements, then the bullet or the number is not aligned on the first list item after a page break.

I wonder if it is related to this behavior which looks like a bug: On a document without custom CSS, the first page top margin is bigger than all other top margins in the document and the difference is the height of one line.

Anyway, here is a (quite convoluted) workaround. It seems to work even with nested lists. I usually use it to replace bullets with the characters I want in <ul>. This CSS removes the actual number or bullet and replaces it with a counter or a character.

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8" />
    <title>OL UL BUG</title>
    <style>
        ol,
        ul {
            counter-reset: list-item-counter;
            list-style-type: none;
        }

        ol li p,
        ul li p {
            counter-increment: list-item-counter;
            text-indent: -2.0rem; /* must be equal to -width (see below) */
        }

        ol li p::before,
        ul li p::before {
            display: inline-block;
            left: -0.16rem;
            margin: 0;
            padding: 0;
            position: relative;
            text-align: right;
            width: 2.0rem;
        }

        ol li p::before {
            content: counter(list-item-counter)".";
        }

        ul li p::before {
            content: "•";
        }

    </style>
</head>

<body>
    <ol>
        <!--
            Copy-paste this line 50 × so that the list takes more than one page.
            Generate the PDF with and without the CSS above to see the difference.
         -->
        <li><p>Lorem</p></li>
    </ol>
</body>

</html>

NicHub avatar Nov 10 '20 21:11 NicHub

Hello @liZe

I have just tested it with WeasyPrint 58.1 , the behaviour is still the same for me.

image

fabiobatalha avatar Mar 27 '23 20:03 fabiobatalha

Hello @fabiobatalha,

Could you please share the related HTML/CSS files?

grewn0uille avatar Mar 27 '23 20:03 grewn0uille

Hello @grewn0uille

The example!

sample.zip

fabiobatalha avatar Mar 27 '23 20:03 fabiobatalha

Hi @fabiobatalha

Your bug is different from this issue, it’s not related to page breaks at all.

The bullet’s position is "wrong" because you have a different line height for li (18px) and li p (1.2em). The marker is aligned according the li box’ line height, but the text of the paragraph is not (because it’s a block, not an inline text).

Even if the rendering is not optimal in this specific case, I’m not sure that the real position is defined by the specifications, so may not technically be a bug. You can easily change the line height of the marker if you want to use different line-heights for your li tags and their content. Something like ::marker { line-height: 1 } will give you what you want.

If you think that this problem is a real bug (ie there’s something about the vertical alignment of markers in the specifications), you can open a new issue. Otherwise, we can consider that this is an implementation detail, and setting the marker’s line height is the way to go.

liZe avatar Mar 28 '23 12:03 liZe

Hi @liZe

Thanks for the response. I will try to fix it in the css following your highlights.

My point of view of a "bug" is more related to the "Wysiwyg" aspect of the conversion from HTML to PDF, once in the HTML preview the bullets are well placed.

fabiobatalha avatar Mar 28 '23 13:03 fabiobatalha

My point of view of a "bug" is more related to the "Wysiwyg" aspect of the conversion from HTML to PDF, once in the HTML preview the bullets are well placed.

I agree, web browsers seem to behave the same "correct" way, so it’s possibly a real bug. Even if you can get what you want with CSS, you can open a new issue with your example attached, we’ll find the time to read the specifications in the future to find what’s the correct behavior.

liZe avatar Mar 28 '23 13:03 liZe

Hello For me the bad positioning was more about inside elements I fix it with ol > li > p { display: block; }

  • ::marker { line-height: 1 }

bonnebulle avatar May 20 '23 07:05 bonnebulle