Dynamically adjust size of page

[NadaAfterwards]

Hi! I'm improving our script at my job to generate tickets for our queue management system, going from PyFPDF to FPDF2 and expanding the script's functionality. One of my objectives is to try to make most things dynamic such as the placing of elements (cell, multi_cell and image) as well as allowing us to easily modify which elements to be rendered and how much space to put between one another.

This means I don't truly know the height of my PDF page until all elements are rendered and as far as I can tell, there isn't a way to go back and update the dimensions of the used FPDF object. A plausible solution, which I somewhat dread, would be to create a new FPDF object after finding the required height, redoing all the elements there and outputing that instead. Seems slow but it could work...

I do want to clarify that I cannot simply leave empty space at the end since we have to print the document with a rotation of 180 degrees, causing the end of document to be the beginning. Our printers can't be configured to skip empty lines from the top.

I'm wondering if there are any other better solutions to this problem, I do understand our use case might be somewhat outside the scope of this library.

Cheers!

[Lucas-C]

Hi @NadaAfterwards!

Interesting use case. Thanks for opening the discussion.
It makes me happy to know that you are considering fpdf2 for this task 😊

One thing that I do not quite understand: you mentioned that your document will be printed.
Hence you must have at least a maximum document size for you ticket? Will the tickets be printed on an A4 paper page?
Do you plan to put several ticket on the same page, or a single one?
What will cause your tickets to expand in size? Images?

Overall, it seems that your are trying to build a layout system for structuring your tickets.
Something similar to a table, grid or flexbox system in the HTML/CSS world.
For the record, fpdf2 does not offer such layout capabilities out of the box, and you may want to have a look at those:

• borb has a layout system: https://github.com/jorisschellekens/borb-examples/#3-container-layoutelement-objects
• WeasyPrint allows to convert an HTML document styled with CSS to a PDF. It supports flexible box layout and setting document dimensions

If you want to stick with fpdf2, based on what I understand of your requirements, you could adopt a 2-steps strategy:

1. build a basic layout engine, with zero dependency on fpdf2, but where you can define positioning requirements like "put this block with a width that is 30% of the space, sticking on the left side" or "center this title vertically in its parent container"
2. once you have fed your layout system all your constraints, it gives you as output all your elements final positions, and you can then call fpdf2 to generate a PDF document

[NadaAfterwards]

Hello @Lucas-C

Hence you must have at least a maximum document size for you ticket? Will the tickets be printed on an A4 paper page?

The tickets are printed in 80x80 mm thermal paper roll. The maximum document size is only mandatory because we set the orientation-requested to 6 (inverted portrait mode). With the orientation in place it means we waste paper when printing each ticket. If we didn't set the orientation-requested this wouldn't be a problem, but we would like for the tickets to face the right way up.

Do you plan to put several ticket on the same page, or a single one?

One ticket per page. We run the script that generates the PDF each time a new ticket is requested, so the output PDF will always be a single page representing a unique ticket.

What will cause your tickets to expand in size? Images?

The multi_cell can cause the ticket to expand in size, we have a user interface in place where our clients can customize several aspects that get reflected on the ticket. These consist of a space for a header text, the name of the sector for which they are queueing and a footer text. All these are created as multi_cell because the text they input could be really long or really short, e.g. for the header it could be "Welcome to [Business Name]" which fits in a single line, or "Welcome to [Business Name] please await your turn, you will be called shortly" which could result in three lines.

Additionally we're expanding the script's functionality to omit certain elements if our clients request it, this is something we'll be handling ourselves internally but causes the tickets to contract in size. The idea is to have all possible variants unified in a single version of the scrpt, so we I've created booleans to toggle the elements, rather than deleting lines of code.

borb sounds like it might be a good alternative, unfortunately at this point in time we've settled in using FPDF2. If we decide to continue adding functionality, I might consider borb but it's unlikely we'll need features not present in FPDF2 (save for the need to dynamize page/doc height).

Your 2-step strategy seems like a good solution! But I think I will stick to redoing the entire creation of the document as I stated on my original post. Creating an engine might be outside of my codding capabilities and something that could take more time than we anticipated to finish this task. Thanks for all the suggestions! I will keep them in mind for any future opportunities!

[Lucas-C]

Thank you for the detailed explanations.
I understand that you are time-constrained and cannot afford migrating your codebase to using another PDF rendering lib.
Have you tried setting the document size to be 80x80mm? This would make sense given your usage.
Also, maybe FPDF.offset_rendering() could be useful to you, as it will let you try to render an element on your document and check if it overflows the page.

[gmischler]

The tricky part here is that the PDF format has the coordinate origin at the bottom of the page, while fpdf2 has it at the top.
This is the reason that you can't just do a pdf.set_dimensions() after you filled the page, because that will cause the page to be cropped from the top, removing part of your content.
The solution is to just rotate the page content by 180° around the page center in the first place. In your case, this also happens to be the desired orientation for printing. Reducing the page height after that will remove the empty space at the "logical" bottom, which is still technically the top.

from fpdf import FPDF

def draw_label(pdf):
    for i in range(10):
        pdf.cell(txt=f'{i:02}: ABCDEFGHIJKLMNOPQRST', new_x="LEFT", new_y="NEXT")

pdf = FPDF()
pdf.set_margins(5, 5)
pdf.set_font('Courier', '', 11)

# full 80x80 mm page.
pdf.add_page(format=(80,80))
draw_label(pdf)

# page cropped to 80x50 mm from the top.
pdf.add_page(format=(80,80))
draw_label(pdf)
page2 = pdf.pages[2]
page2.set_dimensions(pdf.w_pt, 50*pdf.k)

# content rendered flipped by 180° around page center, then cropped.
pdf.add_page(format=(80,80))
with pdf.rotation(180, x=pdf.w/2, y=pdf.h/2):
    draw_label(pdf)
page3 = pdf.pages[3]
page3.set_dimensions(pdf.w_pt, 50*pdf.k)

doc = pdf.output('pagesizetest.pdf')

The image shows the three different versions of the output:

edit:
ping @NadaAfterwards, just to make sure you actually see the solution, since it was added a bit late...