Defect #28565
closedPDF export has too many whitespaces
0%
Description
When exported in pdf format, there are too many whitespace under each note (attached).
As far as I can see, white space is automatically generated equal to the line number of the note.
I tested on Redmine 3.4.4.stable.17198 and Redmine 3.1.7.stable.17140, this issue persists.
Hope this issue is fixed soon.
Thank you !
Files
Updated by Guillermo ML over 6 years ago
I can confirm this behaviour on 3.3.1.stable, 3.4.3.stable and 3.4.4.stable
The number of blank lines after each note seems to be identical to the number of lines of text in the note.
Updated by Go MAEDA over 6 years ago
- Status changed from New to Confirmed
- Target version set to Candidate for next minor release
Reproducible in the current trunk (r17315).
Updated by Tyler Nguyen about 6 years ago
I'm not a professional programmer. Hope someone can help me solve this problem, it is also quite important.
Updated by Bernhard Rohloff about 6 years ago
- File fix_height_of_line_break_in_issue_pdf.diff fix_height_of_line_break_in_issue_pdf.diff added
- File ecookbook-2.pdf ecookbook-2.pdf added
The behavior is caused by source:trunk/lib/redmine/export/pdf/issues_pdf_helper.rb#L234
After each comment block the method pdf.ln
gets called without an argument. In this case the space height is equal to the last block.
https://www.rubydoc.info/gems/rbpdf/1.18.3/RBPDF:Ln
I've attached a patch to set the height to what I think is an appropriate value.
Updated by Bernhard Rohloff about 6 years ago
- File fix_height_of_line_break_in_issue_pdf_v2.diff fix_height_of_line_break_in_issue_pdf_v2.diff added
I've found the same behavior for associated revisions and comments after journal entries.
Attached is a second patch to fix also these whitespace issues.
The spacings meet my esthetical reqiurements but feedback on this is hearty welcomed. :-)
Updated by Bernhard Rohloff about 6 years ago
This is the result of my patch but it's quite difficult to show how it looks in a document...
Updated by Jun NAITOH about 6 years ago
I think this is a problem of rbpdf.
Please wait for a while because we are working on correcting it.
Updated by Bernhard Rohloff about 6 years ago
Jun NAITOH wrote:
I think this is a problem of rbpdf.
Please wait for a while because we are working on correcting it.
Do you think this is a bug or do you want to change the default behavior of the pdf.ln method?
Because as I wrote in #28565-6 that's the exact default behavior described in the rbpdf documentation.
... By default, the value equals the height of the last printed cell.
Updated by Jun NAITOH about 6 years ago
- File rbpdf_cell.png rbpdf_cell.png added
- File rbpdf_multi_cell.png rbpdf_multi_cell.png added
Bernhard Rohloff wrote:
Jun NAITOH wrote:
I think this is a problem of rbpdf.
Please wait for a while because we are working on correcting it.Do you think this is a bug or do you want to change the default behavior of the pdf.ln method?
Yes, I think it is a bug in rbpdf.
Because as I wrote in #28565-6 that's the exact default behavior described in the rbpdf documentation.
... By default, the value equals the height of the last printed cell.
By default, the value is intended to be the height of the last printed cell.
However, the current implementation has become the height of the last printed by MultiCell.
This means the height of multiple rows(MultiCell), but the expected specification is the height of one rows (Cell = charactor's hight).
Updated by Jun NAITOH about 6 years ago
- File rbpdf_1_19_5__1_19_6.png rbpdf_1_19_5__1_19_6.png added
- File test-6_rbpdf_1_19_5.pdf test-6_rbpdf_1_19_5.pdf added
- File test-6_rbpdf_1_19_6.pdf test-6_rbpdf_1_19_6.pdf added
- File Wiki_rbpdf_1_19_5.pdf Wiki_rbpdf_1_19_5.pdf added
- File Wiki_rbpdf_1_19_6.pdf Wiki_rbpdf_1_19_6.pdf added
I'm sorry it takes time to fix it.
This problem fixed by rbpdf 1.19.6.
please bundle update.
The fixed issues is as follows.
Updated by Go MAEDA about 6 years ago
- Status changed from Confirmed to Resolved
- Assignee set to Go MAEDA
Updated by Go MAEDA about 6 years ago
- Subject changed from PDF export has too many whitespace to PDF export has too many whitespaces
- Status changed from Resolved to Closed
- Target version changed from Candidate for next minor release to 3.3.9
- Resolution set to Fixed
Updated the Gemfile in the repository. Thank you for working hard on fixing this issue.