Closed lilith-writes-code closed 4 years ago
Welcome! Thanks for posting your first issue. The way things work here is that while customer issues are prioritized, other issues go into our backlog where they are assessed and fitted into the roadmap when suitable. If you need to get this done, consider buying a license which also enables you to use it in your commercial products. More information can be found on https://unidoc.io/
Welcome! Thanks for posting your first issue. The way things work here is that while customer issues are prioritized, other issues go into our backlog where they are assessed and fitted into the roadmap when suitable. If you need to get this done, consider buying a license which also enables you to use it in your commercial products. More information can be found on https://unidoc.io/
This makes sense github-bot. Where can I go to indicate that we do have a license? :)
@venison No worries, we know the context :).
Will this also fix the case where division doesn't seem to take page margins into account? I was looking at your change to division.go::GeneratePageBlocks. Locally while trying to troubleshoot using AddSection, I modified line 116 to be:
ctx.Height -= div.margins.top + div.margins.bottom + ctx.Margins.bottom
After doing this my section content seemed to respect the bottom margin values set using Creator.SetPageMargins
@venison I'm not sure what your exact use case is. I ran the sample you attached on the PR branch and added c.SetPageMargins(50, 50, 50, 50)
. I attached the output PDF. Let us know if that looks ok: invoice_simple.pdf
EDIT: And here's the output from the modified invoice advanced test case from the PR (this one has the default page margins): invoice_advanced.pdf
Judging by your output, I think it fixes the 'other' issue I was running into locally. My use case was similar to what you have in invoice_advanced.pdf, where I was adding multiple sections using invoice.AddSection("someTitle", "some content"), or invoice.AddSection("", "more content"). I was seeing that the content was not respecting the bottom margin. Judging by the testcase output you have there, I think this might fix both the "really really long content with no line breaks" case and the invoice.AddSection content not respecting the bottom margin. Does that make sense?
Yes, the PR primarily addresses the behavior of the paragraph component. Before, if the entire paragraph content (the custom section in this case) did not fit on the current page, it was moved on the next one. With the changes, only the paragraph lines which do not fit on the current page are moved to the next one. I did notice the page margins were causing some issues when using divisions so I fixed that as well. It was due to using divisions inside tables. So both issues should be solved now.
Description
Given a large contiguous text block (no line breaks/carriage returns), sections such as invoice.SetTerms or the base AddSection do not automatically break content across pages.
Expected Behavior
It would be awesome if this text content was split to new pages when encountering the end of a page or pages.
Actual Behavior
Steps to reproduce the behavior: Using the pdf_invoice_simple.go as a starting point, simply update the content for SetTerms to be a long contiguous block of text.
Attachments
Attached is an example pdf and the modified pdf_invoice_simple.go
pdf_invoice_simple.zip