You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please explain your intent
The Table feature is fantastic, but I find that I want more control over borders that is provided by TableBorderLayout. I would really like to be able to control exactly which borders are turned on, and ideally also their thickness, independently.
Describe the solution you'd like
I was thinking that perhaps:
TableBorderLayout could become a regular class instead of an enum, so that a user could create instances of it
The existing values (e.g. HORIZONTAL_LINES) could still be class variables so that existing usage doesn't break
The class would hold on to a function/lamba that is called for every border segment for a table, and would return perhaps a thickness (0=off?) and a color (so table borders don't have to be black).
For (3) I'm imagining the function looking something like:
Additional context
I'm actually trying to port some nasty Rmarkdown -> latex -> PDF code, and users have gotten used to some latex table styling, which I can't reproduce. One example is a table with i) thick borders above/below the table, ii) thin borders under the headerline, iii) no other borders.
The text was updated successfully, but these errors were encountered:
The current border handling for tables is indeed not particularly flexible, since the available combinations of border lines are essentially hardcoded. As another consequence, they will all have the same color (I haven't checked, but I think FPDF.draw_color should take effect here).
Your idea introduces a lot more complexity, but might actually work. As always, the proof is in the PR... 😉
Please explain your intent
The Table feature is fantastic, but I find that I want more control over borders that is provided by TableBorderLayout. I would really like to be able to control exactly which borders are turned on, and ideally also their thickness, independently.
Describe the solution you'd like
I was thinking that perhaps:
TableBorderLayout
could become a regular class instead of an enum, so that a user could create instances of itHORIZONTAL_LINES
) could still be class variables so that existing usage doesn't breakFor (3) I'm imagining the function looking something like:
Additional context
I'm actually trying to port some nasty Rmarkdown -> latex -> PDF code, and users have gotten used to some latex table styling, which I can't reproduce. One example is a table with i) thick borders above/below the table, ii) thin borders under the headerline, iii) no other borders.
The text was updated successfully, but these errors were encountered: