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.

Sign up for GitHub

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

Jump to bottom

input type="hidden" takes up space in PDF #1471

Closed
Christoph-Wagner opened this issue Oct 14, 2021 · 1 comment
Closed

input type="hidden" takes up space in PDF #1471

Christoph-Wagner opened this issue Oct 14, 2021 · 1 comment
Labels
bug Existing features not working as expected
Milestone
53.4

Comments

@Christoph-Wagner
Copy link

Christoph-Wagner commented Oct 14, 2021 •
edited
Loading

I upgraded from Weasyprint 51 to the current 53.3 and there was suddenly a new page at the beginning of the document:

image

After some testing, I narrowed it down to <input type="hidden">-fields.

2 Examples:

Correct (1 page) test-correct.pdf:

<!DOCTYPE html>
<html>
  <head>
    <title>Title</title>
    <style>
      @page {
        size: A5 portrait;
      }
      #intro {
        page: Intro;
        height: 210mm;
      }
    </style>
  </head>
  <body>
    <div id="intro">
      <h1>Headline</h1>
    </div>
  </body>
</html>

Wrong (2 pages) test-wrong.pdf:

<!DOCTYPE html>
<html>
  <head>
    <title>Title</title>
    <style>
      @page {
        size: A5 portrait;
      }
      #intro {
        page: Intro;
        height: 210mm;
      }
    </style>
  </head>
  <body>
    <input type="hidden" />
    <div id="intro">
      <h1>Headline</h1>
    </div>
  </body>
</html>

This is not important for me as I can luckily remove those fields, the only reason they are even there is that we use ancient and deprecated asp.net webforms technology. But I thought I should at least report it ;)

The correct behavior would be for input type="hidden" to be completely ignored.

In case it matters, this is on Windows.
@liZe liZe closed this as completed in eebb6e5 Oct 14, 2021
@liZe
Copy link
Member

liZe commented Oct 14, 2021

Thanks a lot for the bug report! As you can see in eebb6e5, the fix was quite easy 😉.

@liZe liZe added the bug Existing features not working as expected label Oct 14, 2021
@liZe liZe added this to the 53.4 milestone Oct 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Existing features not working as expected
Projects
None yet
Milestone
53.4
Development

No branches or pull requests
2 participants
@liZe @Christoph-Wagner