# RE: BoundingBox in PostScript output for A4 is too large and the computation with its comment are bogus

Al Ma alma0 at ro.ru
Thu Mar 14 03:55:48 CET 2024

```My main point was more about the terminology than about the precision of the representation. It's unnecessary to use the name of a large set (here: the real numbers) if you have a good name for a smaller set where all the really occurring values lie (here: the rational numbers, the rationals, the numbers representable in a decimal form, …). An artificial example: though technically the high-resolution–box values can also be viewed as complex numbers, it'd be even more pointless and distracting to talk about the complex numbers (as compared to the reals, and, even more so, to the rationals).
Now, as you've talked about the precision/accuracy, consider this:
1 bp = 1/72 in = 1/72 in · 2.54 cm/in = 1.27/36 cm = 0.352 + 7/90000 cm = 0.03527(7) cm = 0.3527(7) mm = 352.7(7) µm.
So 0.001 bp = 0.3527(7) µm = 352.7(7) nm < 380 nm, an approximate lower bound for the visible light length. Strictly less. Such a justification of at most 3 decimal digits after the decimal separator is fine so far; I agree.
Until, for whatever reason, the typesetter, be it a human or an automatic printing procedure or an export-as-PostScript procedure of whichever program, provides details that are visible only under zoom (say, the details of a technical drawing). A drawing of a visible object (e.g., a building, a mechanism, an electrical device, a portion of the night sky …) may contain parts, which contain subparts, which contain subparts, … – with lots of nesting (nowadays, down to the details of 18 ångström for the microchips). For microchips, e.g., a resolution of 10 Å = 1 nm = 0.001 bp / (352+7/9) = 9 / (352·9 + 7) 10⁻³ bp = 9 / (352·9 + 7) 10 ⁻³ bp = 9000/3175 · 10⁻⁶ bp = 360/127 · 10⁻⁶ bp ≈ 2.834645669 · 10⁻⁶ bp = 0.000002834645669 bp would probably suffice for now. Opposite to that, consider fitting the constellation Fornax into the landscape DIN A4 format and providing the zoom for the most distant visible objects therein at 33.6 Gly – let us leave this as an exercise to the students – my hunch is that dozens of digits after the decimal separator would be needed.
Therefore, if we talk about precision at all, my point is that, from the viewpoints of the typesetter and viewer (and NOT from the viewpoint of how various programs work now), it makes little sense to fix any particular number of digits after the decimal separator.
Now I have to turn to other tasks and am going to (probably, temporarily) unsubscribe from the mailing lists tex-live and tex-k for the moment.
Cheers and thank you all,
AlMa
11.03.2024, 06:46, < mailto:reinhard.kotucha at gmx.de reinhard.kotucha at gmx.de >
On 2024-03-10 at 04:45:51 +0000, Al Ma wrote: >> I think that it's quite useful to provide a HiResBoundingBox >> comment as well. The latter allows real numbers instead of >> integers. > Almost no reals can be spelt out. Do you probably mean the > rationals or the rationals representable in decimal notation? > Notice that the width of A4 is 21 cm / (2,54 cm/in) × 72 pt/in = > 75600/127 pt, which cannot be represented exactly using the decimal > notation. It's not necessary to provide exact values. Assume that that 1 bp is about 0.35 mm. With three decimal digits the resolution is 350 nm, the wavelength of visible light. The resolution of a phototypesetter (2540 dpi) is 10 𝜇m. There is absolutely no need to express 75600/127 with more than 3 or 4 decimal digits. Even then additional rounding errors will be introduced by successive processing steps. But three or four decimal digits are better than none. Regards, Reinhard -- ------------------------------------------------------------------ Reinhard Kotucha                            Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover /compose mailto:reinhard.kotucha at gmx.de ------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-live/attachments/20240314/871274b1/attachment-0001.htm>
```