Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

li marker position issue when a superscript is present. #2253

Open
kesara opened this issue Sep 16, 2024 · 4 comments
Open

li marker position issue when a superscript is present. #2253

kesara opened this issue Sep 16, 2024 · 4 comments
Labels
bug Existing features not working as expected

Comments

@kesara
Copy link
Contributor

kesara commented Sep 16, 2024

The marker position for li differs when sup (superscript) is present. There are no such issues with sub (subscript).

Example screenshots:
Screenshot 2024-09-16 at 22 51 23
Screenshot 2024-09-16 at 22 51 31

Test HTML:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <title>li marker position test</title>
  </head>
  <body>
    <h1><code>li</code> marker position test</h1>
    <h4>List <code>ul</code> 0</h4>
    <ul>
      <li>This list has an ordinary line.</li>
    </ul>
    <h4>List <code>ul</code> 1</h4>
    <ul>
      <li>This list has a <sup>superscript</sup>.</li>
    </ul>
    <h4>List <code>ul</code> 2</h4>
    <ul>
      <li>This list has a <sub>subscript</sub>.</li>
    </ul>
    <h4>List <code>ul</code> 3</h4>
    <ul>
      <li>This list has an ordinary line.</li>
      <li>This list has a <sup>superscript</sup>.</li>
      <li>This list has a <sub>subscript</sub>.</li>
      <li>This list has another ordinary line.</li>
    </ul>
    <h4>List <code>ol</code> 0</h4>
    <ol>
      <li>This list has an ordinary line.</li>
    </ol>
    <h4>List <code>ol</code> 1</h4>
    <ol>
      <li>This list has a <sup>superscript</sup>.</li>
    </ol>
    <h4>List <code>ol</code> 2</h4>
    <ol>
      <li>This list has a <sub>subscript</sub>.</li>
    </ol>
    <h4>List <code>ol</code> 3</h4>
    <ol>
      <li>This list has an ordinary line.</li>
      <li>This list has a <sup>superscript</sup>.</li>
      <li>This list has a <sub>subscript</sub>.</li>
      <li>This list has another ordinary line.</li>
    </ol>
  </body>
</html>

Sample PDF generated with WeasyPrint 62.3:
li.pdf

@kesara
Copy link
Contributor Author

kesara commented Sep 16, 2024

This is a non-issue when the sup is not present in the first line.
Screenshot:
Screenshot 2024-09-16 at 23 01 58

@liZe liZe added the bug Existing features not working as expected label Sep 16, 2024
@liZe
Copy link
Member

liZe commented Sep 16, 2024

Thanks a lot for the bug report and the examples.

@kesara kesara changed the title li market position issue when a superscript is present. li marker position issue when a superscript is present. Sep 16, 2024
@liZe
Copy link
Member

liZe commented Sep 16, 2024

This bug appears because in WeasyPrint, markers are absolutely positioned boxes: vertically they are positioned to be on the left of the content of the li box, and horizontally to be aligned with the top of the content box of the li box.

Both positions are wrong in some cases. Horizontally, it’s explained in #1557, padding breaks the assumption. And vertically, well … you’ve just found the bug.

Subscript doesn’t break the rendering because we still want to put the marker at the top of the li box in this case.

The clean solution would be to position markers manually, not using some dirty hidden CSS rules. We can actually do what we want, as "CSS does not specify the precise location of the marker box or its position in the painting order", but we should try to manually do what other browsers do.

A workaround is to add line-height: 0 to superscript text, it works well with rather high line-height values. It should be the default in my opinion, otherwise lines with superscript are taller than other lines. But that’s not what other browsers do, so we’re stuck with this.

@kesara
Copy link
Contributor Author

kesara commented Sep 17, 2024

@liZe Thanks for the explanation and workaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Existing features not working as expected
Projects
None yet
Development

No branches or pull requests

2 participants