endless loop in table layout #660
Comments
Unfortunately, it's not for me. Could you try to reproduce with a free font instead of Helvetica/Arial? There's probably a problem with the columns, this feature is young and not widely used.
Using pdb may be useful, but it's hard to know where to put breakpoints when there's an endless loop. I'll try to explain how I would debug as soon as I can reproduce this error, I hope it'll help everyone to find a way to know what's going on… |
|
Another possibility: this bug may be a duplicate of #614 as you're using Windows. If you use Pango < 1.40.13 then it's pretty sure. |
|
Hey liZe! Thanks for looking into this. You are right, I'am running windows. But I just updated my GTK3 to the newest runtime dist and have now Pango 1.42.1.0. Sadly with the same endless loop. The same happens under MacOS X with all the latest dists through homebrew.. So this seems to be something new. I will try to create a situation with another font! |
|
.. trying to figure out a font that would be available for you. Would "Verdana" work? |
😢
Any font that's free and that I can easily download anywhere. Using Google Fonts' |
|
Can reproduce the issue. Will try to debug and catch... |
|
OMG! Its weird! Is this Cairo again? Akin to #628? |
|
It's not the Probably another discrepancy in the calculation of text-widths between ??? and ??? -- dunno yet, yes, looks like #614 and #585 , but that bug has been fixed... |
|
Hey Tontyna! Thanks for your digging! Cool, that you could reduce it further to the outside div. Concerning the double spans: In the non reduced file the spans of course have different classes and attributes. Yes, I could programmatically combine them. But as the double spans work with other content in between.. it must be the combination of things, like you pointed out. |
|
That's the output when I break the make_all_pages-loop:
Interestingly the opening bracket isn't repeated. |
|
Binary search of first problem occurrence in document after switching to DejaVu: <html lang="de">
<head>
<meta charset="utf-8" />
<title>All Truckgroups</title>
<style>
body {
margin: 1px;
font-size: 9pt !important;
font-family: DejaVu Sans, sans-serif;
}
.options {
column-count: 2;
column-gap: 3.5em;
margin-left: 1cm;
margin-right: 2cm;
}
table {
width: 100%;
border-spacing: 0;
border-collapse: collapse;
font-size: 0.9em !important;
}
table, td {
padding: 0;
margin: 0;
}
@media print {
@page {
size: A4;
margin: 0;
}
}
</style>
</head>
<body><div id="full">
<div class="options">
<div><span><span>Wenn der Schlauch angebracht ist, ist kein Herausheben der Batterie am NT-Mast
und für Hubhöhen ≤ 2.600 mm an TL/TF-Masten möglich</span></span><span><span>nicht verfügbar
bei NT Mast</span></span></div>
</div>
</div></body>
</html>Hope this is now reproducable everywhere? I downloaded and installed 2.37 of the ttf fonts from https://dejavu-fonts.github.io/Download.html Good night and good luck! And thank you! |
|
Eliminating the second double-span still results in an endless loop when the immediately following word is too long to fit into the same line: Separating the "xxx" from the double-span -- e.g. with a LF or a SPACE - prevents the infinite loop: Definitely a mutation of #614 |
|
@JohannesMunk : Thx. But this issue must be caught one level higher. I almost understand where it happens but am not (yet) able to fix it. Thats the situation: Since there is no SPACE or LF after the Watching resume_at/skip_stack in The above "30" is (as far as I understand) the first letter of the (successfully split) second text line, but next call to |
|
Minimal case: <div style="font-family: Ahem; width: 3.5em">
<span><span>xxx x x</span></span><span>x |
|
Good news: I've been saved by a comment 😉. Fix coming soon. |
|
@JohannesMunk @Tontyna Thanks a lot for your bug report, examples and hard work. The commit message and diff should be self-explanatory. This function is really tricky and quite recent (as it was modified to fix #163), that's why a lot of comments had been added. I would have spent days to fix this without this comment, that's another reason to add more (but not too many) as discussed in #659. |
|
Oh yes, remember having seen those grandchildren before. I didnt like them at all 😉 |
|
Hey you two! I just successfully generated 6 x 125 pages of PDFs!! Great stuff! Thanks a lot for your super nice and quick responses and fixes. Everything working now! I am impressed by the thorough regression tests! If you are interested I have another open issue concerning multiple columns and horizontal sizing of a table inside. I probably will be able to work around it, or shall I extract the problem and submit another issue for it? All the best and thank you again! Johannes |
😃
It looks like an awful problem, but I'd be happy to have a separate issue for that.
No problem! We currently have a tiny opinion survey open in #635, would you be interested in writing a little message? I'm curious about your 125-page documents 😉. |
|
Ah, the survey - isn't there a way to promote it? It's already buried in the open issues. Maybe via an issue template? |
Hello again!
Over the weekend I successfully boiled down another problem, that hunted us for a couple of weeks and prevents us outputting some files. As these files are pretty big, such a constellation as random it might seem, happens with a stubborn regularity.
This bug requires a specific layout situation with given widths and content. I hope it is reproducable on your side. On my side the following html does not convert, but instead weasyprint collects memory until it runs out of it, or the process is aborted..
I let this run in cProfile:
I dont know how to debug/step python. But what I read from the profile, is that iter_line_boxes is called a few times to often!
Let me know, if I can be of more assistance and thanks a lot in advance!
Johannes
The text was updated successfully, but these errors were encountered: