Suggest new features!

[Lucas-C]

fpdf2 is a living project: it aims to grow with new features, improvements to existing functionalities, and always more helpful documentation.

To do so, we need to know what users of fpdf2 would like to be able to do with this library.

This discussion purpose is exactly that: please add comments with suggestions for features & general improvements!

• would you like some documentation on how to use fpdf2 in some way?
• would like to be able to produce some specific visuals?
• would you like support for a precise PDF feature?

[vicmayrink]

FPDF is helping me to create high quality reports and documents. I really appreciate the community efforts to develop and maintain the project.

I would like to suggest a feature to include images in .pdf format. Most graphical libraries (including the famous matplotlib) allow us to save images as .pdf files. This a good choice to save the plot in vector format (rather than bitmaps). I know that FPDF2 supports SVG images, but I've got unexpected results when trying to embed an SVG image into the output PDF file.

[Lucas-C]

I've got unexpected results when trying to embed an SVG image into the output PDF file

I'd be happy to help you properly embed SVG images in a PDF using fpdf2.
Could you please create an issue and provide a bit more details on what was the problem exactly?

[vicmayrink]

Thanks for your reply :)
I've just created this question

[datatalking]

Does fpdf2 have a good first contribution tag or whatever GitHub issues does ?

I'm looking to understand your framework as I used the old PyFPDF lib and had to patch the code, just found your repo and will have some time later this week to play with changes you've made.

Do we have a running list of functions or errors as a sort of diff between the last version PyPDF2 and fpdf2?

When I import fpdf2 why do some tutorials use a capitalized FPDF2, is this for a function difference? Perhaps the python importer care about capitalizations as it definitely cares wether its pandas-dataframe vs pandas_dataframe which I believe generates a Import Error

[Lucas-C]

Does fpdf2 have a good first contribution tag or whatever GitHub issues does ?

We do have such issue tag indeed: good first issue

Do we have a running list of functions or errors as a sort of diff between the last version PyPDF2 and fpdf2?

So far I only know of only one functional difference with PyFPDF, detailed there: https://pyfpdf.github.io/fpdf2/Development.html#history

We aimed for full backward compatibility, however a few things have be deprecated (unused function arguments & other minor things), and will be removed one day.
You'll find instructions on how to enable deprecation warnings there: https://pyfpdf.github.io/fpdf2/index.html#displaying-deprecation-warnings

why do some tutorials use a capitalized FPDF2?

I couldn't find a single use of this capitalized form in this repository, sorry.
Could you be more precise on what tutorials you are refering to?

PyFPDF is the original, unmaintained library: GitHub repo - Pypi page

fpdf2 is this new, extended library: GitHub repo - Pypi page

If you have any suggestion to make the difference between them clearer in our documentation, I'd be happy to hear about it 😊
(maybe open a new discussion about it)

[gmischler]

So far I only know of only one functional difference with PyFPDF

There are several things that may technically still work, but are really deprecated in favour of cleaner solutions.
Not sure if all of the below were actually already present in the original PyFPDF, but they got changed at some time:

• center parameter for cell() is deprecated.
• new_x and new_y parameters to cell() and multi_cell() have replaced ln.
• fill parameters have been replaced by style.
• dashed_line() is deprecated in favour of set_dash_pattern().
• parameter names have changed for code39() barcodes.
• set_doc_option() is deprecated.
• dest parameter for output() is deprecated.
• type parameter for image() is deprecated.
• infile parameter of Template() constructor is deprecated.
• Template elements have a transparent default background instead of white.
• dest parameter of Template.render() is deprecated.
• rotate() method is deprecated in favour of rotation() context manager.

The full set can of course be found in the changelog, but that may be tedious to scan through.
If you ask Python to show DeprecationWarnings, you'll also get a list of those that actually matter to your code.

But maybe a seperate list of API changes "since X" would really be helpful?
There should probably also be a plan about how long to carry around deprecated features, and when to actually remove them.

[Lucas-C]

But maybe a seperate list of API changes "since X" would really be helpful?

Agreed!
Thank you for this list @gmischler.
We should mention those in the documentation, maybe in a dedicated section between "History" & "Usage" here:
https://pyfpdf.github.io/fpdf2/Development.html#history

Maybe like this:

## History
## Compatibility with PyFPDF
### Major changes
### Deprecated functionalities
## Usage

What is your opinion on this proposal @gmischler?

I want to emphasize that the deprecated functionalities / arguments still work perfectly fine,
they just generate warnings suggesting to switch to alternative methods / parameters.

Hence 90% of the items in this list are deprecated functionalities that still work,
but the default background color for templates elements is something I did not have in mind that should probably be made explicit in the documentation.

parameter names have changed for code39() barcodes

Which ones exactly? Is it just for templates?

[gmischler]

Thank you for this list @gmischler.

No garantee that it's complete, though...

And of course, a lot of functionality has been added, but I guess in a migration context that only becomes relevant as a second step.

What is your opinion on this proposal

Looks like a good place to put it.

parameter names have changed for code39() barcodes

Which ones exactly? Is it just for templates?

Ah yes, that was in the templates.

[Lucas-C]

I finally took the time to redact that PR 😅

Could you please review it @gmischler? -> #885

[n-gram-hub]

I would add an add_page(bytes) because other libraries (eg. PyPDF2) let you get (get_contents().get_data()) a byte string representation of a page. pdfrw lets you do a similar thing for a whole pdf in the PdfReader constructor, eg. reader = PdfReader(fdata=bytes(fpdf.output()))

[Lucas-C]

I agree with @gmischler overall.

A few months ago, I tried to write a script with zero dependency that performed text substitution on a PDF document:
https://github.com/Lucas-C/dotfiles_and_notes/blob/master/languages/python/pdf_edit_text.py

In the end, this script probably only works for the single PDF document I was working on,
and with serious limitations: it cannot insert letters that were not present initially in the document.

The functionality you were looking for @n-gram-hub, text edition in PDF documents, won't be provided by fpdf2.
Other libraries exist that can do that however! 😊

[n-gram-hub]

@gmischler First of all (sorry for suggesting something you don't want to support, I didn't know it) I must say, text extraction was a really easy task (maybe it's because I've been involved in text extracting activities before).

Anyway, the problem was not directly mine: a friend, who works as a graphic designer, many years ago created a pdf with Adobe Illustrator and lost the source files: his main customer asked him to produce pdf translations of that file and he wanted to avoid creating a new manual from scratch. So, he asked for help and I devoted an hour and a half to him. Of course, he was inundated by three or four questions starting with "Why don't you...", but anything involving new work or a completely different approach to the problem was discarded. But in the end I gave up, as I said I'm not a pdf expert: I'm a curious guy, but the last thing I wanted to do was learning the inner workings of PyPDF2. :-)

[Lucas-C]

Understood 😊

Even if we do not implement it, thanks for dropping by to suggest a new feature.
From a maintainer perspective, it's always interesting to know what users expect from the library.

[gmischler]

I must say, text extraction was a really easy task (maybe it's because I've been involved in text extracting activities before).

If a document mainly consists of linear text, then extracting that can often be trivial.
But there's no garantee for that at all, because the PDF format doesn't have a concept of text flow.
There's a reason that specialized extractor programs exist that try to guess the format of tables in PDF files, with wildly varying success depending on what software created the file.

But we were talking about replacing text with a translation, which opens yet another can of worms...
If there is only a reasonably small amount of text involved, a graphical PDF editor might actually be best suited for the task. Acrobat Pro for example can edit text on screen, and your graphics designer friend might already have a licence of that. If there's a lot of files or a lot of text, the job might get a bit tedious, though...

[n-gram-hub]

@gmischler The problem with my friend is he doesn't want to do anything (manual editing, online APIs, nothing): the Python code he showed me was a fairly ridiculous code generated by a famous chatbot: he spent 10/15 minutes in the Socratic art of maieutics, believing something magic would have solved his issue :-) The same Adobe program he uses has this feature: https://www.christianda.com/blog-variable-data.html but he doesn't want to recreate the manual from scratch. Generating pdfs from data is not an impossible task, if you aren't that lazy. :-)

I thank you for giving me a better understanding of the world around the pdf format (I knew it was intricate, but I didn't know how much)

[jhdedrick]

First, let me thank the authors and maintainers for a really exceptional piece of work. This is quality software, and a real pleasure to use.

I'd like to request that you consider two additions to the .table() signature/behavior regarding the width of individual columns and the table overall. The current behavior allows control of overall table width only if we're willing to live with equal-width columns, and allows specifying individual column widths only if we're willing to live with a fixed-width table.

Ideally, we would be able to take advantage of fpdf2's (excellent) column width apportionment logic most of the time, but be able to override it when needed. And similarly, we'd like to be able to let the table use the entire width most of the time, but make it narrower or wider when needed. Most importantly, we want both at the same time!

As background, I first need to point out an error in the documenation:

Setting table & column widths¶

The col_widths optional parameter can be provided to configure this.
If a single number is provided as col_widths, it is interpreted as a fixed column width in document units.
If an array of numbers is provided as col_widths, the values are considered to be fractions of the full effective page width, meaning that col_widths=(1, 1, 2) is strictly equivalent to col_widths=(25, 25, 50).

(In fact, when a single number is provided, it actually becomes the total width of the table, not just of a column. In this case, all column widths are the same, and are sized to fit within the width.)

The current signature has a single parameter, "col_widths". If col_widths is a single value, it uses that value in document units for every column. If it's an iterable, instead of the expected behavior (using the values in document units to control the widths of columns individually), it treats them as relative sizes, but resets the overall width to the effective document width. So, you can either control overall width or relative column size, but not both.

Detailed proposal (but we'd be happy with any implementation that gives the same degree of control):

1. Add a "table_width" parameter that defaults to the effective document width. This takes a single float, and all tables are then exactly this width. Deprecate the single-value input option for "column_widths", since it doesn't really do what it says it does.
2. Add a "col_abs_widths" parameter. This is an iterable of float | None, which must be of length <= the number of columns. If any value is specified, that value is the absolute width of the corresponding column in document units. If a value is None or not specified, the existing fpdf2 column-width logic controls the width of that column (while staying within "table_width" of course. Note that there then may be a mix of absolutely specified columns and columns controlled by fpdf2.
3. "col_widths" becomes effectively "col_rel_widths" - it takes an iterable of float | int | None, and acts like col_abs_widths, except with relative, not absolute values.

[andersonhc]

We already have a width parameter, which already behaves like the proposed table_width.
If you pass width, any col_widths sequence is treated as relative weights within that width.
If you don’t pass width, it defaults to the effective page width.

We don’t currently support absolute per‑column widths directly (or mixing fixed + auto),
but you can get exact absolute widths by converting them to ratios yourself
(e.g., set width=sum(col_widths) and pass the list as weights).

If it still doesn’t work for you, please open an issue with a minimal example so we can reproduce it.