Split handling of HTML attributes & style CSS properties

[Lucas-C]

This PR also:

• rename the fpdf.TitleStyle class into fonts.TextStyle
• deprecates tag_indents in favour of tag_styles
• allows both FontFace and TextStyle instances to be provided as tag_styles
• remove heading_above & heading_below parameters (not released yet), now handled by .t_margin & .b_margin of HTML tags' TextStyle settings
• remove list_vertical_margin parameter (not released yet), now handled by .t_margin <ol> & <ul> TextStyle settings
• removes several hardcoded values in fpdf/html.py

Checklist:

• The GitHub pipeline is OK (green),
  meaning that both pylint (static code analyzer) and black (code formatter) are happy with the changes of this PR.

• A unit test is covering the code added / modified by this PR

• This PR is ready to be merged

• In case of a new feature, docstrings have been added, with also some documentation in the docs/ folder

• A mention of the change is present in CHANGELOG.md

By submitting this pull request, I confirm that my contribution is made under the terms of the GNU LGPL 3.0 license.

[gmischler]

Looks reasonable.

Note that svg.py uses parse_style() as well and will need to be adapted.
Also, maybe rename to parse_css_style()?

[Lucas-C]

Note that svg.py uses parse_style() as well and will need to be adapted. Also, maybe rename to parse_css_style()?

Agreed! Good idea.

[Lucas-C]

Quoting @gmischler in a comment above:

It becomes increasingly clear that all those styling features were slapped together without first trying to come up with a real concept of which role each one is supposed to play. It might be good to take the time now to figure out something a bit more systematic.

There is some truth in this.
What do you mean by "something a bit more systematic"? What interface would you like?

At this point, I think that this PR is "good-enough" to be merged, and we could perform more improvements in later PRs.
Specifically, I'd like to handle most inline HTML tags & most HTML block tags the same way in HTML2FPDF methods.

Still, I'd be happy to merge this, because:

• it simplifies HTML settings, by deprecating tag_indents in favour of tag_styles, and by getting rid of 3 parameters of write_html() that are now handled by tag_styles
• it removes several hardcoded values in fpdf/html.py
• we will never fully support CSS style sheets (with selectors, priority rules, media-queries, etc..), but we still want to provide a way for users to style globally their HTML tags, and IMHO tag_styles seems like a good API that could last

[Lucas-C]

@lcgeneralprojects : I'd be happy to have your review / feedbacks on this, given that you previously worked on list_vertical_margin in PR #1170

[gmischler]

What do you mean by "something a bit more systematic"? What interface would you like?

I don't have a very detailled idea of how the optimal API would look like.

There are quite a lof of places that could be equipped with styling (traditional text, HTML tags, table cells/rows/columns, text regions, paragraphs, etc.), all with some common requirements, but also a lot of sometimes subtle differences. My point is that when adding a new option, the way of thinking should always be "could this be used elsewhere? What would need to be different for that?".

It looks like with your changes we're a lot closer to that than before.

we will never fully support CSS style sheets

Never say never... 😉
But yes, for the forseeable future we're very likely going to limit ourselfes to inline CSS. The whole selector business adds a huge amount of complexity, that would probably require full DOM support (both for HTML and SVG).

[lcgeneralprojects]

@lcgeneralprojects : I'd be happy to have your review / feedbacks on this, given that you previously worked on list_vertical_margin in PR #1170

Will try to help, unless it's too late.

[Lucas-C]

Will try to help, unless it's too late.

I merged this PR, but your review is still very welcome!
I you have feedbacks, I'd be happy to include some changes/improvements in my next PR.

[lcgeneralprojects]

I do like the generalisation and unification of text style management. I also have to say that I am grateful for being mentioned in the changelog.

I won't have time to delve in-depth into the new stuff until at least two more days, but the apparent reduction of 'special cases' seems nice.

[Lucas-C]

Thank you very much for the feedback @lcgeneralprojects! 👍

[Lucas-C]

This PR is a follow-up of the clean-up started there: #1217