view release on metacpan or  search on metacpan

INFO/RoadMap  view on Meta::CPAN

   like many other table implementations. Some columns absolute widths, and
   remaining space divided up even among *'s (with a column N*), subject to
   minimum and maximum widths.

   Within a cell, ideally it would be treated as a mini-page, with all the 
   normal PDF construction capabilities including paragraph shaping, flow into
   column(s), images, etc. This would be better than the "text_block" used in
   PDF::Table (more uniform coding and treatment), although some ideas from
   text_block might find a home. However, such complex treatment (a table 
   could embed a table) requires virtual pages to permit a lot of rearrangement.

I. Consider Optional Content Groups (Layers), per 32000-2008 section 8.11.
   This permits drawings to be shown by layer, or a watermark/copyright layer
   to show only on printing.

J. ## DONE ## release 3.020  (documentation improved)
   Per wkHTMLtoPDF issue 4846, at least some phone cameras output "portrait"
   mode photos in landscape mode (rotated), with an "orientation" tag. JPEG
   (at least) image handling may need a rotation flag in the call, and/or 
   pay attention to the Exif orientation flag. Confirmed that
   Builder JPEG support does NOT respect the orientation flag.
   https://www.google.com/search?client=firefox-b-1-d&q=jpeg+orientation+metadata
   Unfortunately, there are a number of ways to specify the orientation flag
   including XML '<exif:Orientation>Top-left</exif::Orientation>' and buried
   somewhere in the Exif or JFIF header of the file. It might be best to ask
   the image what its orientation is, and leave translation and rotation of
   the placed image to user code, rather than trying to flip the contents of
   the image file directly. See writeup in Docs.pm.
   Supposedly CSS img { image-orientation: from-image; } will get from EXIF,
   although this may have been deprecated.

K. A means to update PDF content already written to the $pdf data structure, 
   but not yet written to file. This could involve moving a text write (one
   or more translates) to somewhere else on the page, or even moving from one
   page to another. More general editing of material already "written" out,
   such as changing a font size or a color -- would need a way to find the
   desired content to be modified. Ability to erase content or move it from
   page to page (e.g., started a table and then found it wouldn't fit on one
   page -- move it to the top of the next page to allow display on a single
   page). If virtual pages, design with all this in mind, so easy to update
   content before being "written" out. If nothing is written to the PDF file
   until the end (save or saveas), this might even supersede virtual pages.

L. (See B and H items above) Consider a $page->subpage(x, y, w, h, opts) to
   subclass a page into a restricted area (not necessarily rectangular, or
   bounded in height). Things like columns and table cells could then be
   treated as normal pages (inherit text and graphics contexts?) and anything
   could be put into them. May want to wait until have virtual write 
   capability rather than writing to file right away, for fitting table cells
   into a page, and balancing columns. Once in, build-in PDF::Table capability
   as PDF::Builder::Table, and can have arbitrary content in a table cell.

=============================================================================
III. A new architecture, in a new package

These are things that would be useful in being able to handle page design
in a higher-level manner. This would almost certainly be another package,
such as PDF::Builder::Environments.

A. Introduce the concept of environments, which take care of handling much of
   the busy-work of laying out a page.

   page -- including margins (define the work area); page numbering, outline,
           and slider thumb consistent page numbers; headings/footings. also 
           odd/even page layouts, odd-only, or single page (roll printer) layout
     column(s) -- define single or multiple columns, not necessarily of
                  rectangular outline or of the same width or height. lower
                  level environments can modify the initial outline (eat
                  away at it). balanced columns could be done
       heading -- per column or per page, keep together along with first two
                  lines of following paragraph
       footnote -- per column or per page, grows up from the bottom and can
                   spill to the next page. mostly for keeping track of the
                   bottom of the usable area
       margin note -- a minipage eating into a column and margin, limited to
                      column height. must be defined before filling column
       inset -- usually rectangular (but could be any shape) that eats into
                the space for one or two columns
       floats -- per column or per page, for images, etc., may float left or 
                 right (but not cause a hole in the middle of a column)
       table -- per column or per page, somewhat like PDF::Table, but probably 
                only fixed width columns, and content fill left to author
       list -- per column or per page; sl, ul, ol, dl; content fill left to
               author
     span all or selected columns
       heading 
       footnote
       floats -- may be centered here
       table
       list

   The idea is that you start an environment (either implicitly or explicitly)
   and are responsible for all the content. At the start, you are told the
   position of the upper left corner (not necessarily a baseline), the allowed
   width, and the maximum height on this page. You fill in the content as you
   wish. At the end, you close the environment. The current PDF::Builder is
   only used for low-level stuff (primitives); the higher-level structure is
   in this package.

   The purpose is to allow you to put any kind of content anywhere, such as
   another list within a list item, or another table within a table cell (as 
   well as a table within a list or a list within a table cell). The current
   PDF::Table severely limits your content to (currently) simple text of
   constant font, font size, color, etc. It is up to you to obey the limits
   of the extent of your content (no checks for overflow). Some environments
   (e.g., insets) will eat into the real estate defined for their parents, so 
   they will have to be fully defined and filled before you start filling 
   their parents.

   A table row would need to be defined (filled) before ink can be put down,
   so there may also need to be a table row environment. To handle vertical
   alignment, or decide where to split a row across a page break, the table
   environment needs to know the height of each row. This may need a means of
   tentatively writing a virtual row, moving part to a new page (or down their
   cell) if necessary, and commanding that the ink be put down. It may even be
   necessary to move the entire row to the next page (e.g., a cell's content
   is an image). Note that a new page is handled by the top-level program, 
   rather than having one automatically created -- unlike PDF::Table, 
   permitting more control over the layout and appearance.

   Balanced columns could be done. If the columns are purely rectangular (no