py-pdf / fpdf2

Simple PDF generation for Python
https://py-pdf.github.io/fpdf2/
GNU Lesser General Public License v3.0
1.12k stars 254 forks source link

Feature Request: set_y() boolean flag to avoid affecting x coordinate #296

Closed Ericbaz closed 2 years ago

Ericbaz commented 3 years ago

I'll just preface this by saying that this library saved my life at the new job . So thanks to all of you in advance.

Anyway, I've stumbled into this behavior where the abscissa of the current position is reset every time you use set_y(). It kind of stumped me, since set_xy() didn't really fit my particular situation.

After some research, I found this Stack Overflow post about the same thing in the original PHP library: https://stackoverflow.com/questions/23109873/fpdf-setx-and-sety-call-order-bug

Someone commented that they added a boolean so you can stop set_y() from affecting the x axis and it seems sensible that this could be in this library as well. Especially because this current behavior is not easily discoverable in the available documentation, so it caught me by surprise.

Thanks again.

Lucas-C commented 3 years ago

Hi @Ericbaz!

Glad that fpdf2 was so useful to you :)

Regarding set_xy() behaviour, I fully understand how it can be unexpected and somehow annoying.

It may be difficult to change it however, as changing its definition would break backward compatibility in a way that would be hard for users to identify and track down.

Nevertheless, this method is only two lines of Python: https://github.com/PyFPDF/fpdf2/blob/2.4.5/fpdf/fpdf.py#L2418

Why don't you simple set pdf.y directly?

Ericbaz commented 2 years ago

It's the other way around. As stated previously, it's the set_y() method that behaves this way.

I got around that by keeping in mind that I have to call set_y() BEFORE set_x() just so my positioning doesn't get botched. Which is what led me to suggest the boolean flag to disable that "self.x = self.l_margin" contained in the set_y() method, like they apparently did in the original PHP library.

Wouldn't want you to break this library for everyone else over it, of course.

If it works, I wouldn't have much problem using the self.y from FPDF class instead in future situations.

Though it would kind of defeat the purpose of a set_y() method even existing in the first place, I think.

Anyway, thanks for the quick response.

Lucas-C commented 2 years ago

OK.

Closing this for now, thanks for notifying us about this small API hindrance