Re: Oversized Tables - how to produce non-truncated PDF?

[Oliver Corff]

Hi Branden,

thank you for everything!

At the moment I cannot recall whether I even tried A2. Something along
the process chain did not seem to work well, but as the attempts to
create these behemoths took place approx. 3 years ago I do not remember
exactly the command setup and, in case of failure, its specific failure
mode.

While most of the approx. 1.200 tables of my project fit well on one
sheet, I had a batch process (or rather, a system call from inside a
perl script that converted the table to every desired output format on
the fly). The big ones are just a handful and I never bothered to make a
shell script which auto-adjusts for the size of the table.

Best regards,

Oliver.


On 18/07/2024 23:13, G. Branden Robinson wrote:

Hi Oliver,

At 2024-07-18T22:07:33+0200, Oliver Corff wrote:

after a long period of silence I return.

Welcome back!


The publication project containing so many tables (yes, my friendly
tbl primer waits to be finished) is finally coming to a positive end.
Currently, I am going through the last stages of proofreading. There
is one problem I fail to solve: some of the huge tables which in my
original sources spread over two book pages, appear truncated by the
PDF, no matter what papersize I try to set (e.g. like A3).

Did you try going even bigger, like A2 in landscape orientation?
Because that works for me, with both groff 1.23.0 and Git HEAD
(technically my working copy[1]).


I attach an example of material cut off at the right margin
(1985_1006_Politbuero.{tbl,pdf}.

Arguably, the material displayed in this table could also be expressed
in other ways, e.g. as an html table (thank you, Ingo, for helping me
with the conversion from tbl to html!), but there are a few more
oversized tables in my material and for a multitude of reasons,
including fidelity to the sources, I do not want to reshuffle the
appearance of these tables while preserving only their content.

I don't think any of that will be necessary.


Thank you for any hint!

Here's what I did:

$ groff -t -dpaper=a2l -P -pA2 -P -l ./ATTIC/1985_1006_Politbuero.tbl >| 
politburo.ps
$ evince politburo.ps
$ groff -t -dpaper=a2l -Tpdf -P -pA2 -P -l ./ATTIC/1985_1006_Politbuero.tbl >| 
politburo.pdf
$ evince politburo.pdf
$ ~/groff-stable/bin/groff -t -dpaper=a2l -Tpdf -P -pA2 -P -l 
./ATTIC/1985_1006_Politbuero.tbl >| politburo.pdf
$ evince politburo.pdf
$ ~/groff-stable/bin/groff -t -dpaper=a2l -Tps -P -pA2 -P -l 
./ATTIC/1985_1006_Politbuero.tbl >| politburo.ps
$ evince politburo.ps

Attaching the PDFs generated by groff 1.23.0 and HEAD.[2]

Does this address your issue?[3]

Regards,
Branden

[1] ...but not many changes from origin/master are in this branch yet.

aefbf42b5 (HEAD) [troff]: Refactor has_arg() to support copy mode.
017779a9a [troff]: Fix Savannah #65977 (early `device` req).
e41cbff3d [troff]: Trivially refactor (`get_long_name()`).
c415e26da (origin/master, origin/HEAD) bootstrap: Resync with gnulib upstream.

[2] The generated-by-HEAD attachment is much smaller.  I believe this is
 due to Deri's new font subsetting feature in gropdf(1).

 $ ls -hs1 /tmp/branden/politburo-groff-*
 212K /tmp/branden/politburo-groff-1.23.0.pdf
  40K /tmp/branden/politburo-groff-HEAD.pdf

 That's one of several PDF improvements to boast of in the next groff
 release.

 Incidentally I am reminded that we should probably make gropdf(1)'s
 `-e` option the default behavior since that (inclusion of any font
 resource used) is what the PDF standard now mandates.  Comments?

[3] Meanwhile, emailing this document full of names of GDR leaders has
 tripped U.S. intelligence agency flags and I'll be hunted down by
 President Trump's anti-communist death squads come January.  Guess
 I'd better get groff 1.24 out this year, huh?


--
Dr. Oliver Corff
Wittelsbacherstr. 5A
10707 Berlin
GERMANY
Tel.: +49-30-85727260
mailto:oliver.co...@email.de

GNU troff converted to checked integer arithmetic

[G. Branden Robinson]

Hi folks,

I've made my "deepest" change yet to the formatter, altering code that
hasn't changed since James Clark wrote it circa 1989.   However, I think
it unlikely that any user will notice any difference.

Traditionally, *roff arithmetic is a thin wrapper around C arithmetic,
using signed integers.

Signed integer overflow is undefined behavior in standard C.

Historically, C users have assumed that overflowing signed integers
would wrap around from the maximal to minimal value (changing sign) and
vice versa.  But there's never been a guarantee.

And *roff users, when thinking about it at all, have likely made similar
assumptions...most of the time.  In GNU troff under limited
circumstances, arithmetic won't wrap.  (I leave identification of these
as an exercise for the reader.  The answer key is in the groff ChangeLog
and Git commit messages.)

If you enabled the `-ftrapv` compiler option, signed integer overflow
would cause the formatter to SEGV.

This was .

I have therefore migrated GNU troff arithmetic to use 
checked arithmetic.  This is part of C23, but also implemented by
gnulib, so we have it no matter what the platform.

This change lays a foundation for migration of GNU troff arithmetic from
wrapping behavior, which is not useful in a typesetting application, to
saturating arithmetic, which suits such a purpose better.

https://savannah.gnu.org/bugs/?66001

In fact I have 3 applications of saturating arithmetic already in mind.

https://savannah.gnu.org/bugs/?63587
https://savannah.gnu.org/bugs/?63837
https://savannah.gnu.org/bugs/?65190

Needless to say(?), all of our tests continue to pass, and I added one
for several extremal arithmetic operations in the bargain (and a couple
of mundane but tricky ones I stumbled over while working on this).

I also sliced the commits very finely to aid future Git bisection in the
event I messed up some corner case.

(I wanted to cite a classic CS paper here about integer arithmetic
setting forth the alternatives of trapping, wrapping, and saturating,
but while I've read it, I can't find it now.  :-/ )

Regards,
Branden


signature.asc
Description: PGP signature

Re: GNU troff converted to checked integer arithmetic

[G. Branden Robinson]

[self-follow-up]

At 2024-07-19T14:47:01-0500, G. Branden Robinson wrote:
> (I wanted to cite a classic CS paper here about integer arithmetic
> setting forth the alternatives of trapping, wrapping, and saturating,
> but while I've read it, I can't find it now.  :-/ )

Saying this and sending the mail kicked it loose as I thought it might.

C. A. R. Hoare's "An Axiomatic Basis for Computer Programming"[1]
set these forth as "strict", "firm", and "modulo", respectively.

Regards,
Branden

[1] https://dl.acm.org/doi/pdf/10.1145/363235.363259


signature.asc
Description: PGP signature