Unwanted line-breaks in bold text #288

Closed
zopyx opened this Issue Dec 28, 2015 · 5 comments

Comments

Projects
None yet
2 participants
@zopyx

zopyx commented Dec 28, 2015

See the attached PDF/screenshot. There is an unwanted line break in the last row of table - likely to the fact that the text is marked as span.bold.

screenshot 2015-12-28 10 47 50

xx.zip

@zopyx

This comment has been minimized.

Show comment
Hide comment
@zopyx

zopyx Dec 28, 2015

Removing the first row let the last row render differently but still with an improper line break..completely weird rendering behavior.

screenshot 2015-12-28 16 30 31

zopyx commented Dec 28, 2015

Removing the first row let the last row render differently but still with an improper line break..completely weird rendering behavior.

screenshot 2015-12-28 16 30 31

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe Dec 31, 2015

Member

I can't reproduce the bug with simple HTML samples like this one:

<ol>
<li>
  sietua netunars etunare itunr itnause eitu netauie tnauiet rnauetn
  <strong>etasnui tenrau etnrsauet nrauet nrauet</strong> sitenaurset
  auiret nauietnrau et

Could you please provide the HTML and CSS used in your examples?

Member

liZe commented Dec 31, 2015

I can't reproduce the bug with simple HTML samples like this one:

<ol>
<li>
  sietua netunars etunare itunr itnause eitu netauie tnauiet rnauetn
  <strong>etasnui tenrau etnrsauet nrauet nrauet</strong> sitenaurset
  auiret nauietnrau et

Could you please provide the HTML and CSS used in your examples?

@liZe liZe added the bug label Dec 31, 2015

@liZe liZe self-assigned this Dec 31, 2015

@zopyx

This comment has been minimized.

Show comment
Hide comment
@zopyx

zopyx Dec 31, 2015

See uploaded xx.zip file

zopyx commented Dec 31, 2015

See uploaded xx.zip file

@liZe liZe closed this in fac5ee9 Jan 1, 2016

@zopyx

This comment has been minimized.

Show comment
Hide comment
@zopyx

zopyx Jan 1, 2016

Where is a related (unit)test? How can you ensure that there will not be
any regressions? Do you even have a concept of quality control for
Weasyprint?

2016-01-01 19:37 GMT+01:00 Guillaume Ayoub notifications@github.com:

Closed #288 #288 via fac5ee9
fac5ee9
.


Reply to this email directly or view it on GitHub
#288 (comment).

zopyx commented Jan 1, 2016

Where is a related (unit)test? How can you ensure that there will not be
any regressions? Do you even have a concept of quality control for
Weasyprint?

2016-01-01 19:37 GMT+01:00 Guillaume Ayoub notifications@github.com:

Closed #288 #288 via fac5ee9
fac5ee9
.


Reply to this email directly or view it on GitHub
#288 (comment).

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe Jan 1, 2016

Member

Where is a related (unit)test? How can you ensure that there will not be
any regressions? Do you even have a concept of quality control for
Weasyprint?

Thank you for your gratitude.

WeasyPrint has tests, covering 94% of the code. These tests are launched for each commit with 6 different versions of Python, on Travis.

That's all I have to offer as a "concept of quality control".

Writing tests is sometimes hard and long, especially for text-related features of WeasyPrint. For example, I had no layout problem with your sample page, because I don't have Droid or Calibri installed. I had to change random characters to get your problem.

We can use a special font and rely on it to test some features. Actually, that's what we do: we use Ahem, a font specially crafted for tests. It helps, it makes writing some tests go from impossible to quite hard. But it's sometimes not enough: the test testing 'font-stretch' doesn't work on my computer because the default font used for tests has no condensed variant.

I could take the time to create a condensed font. I just don't want to. I prefer spending this time with my family.

And that's sometimes not only a problem of time. This particular bug was caused by a hack introduced because of hinting problems. The way how hinting is done depends on your OS, the versions of the font rendering libraries installed, and your personnal font rendering settings. On some systems, it may even depend on the screens plugged to the device, and on the orientation of these screens. So, if there's a reliable way to test hinting-related features for all the versions of the font-rendering libraries installed on these computers, I'd be happy to know it. I've already tried hard, please believe me. But I don't know it yet, making some non-regression tests just impossible to write for me.

If you're interested in WeasyPrint, including in its quality, I'll be really happy to spend some time fixing the bugs you report (even on January 1st), reading your pull requests, merging them and answering your questions. I'd love to see WeasyPrint become better. I'll spend time writing code and tests for free. But I won't be the person writing a test each time a bug is found.

Member

liZe commented Jan 1, 2016

Where is a related (unit)test? How can you ensure that there will not be
any regressions? Do you even have a concept of quality control for
Weasyprint?

Thank you for your gratitude.

WeasyPrint has tests, covering 94% of the code. These tests are launched for each commit with 6 different versions of Python, on Travis.

That's all I have to offer as a "concept of quality control".

Writing tests is sometimes hard and long, especially for text-related features of WeasyPrint. For example, I had no layout problem with your sample page, because I don't have Droid or Calibri installed. I had to change random characters to get your problem.

We can use a special font and rely on it to test some features. Actually, that's what we do: we use Ahem, a font specially crafted for tests. It helps, it makes writing some tests go from impossible to quite hard. But it's sometimes not enough: the test testing 'font-stretch' doesn't work on my computer because the default font used for tests has no condensed variant.

I could take the time to create a condensed font. I just don't want to. I prefer spending this time with my family.

And that's sometimes not only a problem of time. This particular bug was caused by a hack introduced because of hinting problems. The way how hinting is done depends on your OS, the versions of the font rendering libraries installed, and your personnal font rendering settings. On some systems, it may even depend on the screens plugged to the device, and on the orientation of these screens. So, if there's a reliable way to test hinting-related features for all the versions of the font-rendering libraries installed on these computers, I'd be happy to know it. I've already tried hard, please believe me. But I don't know it yet, making some non-regression tests just impossible to write for me.

If you're interested in WeasyPrint, including in its quality, I'll be really happy to spend some time fixing the bugs you report (even on January 1st), reading your pull requests, merging them and answering your questions. I'd love to see WeasyPrint become better. I'll spend time writing code and tests for free. But I won't be the person writing a test each time a bug is found.

jsonn pushed a commit to jsonn/pkgsrc that referenced this issue Feb 19, 2016

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

Released on 2016-01-29.

New features:

* Support the `empty-cells` attribute.
* Respect table, column and cell widths.

Bug fixes:

* `#172: <Kozea/WeasyPrint#172>`_:
  Unable to set table column width on tables td's.
* `#151: <Kozea/WeasyPrint#151>`_:
  Table background colour bleeds beyond table cell boundaries.
* `#260: <Kozea/WeasyPrint#260>`_:
  TypeError: unsupported operand type(s) for +: 'float' and 'str'.
* `#288: <Kozea/WeasyPrint#288>`_:
  Unwanted line-breaks in bold text.
* `#286: <Kozea/WeasyPrint#286>`_:
  AttributeError: 'Namespace' object has no attribute 'attachments'.

liZe added a commit that referenced this issue Jun 25, 2016

Re-add hack to avoid floating points errors
Fix #325 and shouldn't reopen #288. Now that fac5ee9 fixes line-cutting
bug when drawing, we can use a much lower relative tolerance inspired
from PEP 485 (1e-9 instead of 1e-3).

Tests have been added with random values, as results highly depend on
the version of Pango used and on hinting properties depending on the
system used to launch the tests. They are probably longer than required,
but they try hard to prevent #288 and #325 from coming back.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment