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)