Re: Auto-resize paper size during document run?

[Oliver Corff]

Hi Larry,

thank you for your commment. In general, I totally agree with you, both
as an author and an editor.

Tables should be made visually pleasing, otherwise they'll hide, rather
than present, the information in them.

In my current case, the situation is a bit different, though. The
materials I am working with are historical sources which I reproduce,
and since I've decided to stick as closely to the original look and feel
as technically feasible and possible, I cannot alter the table
presentations of the original work in any substantial manner. The
original book was typeset in two columns per page, with _large_ tables
spanning across two columns. Appropriately, I use .1C before and .2C
after the table, which works just fine. In a few cases however, the
original authors made tables which were rotated by 90 degrees, to be
perused in landscape mode, and where this was not sufficient, they
constructed tables spanning over two pages --- in one or two cases you
had to turn pages to read the continuation! I decided to ignore these
pagebreaks, but I opted for reproducing the full-width material. In
parallel to these super-wide tables, there are a few organization
diagrams which also span across two fully opened pages --- I scanned
them and reproduce them as original material.

Finally, some tables in the original sources leave me perplexed. While a
few were squeezed horizontally via some apparent postscript shink-to-fit
magic (as can be judged by the weird and inappropriate weight and
proportions of the typography), other tables (a handful only) are
slimmer in the original source than they turn out in my reproduction,
even though I tried all sorts of tricks with zero column widths in tbl.

In general, of the 1380-odd tables I remade for this project, an
overwhelming majority of them looks so strikingly similar to the printed
original that I am convinced the original books were typeset with the
roff toolchain (groff was not yet available).

Anyway, for the few candidates in question, I'll try the suggested \X'ps
calls, and --- thank you for this one! --- I'll try  to split the few
beasts across a two-page spread as suggested.

Have a nice weekend,

Oliver.


On 29/05/2021 05:02, Larry Kollar wrote:
> James K. Lowden <jklowden@schemamania.org> wrote:
> > > Of course, I can typeset the table separately and assemble the pdf
> > > pages by hand, but a solution totally controlled from within the
> > > groff file would be great.
> > Not an answer, but in ancient times, your output would have gone a
> > printer, which might have had different paper in different trays.  It
> > woudn't be unusual to use legal-size paper in landscape mode for tables
> > with 30 or more columns, with no opportunity to use pstricks.
> Another, more robust (in several ways) solution would be to refactor the table.
> There are situations where that isn’t possible, but they’re not as common as
> one might think. The thing is, tables are a big chunk of non-reflowable content
> inserted into content (text) that otherwise flows really well because it’s 
> *roff.
>
> One way to go about it is to ask, “What information is this trying to impart? Is
> there a different way to go about it?” I’ve reduced several huge, complex tables
> to a far simpler format that way (and did the same for a co-worker, who saw
> the benefits immediately). Tables are often abused as a special form of list, 
> and
> that means many tables can be restructured as lists.
>
> > I've often wished for a groff cookbook of odd tricks, such as how to
> > print envelopes. A quick glance at Adobe's Postcript reference manual
> > turns up "setpagedevice", which looks to be its ioctl: it seems to be a
> > set of device-specific name-value pairs for doing things like selecting
> > paper trays and telling the printer to stop while the envelope is
> > inserted.
> >
> > No problem for groff; that's what  \X'ps: exec code' is for. Sadly, in
> > 2021, I have no idea where to obtain the Postscript device-specific
> > features for any printer, or whether such information is even published
> > anymore.
> That was my second thought, after “get rid of the table[1],” to use \X’ps:etc’
> to rotate it. Another possibility is to split it across a two page spread, if it
> really *has* to be a table. Find a good halfway point in the columns, and split
> it vertically. Use the absolute space request (for example, .sp |2i) in front of
> both halves so they line up across the pages.
>
> — Larry
>
> [1] Over a loooooong tech writing career, I’ve come to despise tables. I
> recently had an article published in the Center for Information Development
> Management (CIDM) newsletter called “Tables Must Die!” Full disclosure of
> bias has been delivered. :-P