pyfpdf

pyfpdf copied to clipboard

going to continue this progress through the summer most likely, mostly a pull request to draw attention, because when i started working with/on this library it looked like it was out of maintenance.

checkout the code coverage badge.

Wow, that's huge. More than can be reviewed by one man. It should be splitted to several pull requests. Some thoughts:

1. change formatting - must have
2. tox - too
3. new tests: no binary pdf in repo (only hash), no external http depencies without hash
4. attic is useful, there are few ideas inside
5. why you delete all out tests and docs?

i was thinking about doing pdfs as hashes but decided against it, because really the library produces different pdf's, because it bakes /CreationDate pdf flag into the document, i wrote a utility function that compares binary files ignoring this detail. So this is done for precision.

I deleted everything that isnt formatted or organized and am slowly organizing. I deleted all test files, am rewriting the tests as test cases some are already done. (code coverage is 50%, i wrote 0 of those tests).

I hope to include sphinx docs soon, because there are some irregularities (inevitable ones) when documentation is separate md files, and some of the methods return some weird stuff.

though i would ideally be pulling code back in from reinghart and making merging easier in the future, my immediate top priorities are

• porting all of the tests into actual tests and not like example code,
  • making test suite rigorous enough to comfortably play around with core class (what a stinking pile, half the writer methods can be totally abstracted into another class, maybe inheritance maybe containerization)
• pulling down the features that you guys have with image masking and stuff, and
• making table functionality core (this is my actual application)

i welcome any additional input or specific requests or concerns you guys may have for me! the more concrete the orders are the better and more likely i can cater to them.

because really the library produces different pdf's, because it bakes /CreationDate pdf flag into the document It can be avoided with this tip pdf._putinfo = lambda: common.test_putinfo(pdf) Anyway currently we support custom test suite and unittest (sort of) with single codebase.

Let's change things slightly. Main plan there https://github.com/reingart/pyfpdf/wiki/Roadmap

hey so according to some of the text in the pdf spec, pdf/a just has something to do with putting all the important stuff in the file in the beginning of the file to optimize random access on disk or off of a wire. so i think that can totally be simply lifted off a different library (maybe not quite as extreme as calling a shell command or something, but you get the point, I dont see why this needs to be closely integrated, although I do admit this might be in ignorance of something).

I havent copied any tests regarding fonts yet, so maybe you can shed some light on what Support for 64k+ font ranges means and i can try and work on that. As far as all of the stuff under 2.0, hopefully my organizational efforts can enable more efficient and developer friendly yada yada to help someone who knows about pdf get that done.

pep-8 is proving to be a real doozy because although fpdf.py module itself looks better now, I have eight or so rule exceptions, and flake8 is really uncompromising where the pep8 standard does not insist on certain things, like hanging indents, et cetera. For this reason I have not invested the extra time into cleaning up the other modules, but you can see the code in tox.ini and the other tests in tox.ini pass (feel free to clone my master branch locally and look around.

I have also yet to copy over the readthedocs files because I dont know how those files get uploaded but I'd insist on having the script that processes those exist alongside, and having not found one, i sort of cleaned them up as orphans in the repository.

that aside, my next steps are probably going to be breaking up the fpdf class into FPDF and ShapeWriter, DocumentWriter, HTMLWriter, ImageWriter, FontWriter, because the tests that exist are not organized (alternatively: what is the logic behind how they are now?) and this would be a great way to organize the features, the tests for them, and the documentation? Not sure if this is a good idea, or which would come first, the tests or the new Classes, would love to hear your input on this. Also, in a major version change, this could come with a usage like so: the user would import whatever is needed, and create a class that inherits from all of these classes:

class Document(fpdf.FPDF, fpdf.FontWriter, fpdf.DocumentWriter):
  pass

d = Document()
d.add_page()
d.set_font('Arial', size=12)
d.cell(w=0, txt="hello world")
d.output("hello_world.pdf")

also a feature I thought that would be really useful to me is having the height parameter in cell and multicell default to a 'line spacing' instance parameter which would be MSWord default: 1.15 * font size in points; other improvements in that same vein which crossed my mind are: removing all default parameters, adding an option to cell function to not write text past a designated width (currently width only affects border drawing).

More comments while i am writing all of this down, about the roadmap plans: generating pdf objects will need to have very careful tests written to ensure that the spirit of "calling functions in order" that this library has over other libraries be preserved.

look forward to your thoughts!