Migrating codebase from old FPDF to fpdf2

[gwyker]

Hi, I've written a pretty large codebase over the past year using the old pyfpdf package and just discovered that fpdf2 exists, so I'm eager to make the switch.

Uninstalling pyfpdf and dropping in fpdf2 results in a pretty huge speed increase, and the outputs look nearly identical, but there is one problem: the old module's cell() aligns the center of the text to the cell's xy position, while fpdf2 aligns the top left of the text to the xy position. This means that either all of my code's set_xy calls will need to be adjusted, or I'll have to monkey patch cell() with some sort of re-alignment logic based on fontsize to simulate the old behavior.

I have two questions:

• Is there any way to have cell() align cell text like pyfpdf did, or to get the same effect through other means?
• Are there any other visual differences between the output of the two modules that I may have missed?

[Lucas-C]

Hi, thanks for asking.

I'll try to provide a detailed answer asap.

Also, ping @gmischler who could probably also help there.

[Lucas-C]

there is one problem: the old module's cell() aligns the center of the text to the cell's xy position, while fpdf2 aligns the top left of the text to the xy position

I have just made a test regarding this and the following code snippet renders exactly the same with PyFPDF & fpdf2:

doc = FPDF()
doc.add_page()
doc.set_font("helvetica", size=TEXT_SIZE)
doc.cell(w=45, h=LINE_HEIGHT, border=1, txt="Lorem")
doc.cell(w=45, h=LINE_HEIGHT, border=1, txt="ipsum")
doc.cell(w=45, h=LINE_HEIGHT, border=1, txt="Ut")
doc.cell(w=45, h=LINE_HEIGHT, border=1, txt="nostrud")
doc.output("discussion_411.pdf")

Hence, could you provide more details please?
Maybe some minimal Python code that behaves differently between PyFPDF & fpdf2?

Are there any other visual differences between the output of the two modules that I may have missed?

There should not be any, no.
Check the detailed CHANGELOG.md for an exhaustive list of changes that were made. The Removed sections will point you to features that we dropped from PyFPDF, but there aren't many as we focused on deprecating them first, while preserving backward compatibility. You may want to enable deprecation warnings though.

[gmischler]

Also, ping @gmischler who could probably also help there.

I see three possible approaches here:

A) Fix your own code.
B) To smoothen the transition so you don't need to change all of it at once, you could subclass FPDF(). Add a wrapper method x_cell() which centers around the insertion point, and mechanically replace all your cell() calls with that. Then you can migrate one call at a time to the new API.
C) We add an option align="X" to fpdf2 that centers around the insertion point. That really seems to me to be quite a good idea anyway. This will have an interesting effect on the behaviour of eg. new_x="LEFT" and even more so on the now deprecated ln=#. But in those cases where you happen to rely on the built-in positioning magic you'll have to replace the latter anyway, so that shouldn't really be a problem.

I have just made a test...

Try it with align="C".

[Lucas-C]

Try it with align="C"

I tried, still no difference:

from fpdf import FPDF, FPDF_VERSION

print(FPDF_VERSION)

pdf = FPDF()
pdf.add_page()
pdf.set_font("helvetica", size=36)
pdf.cell(w=45, h=36, border=1, align="C", txt="Lorem")
pdf.cell(w=45, h=36, border=1, align="C", txt="ipsum")
pdf.cell(w=45, h=36, border=1, align="C", txt="Ut")
pdf.cell(w=45, h=36, border=1, align="C", txt="nostrud")
pdf.output(f"repro-{FPDF_VERSION}.pdf")

@gmischler: have you been able to spot this difference yourself?

[gmischler]

@Lucas-C No, I haven't actually tested the old version, and the most recent code there does indeed appear to do about the same thing as ours.
But then, @gwyker hasn't mentioned which release he used. It may have been an earlier one, or it may have been modified individually at some point to get that behaviour.

Either way, I think that an align="X" option would be useful. In fact, it would almost be a cleaner replacement for the ugly center=True that we recently declared deprecated...

[gwyker]

@Lucas-C Thanks, I've written a small example that results in different positions for the versions I have installed.

from fpdf import FPDF, FPDF_VERSION

p = FPDF(format='A4')
p.add_page()
p.set_font('helvetica', size=24)
p.set_xy(0, 10)
p.cell(.01, txt=str(FPDF_VERSION))
p.line(0, 50, p.w, 50)
p.set_xy(50, 50)
p.cell(.01, txt='Lorem')
p.output('test.pdf')

Result: https://i.imgur.com/QqTFRyj.png

pyfpdf version: 1.7.2
fpdf2 version: 2.5.3
Both are recently installed from conda-forge.

I do have a slightly strange way that I use cells. I give them a negligible width so that I can place them precisely, but still have the option of centering the text around that point, an option which text() and write() don't have. I get the same test results with a cell width of 10 though.

My first thought was to patch in a wrapper method like @gmischler suggested, but since the text center depends on the particular font and size, I wasn't sure if that "center" position could be easily calculated in all cases.

Thanks for the help!

[Lucas-C]

Thank you for the code!

From my test, the only thing that differs for me between the PDFs from fpdf2.5.4 & PyFPDF 1.7.2 is the vertical alignement: do you agree?

If so, I think this is related to #210

[gwyker]

@Lucas-C Yep, the only difference I'm finding is the vertical alignment.

I think a vertical alignment option for cell() as mentioned in #210 and by @gmischler would solve my problem, since at my cell height of 0 the only difference between top, center, and bottom would be the location of the anchor of the text.

I'll look into the source some more today to see if I can move the anchor around with an option, though I start to get lost at the Tw TJ Td looking strings. 😄

[gmischler]

Ah, so there's the source of confusion: When you simply say center, then most people will expect you to talk about horizontal centering. In reality it was all about vertical alignment.

The current version will center text vertically within a cell, but only if the cell height is greater than the font height.
That may not be entirely logically consistent, but I'm really not sure what the "correct" solution would be. Current users probably have come to expect that cell text doesn't rise above self.y.
It's rather unusual to align text vertically on a horizontal center line. Is there any specific reason why you chose to do so?

As long as you don't use cell borders and background (both default to transparent), a quick and dirty workaround might be to give the cell a height that is garanteed to be larger than the font height, and anchor it half its height higher than your center line.

Nonetheless, we may still soon see a horizontal align="X" option... 😉

[gwyker]

Currently writing a PR for this =)

[gmischler]

#416 introduces align="X".

[gwyker]

Well, I wrote in an anchor option with values C, T, and B to align the text vertically within a cell. But then I found this little bit of code:

if h is None:
    h = self.font_size

So instead of defaulting to zero like the old pyfpdf, the cell height defaults to text height. Changing my test to p.cell(10, 0, txt='Lorem') results in the same output as pyfpdf and solves my problem. 😅

Here's the branch if you're interested: https://github.com/gwyker/fpdf2/tree/anchor-text
and a sample pic of three cell calls using C, T, and B: https://i.imgur.com/4VWTnWr.png

from fpdf import FPDF, FPDF_VERSION

p = FPDF(format='A4')
p.add_page()
p.set_font('helvetica', size=24)
p.set_xy(0, 10)
p.line(0, 70, p.w, 70)
p.rect(50, 50, 50, 40)
p.set_xy(50, 50)
p.cell(10, 40, txt='Lorem', anchor='C')
p.set_xy(50, 50)
p.cell(10, 40, txt='Lorem', anchor='T')
p.set_xy(50, 50)
p.cell(10, 40, txt='Lorem', anchor='B')
p.output('test.pdf')

It's got some subjective positioning to make the text align decently within the cell, so I'm not sure if it'll look odd in other situations.

[Lucas-C]

So instead of defaulting to zero like the old pyfpdf, the cell height defaults to text height

Well spotted!
I will note this down in the documentation, it should be explicit / known for people migrating from PyFPDF to fpdf2.

Here's the branch if you're interested: gwyker/fpdf2@anchor-text

I looked at your code and it's well done!
I think it could solve #210
One thing that bothers me though is the presence of hardcoded float constant: .9 / .15 / ...
Do you think we could get rid of them / pass them as part of the new anchor argument?

[gmischler]

Well, I wrote in an anchor option with values C, T, and B ...

In HTML/CSS, the terminology chosen is "center" for horizontal alignment, and "middle" vor vertical. This was done very deliberately to help avoid confusion between the two (the above discussion illustrates nicely why that is helpful).
They also use "align" for horizontal and "valign" vor vertical alignment.
"Anchor" is a very generic term, which could mean many different things in a layout, but doesn't signify any direction (eg. Tk/Tkinter uses anchor arguments with bidirectional values out of "nsew").

I highly recommend to stay as close as reasonably possible to the HTML/CSS terminology, since most users will already be familiar with that. When doing that, your keys would become "T", "B", and "M".

It's got some subjective positioning to make the text align decently within the cell,

That is pretty much garanteed to fail with other fonts, which may have vastly different vertical proportions.
There's a variety of font metrics you can use. The .text() method uses the fonts baseline for example, but there are several others which may be more appropriate here. The simplest one is just the line height of the font for top and bottom, even if it may create a slightly larger distance to the border than you apparently wish for. The best center line is probably half the cap height above the baseline. I highly reccommend to do a little research about the various dimensions in a font before proceeding any further here.
Example link: developer.apple.com: Font Handling

Maybe this is actually a good opportunity to switch to using Fonttools instead of our homebrew solution. That will also be necessary for any chance to fix #365, btw.

[Lucas-C]

I think adopting fonttools is a good idea. We could get rid of ttfonts.py.
As usual, we should just take care about backward compatibility.

One drawback I see is that it uses compiled binaries: https://github.com/fonttools/fonttools/blob/main/setup.py
This means that fpdf2 wouldn't really be a pure-Python lib anymore.

Maybe the best, as a first step, would be for fpdf2 to use fonttools if it's available / installed,
and fallback to its current "raw" font processing otherwise?

[gmischler]

One drawback I see is that it uses compiled binaries: https://github.com/fonttools/fonttools/blob/main/setup.py This means that fpdf2 wouldn't really be a pure-Python lib anymore.

From the readme: "fontTools is a library for manipulating fonts, written in Python."
As far as I can tell, the setup.py only mentions the possibility to use cython for building, or to precompile the python files to .pyo during installation.
Am I missing anything there?

Maybe the best, as a first step, would be for fpdf2 to use fonttools if it's available / installed,
and fallback to its current "raw" font processing otherwise?

That sounds like making things much more complicated than necessary.

[Lucas-C]

As far as I can tell, the setup.py only mentions the possibility to use cython for building, or to precompile the python files to .pyo during installation.

You are right, I was misleaded here.
I think there aren't really anything prevent us from using fonttools then

[gwyker]

Agree with you @gmischler on the terminology and I think valign is a better name for it. The hardcoded floats are definitely an issue and are why I didn't go any further with a PR, I couldn't figure out how to align different text styles to the top and bottom in a visually consistent way. The vertical alignment is no longer useful for my case, since I can just use a h=0 cell wrapper, but may help with #210.