-
Notifications
You must be signed in to change notification settings - Fork 249
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor template.py to create FlexTemplate() #228
Conversation
*Values of csv files are converted by position, instead of content * Updated tests to check for regression * Updated documentation and tests to include multiline text.
restrict decimal seperator replacement to float fields
Codecov Report
@@ Coverage Diff @@
## master #228 +/- ##
==========================================
+ Coverage 85.38% 85.91% +0.53%
==========================================
Files 16 16
Lines 3557 3656 +99
Branches 720 754 +34
==========================================
+ Hits 3037 3141 +104
+ Misses 350 334 -16
- Partials 170 181 +11
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really good job on this PR!
🎉🥳
Could you please add a mention of the changes performed in the CHANGELOG.md
file?
@allcontributors please add @gmischler for doc |
I've put up a pull request to add @gmischler! 🎉 |
Well, if I'm not missing anything serious, this thing should be done now.
Now I can focus on why I actually wanted to do this... 😉 |
And finally, as a bonus feature, it was surprisingly simple to add scaling to FlexTemplate.render(). |
Awesome! I will try to review this asap. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job, thank you @gmischler!
You wrote excellent quality code,
and provided useful features for fpdf2 users!
I merged this PR. I also added an extra commit to ensure backward compatibility regarding |
It was my pleasure (and benefit for a different project).
Yeah, my approach may have been too unforgiving there... 😉 |
That would be great, yes, thank you!
Could you be more precise please? |
Your code never gets executed, because the type checking in |
As announced in issue #216.
I decided to name the new class
FlexTemplate()
. WhileTemplateCore()
indicates that it is the base class ofTemplate()
, that fact is an implementation detail and not really relevant to the user. The current name seems better suited to inform about its intended use.As promised, the "new"
Template()
can be used in exactly the same way as before, so we should be fully backwards compatible, except where noted below.The previous code had some unnecessarily complicated data management, first collecting the input text for all pages, and only in the end rendering them all in one go. Now each page gets rendered right before switching to the next one.
I fixed the csv parsing once more (several times, actually), so that most items are now optional, and documented which are.
I discovered that there was an undocumented template field "rotate", which seemed to work in elements dicts. I added that to the csv parser, and to the documentation. There seem to be some issues with the rotating functionality in fpdf though (see issue #226), so unless that can get fixed, maybe it should be labelled experimental.
Added arguments to
FlexTemplate.render()
so templates can be placed with offset and rotation (same caveat as above with the latter).There was previously no test for filling more than one page with
Template()
, so I added one, as well as a test for creating a multipage document, tests about what happens with bad template data, and tests forFlexTemplate()
.In my previous PR, I had added default values for missing fields right when loading a csv file. This was kind of silly, because it globally overrides the individual type defaults already in place. Now we just leave the optional values away if they are not supplied, and let the type handlers worry about defaults. Of course, there are special cases...
Incompatible changes:
Changed the handling of
code39()
, so that it uses the standard template fields instead of x/y/w/h (see issue #227).Open questions:
The two barcode types have a different bar default width.
Is there a technical (graphical) reason for that, or did it just accidentally happen?
If the latter, then it should probably be fixed to the same value.
Oh, and are those actually mm, or maybe points?
When a formally incorrect template is used, that may raise a variety of different exceptions, sometimes during loading, and sometimes only on rendering. Maybe some more input checking and error standardisation could be done there.