Kozea / WeasyPrint

The awesome document factory
https://weasyprint.org
BSD 3-Clause "New" or "Revised" License
7.14k stars 681 forks source link

Upgrading to Weasyprint version greater than 0.42.3 causes changes in css handling #1157

Closed jonathlt closed 3 years ago

jonathlt commented 4 years ago

Since version 43 we seem to be seeing an issue rendering pdfs.

The pdf generated is as follows, where you can see that the map.png image file is not rendered and the styling is not as we were seeing in previous versions. The source html file renders OK in the chrome web browser.

Version 43

a4-portrait-not-working.pdf

Compare with what we were previously seeing using version 0.42.2 and 0.42.3, this renders the pdf correctly as follows:

Version 0.42.2/0.42.3

a4-portrait-working.pdf

Looking into the issue, we can get the pdf to render as expected by changing one of our files, common.css, see the commented out code where I have removed a couple of css rules. So there seems to be a problem with using the height directive in .wrapper and the display:flex one in #map

html 
{
    padding: 0;
    margin: 0;
    transform-origin: top left;
    overflow: hidden;
}

body 
{
    margin: 0;
    padding: 0;
}

h1
{
    font-size: 100%;
    margin: 0;
}

#title
{
    padding: 1mm 0 0 0;
    font-size: 14pt;
    font-weight: bold;
    font-family: Arial;
}

#title > input
{
    border: 1px solid #000;
    padding: 0;
    width: 300px;
    font-size: 14pt;
}

#footer
{
    font-size: 10pt;
    background: #FFF;
}

#logo
{
    margin: 1mm 0 2mm;
    height: 8mm;
}

img#mapimg
{
    margin: 0;
    max-width: 100%;
    max-height: 100%;
}
img#north
{
    max-width: 9mm;
    max-height: 9mm;
    margin: auto;
}
#map
{
    border-width: 0.5mm 0.5mm 0;
    border-color: black;
    border-style: solid;
    /* display: flex; */
    width: inherit;
    flex-shrink: 1;
    position: relative;
    overflow: hidden;
}
#legend
{
    position: absolute !important;
    bottom: 0 !important;
    right: 0 !important;
    z-index: 1000;
    width: 200px;
}

#legend > img
{
    border-style: solid;
    border-color: #000;
    border-width: 0.5mm 0 0 0.5mm;
    display: block;
}
#legend.hidden
{
    display: none;
}

div#info
{
    padding: 2px;
    flex: 1;
}

div#organization
{
    position: absolute !important;
    top: 0px !important;
    right: 0px !important;
    z-index: 1000;
    margin-left: auto;
    padding: 1mm;
    flex: 0;
}

.wrapper
{
    max-width: 100%;
    /* height: 100%; */
    display: flex;
    justify-content: center;
}
.fWrapper
{
    border: 0.5mm solid;
    position: relative;
    display: flex;
    flex-direction: row;
}

.descale 
{
    transform-origin: top left;
}

Do you think this change in behaviour is a bug or is it by design? The issue for us is that we would have to change the css on many client machines to cope with the change in the weasyprint library. If not a bug and expected behaviour, would you be able to give us any advice as to how we might change our local copy of weasyprint to revert back to the previous behaviour?

I’ve attached a zip containing all html, css and images used, along with the test.py script used to generate the pdf.

wptesta4pgh.zip

Thanks for your time

liZe commented 4 years ago

Hello!

The problem is caused by a poor support of the flex layout. You can comment display: flex instead of height: 100% in .wrapper, you’ll get the right rendering.

Flex layout support wasn’t supported before version 43, that’s why it was working. It’s currently supported for simple use cases, but it may break in more complicated cases, like yours.

I don’t have an easy solution right now. I don’t know how you use WeasyPrint, but the library gives the possibility to use extra CSS files, using the Python API or the CLI. Maybe adding a stylesheet (with something like .wrapper, #map { display: block }) could solve your problem, before we solve this issue.

jonathlt commented 4 years ago

Hi, thank you for having a look into this for me, very helpful comments which may help us to find a workaround, I'll have a look at using an extra css file from the python API for now.