Post without Account — your post will be reviewed, and if appropriate, posted under Anonymous. You can also use this link to report any problems registering or logging in.

PDF::Table general discussion

  • 1 Replies
  • 48 Views
*

Offline Phil

  • Global Moderator
  • Hero Member
  • *****
  • 749
    • View Profile
PDF::Table general discussion
« November 06, 2020, 09:49:30 AM »
Problem tickets should be opened up on GitHub (https://github.com/PhilterPaper/PDF-Table/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc) if at all possible, to avoid cluttering up this board and topic. Anything that should be a ticket will be moved to GitHub. Please open up an account there if you wish to join in the conversation and find yourself posting tickets to this board. The sole area for problem tickets will be on GitHub. If you do not wish to open up a GitHub account, I can tolerate an occasional post here or email via Contact that I move to a GitHub ticket, but please do not abuse the privilege!

With that out of the way, the purpose of this topic is to give you a place to praise (or vent about) PDF::Table. You can discuss directions you'd like to see it take, enhancements you'd like, offers of writing code to update it, and so on. Before embarking on a major project, please discuss it here — it's very discouraging to put in a lot of work on a free software product, and then have your efforts airily dismissed by the project owner (I know; it's happened to me). If your envisioned project takes things too far from where I want it to go, I may gently suggest that you either make a new project that makes use of PDF::Table within it (use or require), or even that you fork it into a new project.

And please, maintain backwards compatibility as much as you can. A new whizz-bang feature isn't helpful if implementing it breaks all the existing code making use of PDF::Table! And don't forget that PDF::Table is supposed to work with both PDF::API2 and PDF::Builder, so be careful about adding functionality found only in PDF::Builder.
« Last Edit: November 06, 2020, 10:40:49 AM by Phil »

*

Offline Phil

  • Global Moderator
  • Hero Member
  • *****
  • 749
    • View Profile
Re: PDF::Table general discussion
« Reply #1: November 06, 2020, 10:39:33 AM »
For a long time, PDF::Builder has had a wishlist item for proper table capability, possibly something along the lines of the nroff tbl subsystem. PDF::Table somewhat fulfills this need, but it's not perfect. The biggest hole in it is that there is very little control over what you can put inside a cell. Only one font in one size in one color with one decoration (e.g., underlining) and one variant (e.g., italic) for the whole thing, and no images and no lists and no embedded tables, etc. You can break up your text into paragraphs, with some indentation control, but that's about it.

What might be possible is to have table() figure out the dimensions of the cell and its starting text characteristics (font, size, color, etc.), and pass this information along with text markup for the cell back to PDF::Builder (or PDF::API2) for further processing. Something like Text::Layout might be used to change font, size, color, variant/style, etc. on the fly (using HTML-like markup), and either let the outer library handle actually writing the resulting text to the file, or enhance PDF::Table to call Text::Layout and do the processing.

Note that PDF::Table figures column widths based on the longest word of the text in that column (at the starting text properties), minimum and maximum column width limits, and the overall desired table width. It might be necessary to allow specification of column width(s) in absolute measure (e.g., points or inches) with n* widths for other columns to divide up the remaining space. In any case, the height of the cell (and row) is unknown until output has actually started, and a split within a row might be necessary at the bottom of the page. Currently, nothing is done regarding control of widows and orphans (single lines of a row's text widowed on the spill page or orphaned on the first page). What might work best is to pass the width back to PDF::Builder and let it do a "virtual print" of the text, letting PDF::Table decide where to split the row, and how high the row will be. It would also permit vertical alignment of cell content, as you would not start outputting a cell until you know the height of the cell content (and the height of the row). This could work with PDF::Builder, but I have no control over PDF::API2, and can't guarantee that this will be implemented there. Thus, some advanced PDF::Table functionality might not be available on PDF::API2.

An alternative would be to cram more functionality into PDF::Table itself (i.e., invoke Text::Layout if it sees <>), but it's already getting a bit out of hand. This is almost getting into a proposed PDF::Builder functionality of defined columns, a  (not necessarily rectangular) block into which you pour marked-up text, lists, images, etc., where a table cell would simply be a fixed width rectangle with a minimum and maximum height. PDF::Table would still need to figure out the overall height of the row, and if (and how) to split a row, before actually starting output. Short of extending Text::Layout to handle all sorts of HTML-like things (lists, tables, etc.), I don't know if this is practical.