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.

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

Inconsistent cell width calculation based on style #61

Open
cdekker opened this issue Dec 14, 2015 · 3 comments
Open

Inconsistent cell width calculation based on style #61

cdekker opened this issue Dec 14, 2015 · 3 comments

Comments

@cdekker
Copy link

cdekker commented Dec 14, 2015

As far as the manual is concerned, there are 2 different ways to style the text in the cells: inline and through an options hash.

For a table, I want only the first row (headers) to be bolded.

When I fill the cell with <b>Onelongcontentword</b> it fits fine, and the table expands width where needed.

If I set the style options like page 19 from the manual (http://prawnpdf.org/prawn-table-manual.pdf):

table(data, :header => true) do
    row(0).font_style = :bold
end

The last letter is pushed to a new line. It seems the width is calculated on the non-bold width of the text. This is all with the default font Helvetica.

Since I prefer not to meddle in the content strings (which come from a database) to append <b> tags around them, I prefer the second approach. Sadly this does not work due to this bug.

@maikokuppe
Copy link

+1

@jessedoyle
Copy link
Contributor

I believe #60 fixes this issue, but a new version has not yet been released that includes this fix.

Would you be able to test the issue against the Github master branch?

@mojavelinux
Copy link
Contributor

I can confirm that #60 fixes the issue for me. I reported a similar issue in Asciidoctor PDF (asciidoctor/asciidoctor-pdf#599). I've been able to verify that the bug does not occur when using prawn-table from master.

@packetmonkey Would you be willing to release 0.2.3? It would really help if you didn't drop support for Ruby 1.9.3 at the same time so that we can get the bug fix without having to change the software stack at the same time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants