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

<div> block split #467

Closed
chickendude opened this Issue May 13, 2017 · 5 comments

Comments

Projects
None yet
2 participants
@chickendude

chickendude commented May 13, 2017

I'm trying to build a PDF of a text with word for word translations where some short phrases need longer idiomatic translations underneath. The format works well on browsers like Firefox/Chrome, but when i print to a PDF many of the idiomatic translations get split down the middle and take up two rows. I've attached a PDF of the output as well as the HTML + CSS markup used to generate it.

The first picture is what i see in Firefox, the second picture is from the PDF (You can see the 'nolakoa den ulertzeko' bit is split in the middle across two lines). Any ideas on how to get around this? I've solved all other issues i had (namely setting up the Table of Contents where i first run each chapter individually, count the number of pages in each chapter, create the table of contents page, build the whole book, and finally combine the title page, table of contents, and actual book contents into one PDF). Thanks for the amazing tool, if i can just figure this one last thing out, it'll be perfect (for me, at least ;) )!

picture 1 (correct)
correct
picture 2 (incorrect - see 'nolakoa den ulertzeko' section)
incorrect

template.pdf
template.txt

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe May 13, 2017

Member

I've got bad news.

This bug is related to the shrink-to-fit width of some inline blocks, its been fixed with awful solutions many times, but it will only be really fixed with #301.

If you want more information, you can check 902f5e2 and its related issues, it gives a pretty good idea of what the problem is. This issue is a bit different, as changing the value of the hack doesn't fix the issue, but the idea is the same:

  • floating point errors accumulate, and
  • we compute the shrink-to-fit width of inline blocks with some values coming from Pango, these values are not exactly the same depending on where the text is displayed on the page, and sometimes we don't get the width of the text at the place it will be really displayed.
Member

liZe commented May 13, 2017

I've got bad news.

This bug is related to the shrink-to-fit width of some inline blocks, its been fixed with awful solutions many times, but it will only be really fixed with #301.

If you want more information, you can check 902f5e2 and its related issues, it gives a pretty good idea of what the problem is. This issue is a bit different, as changing the value of the hack doesn't fix the issue, but the idea is the same:

  • floating point errors accumulate, and
  • we compute the shrink-to-fit width of inline blocks with some values coming from Pango, these values are not exactly the same depending on where the text is displayed on the page, and sometimes we don't get the width of the text at the place it will be really displayed.

@liZe liZe added feature bug and removed feature labels May 13, 2017

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe May 13, 2017

Member

By the way, for your example, a good solution would be to implement flexbox (see #324), that would help you to get the same result with better HTML and CSS 😉.

Member

liZe commented May 13, 2017

By the way, for your example, a good solution would be to implement flexbox (see #324), that would help you to get the same result with better HTML and CSS 😉.

@chickendude

This comment has been minimized.

Show comment
Hide comment
@chickendude

chickendude May 14, 2017

Ah, thanks, do you see a solution or alternative way of implementing it to get the same output? If I understand correctly, flexbox hasn't been implemented yet, right? I'm afraid I wouldn't know how to go about implementing it myself (but wouldn't be against financing/paying for someone else to implement it if it'd help other users as well). I've never actually used flexbox either. I'll look into the links you provided, perhaps I can hack something together that'll work for my use case. Thanks again for the help, @liZe

chickendude commented May 14, 2017

Ah, thanks, do you see a solution or alternative way of implementing it to get the same output? If I understand correctly, flexbox hasn't been implemented yet, right? I'm afraid I wouldn't know how to go about implementing it myself (but wouldn't be against financing/paying for someone else to implement it if it'd help other users as well). I've never actually used flexbox either. I'll look into the links you provided, perhaps I can hack something together that'll work for my use case. Thanks again for the help, @liZe

@liZe liZe closed this in 78f0d7f May 14, 2017

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe May 14, 2017

Member

For the record, here's an simple example that shows the problem for me (with DejaVu Serif as default font):

<style>
  @page { margin: 1.2cm }
  body { display: inline-block }
</style>
nolakoa <span>in order to understand</span>

Playing with the page margin makes the text fit in one line (correct rendering) or in two lines (wrong).

@chickendude I've found where the problem comes from and I've moved the hack from text.split_first_line to inline.split_inline_box, to make it work with inline blocks (your case) as it was working with letters (the common case). You can take a look at 78f0d7f for the details.

I think that it fixes your problem, even if I can't exactly reproduce it myself. I hit another rendering problem (coming from the same reason) that is fixed with this commit. The simple example above is fixed too for me.

Member

liZe commented May 14, 2017

For the record, here's an simple example that shows the problem for me (with DejaVu Serif as default font):

<style>
  @page { margin: 1.2cm }
  body { display: inline-block }
</style>
nolakoa <span>in order to understand</span>

Playing with the page margin makes the text fit in one line (correct rendering) or in two lines (wrong).

@chickendude I've found where the problem comes from and I've moved the hack from text.split_first_line to inline.split_inline_box, to make it work with inline blocks (your case) as it was working with letters (the common case). You can take a look at 78f0d7f for the details.

I think that it fixes your problem, even if I can't exactly reproduce it myself. I hit another rendering problem (coming from the same reason) that is fixed with this commit. The simple example above is fixed too for me.

@liZe liZe added this to the v0.37 milestone May 14, 2017

@chickendude

This comment has been minimized.

Show comment
Hide comment
@chickendude

chickendude May 15, 2017

liZe, just tested this out on my local and web server, works great! Thanks for the quick response/fix!

chickendude commented May 15, 2017

liZe, just tested this out on my local and web server, works great! Thanks for the quick response/fix!

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Aug 1, 2017

kleink
Update py-weasyprint to 0.39.
Version 0.39
------------

Released on 2017-06-24.

Bug fixes:

* Fix the use of WeasyPrint's URL fetcher with CairoSVG.


Version 0.38
------------

Released on 2017-06-16.

Bug fixes:

* `#477 <https://github.com/Kozea/WeasyPrint/issues/477>`_:
  Don't crash on font-face's src attributes with local functions.


Version 0.37
------------

Released on 2017-06-15.

WeasyPrint now depends on tinycss2 instead of tinycss.

New features:

* `#437 <https://github.com/Kozea/WeasyPrint/issues/437>`_:
  Support local links in generated PDFs.

Bug fixes:

* `#412 <https://github.com/Kozea/WeasyPrint/issues/412>`_:
  Use a NullHandler log handler when WeasyPrint is used as a library.
* `#417 <https://github.com/Kozea/WeasyPrint/issues/417>`_,
  `#472 <https://github.com/Kozea/WeasyPrint/issues/472>`_:
  Don't crash on some line breaks.
* `#327 <https://github.com/Kozea/WeasyPrint/issues/327>`_:
  Don't crash with replaced elements with height set in percentages.
* `#467 <https://github.com/Kozea/WeasyPrint/issues/467>`_:
  Remove incorrect line breaks.
* `#446 <https://github.com/Kozea/WeasyPrint/pull/446>`_:
  Let the logging module do the string interpolation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment