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

[Zdenek Wagner]

Well, using complex numbers, double numbers, tensors, wave functions
and other algebras make no sense because whatever you display is a
projection onto a 2D Euclidean space. The original object need not
even be metric as is very frequent case in physical chemistry. Your
example with a subpart of a subpart ... of a subpart makes no sense as
well. There is a limit on the maximum number of object and on the
number of elements of a path. There is no standard, it is device
dependent and implementation dependent. If the limit is exceeded, the
RIP reports a fatal error. Thus if you create anything with too deep
zoom nesting, the result will be a RIP crash. In display postscript,
"0 setlinewidth" should result in a technically thiniest line but in
phototypesetters such line usually disappears. The same applies to a
too small font size. If you run the file through preflight, it defines
safe smallest limits which should work an all devices and will
guarantee that the RIP will not crash and the result will be the same
as on your device. Thus you never need resolution of 0.001 bp thus
three decimal digits are enough. If your application requires more, it
means that it cannot be represented in PS or PDF and you need your own
preprocessor. Look eg at Google Maps. They are not just zoomed in and
out, when zoomed out small objects disappear because the source has
several layers for different zoom levels. In addition, rendering times
increases at least quadratically, thus if you request changing the
details from 1 bp to 1e-6 bp, then the time requirement will increase
by 12 orders of magnitude. Assume that rendering a usual page will
take 1 ms. In your example it will need almost 32 years.

Zdeněk Wagner
https://www.zdenek-wagner.eu/

čt 14. 3. 2024 v 3:55 odesílatel Al Ma <alma0 at ro.ru> napsal:
>
> 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, <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                    mailto:reinhard.kotucha at gmx.de
> ------------------------------------------------------------------
>