/Bespoke14 for /A3

[jdaw1]

The placement of circles on the page is controlled by PackingStyles. The general mathematical problem, largest possible radius for n non-overlapping circles in a particular rectangle, is difficult (see PackoMania for solutions to many special cases). The code has enough generality that it often finds the best, and when it can’t, its radius is not much smaller than the mathematical optimum.

Over a plausible range of parameters, the largest failing (or maybe a near-largest failing), measured as best possible minus currently findable, is for 14 glasses on /A3. The mathematical optimum is bigger by ≈0.46%, increasing the diameter by ≈0.39mm, but comes at the aesthetic cost of a loss of symmetry (svg, nb, pdf).

¿Should there be a Bespoke14? (The candidate name chosen to rhyme with the already-existing Bespoke5 and Bespoke7.)

Short answer: No.

Mathematica reveals the GroebnerBasis[] for this system to be a polynomial of order 18.

The largest coefficients are of the order of the page size to the power 18. With margins at their default values, /A3’s usable width ≈ 1143pt, which to the 18th power ≈ 10⁵⁵, far exceeding PostScript’s single-precision limit of ≈ 3.4×10³⁸. So rescale: fix the width at 1; set h for the correct aspect ratio of the de-margined paper size, and solve for an r which will then need to be post-multiplied by the original w.

That root finding requires repeated computation of the value of an order-18 polynomial, when the answer is near zero. Small computation errors could erroneously flip the sign of that value, preventing the finding of the correct r.

And, alas, this is what happens.

A test has been done with some simple (and slightly scrappy) PostScript producing a pdf of charts.

• The grey curve is the correct value of the polynomial, as computed to enough precision in Mathematica and hard-coded in the PostScript.
• The ends of the axis are labelled in red, showing both the actual r in pt, and the re-scaled r as a proportion of w.
• In black are labels at the zeroes and turning points of the true polynomial, again from Mathematica.
• And the dots, hollow circles, are the values of the polynomial as computed in PostScript’s single-precision arithmetic.
  

Oh dear. What a mess. Obviously the correct r must be before the first turning point. Even if we magically knew that this was at ≈ 133.113, then it would be known that the answer is in the range from first negative value to last positive. That spans 121.247pt → 132.865pt, an uncertainty in the diameter of the glass of almost 8.2mm. Which would be hopeless.

That leaves a different possibility. For a dense set of specific aspect ratios, the correct values could be computed in Mathematica, and hard-wired into the PostScript code. If Bespoke14 were beautiful, I might do this. It isn’t; I won’t.

There is another alternative, which is to push the problem to the user. Assuming default values of MarginL = MarginR = MarginB = 24pt, and MarginT = 30pt (because ∃ headers), then the required positions could be computed outside PostScript, and inserted by the user into PackingStyles. One of the following elements would suffice.

	[ /Array /Positions
		[ 123.02454 123.02454] [ 123.02454 388.15072] [ 123.02454 664.86522]
		[ 330.30980 255.58763] [ 326.48811 526.50797]
		[ 537.59507 123.02454] [ 533.77337 393.94488] [ 529.95168 664.86522]
		[ 778.56085 172.78037] [ 778.56085 418.82945] [ 776.00076 664.86522]
		[1019.52664 123.02454] [1019.52664 369.07363] [1019.52664 617.21712]
	]

	[ /Array /Positions
		[1019.52664 123.02454] [1019.52664 388.15072] [1019.52664 664.86522]
		[ 812.24138 255.58763] [ 816.06307 526.50797]
		[ 604.95611 123.02454] [ 608.77781 393.94488] [ 612.59950 664.86522]
		[ 363.99033 172.78037] [ 363.99033 418.82945] [ 366.55042 664.86522]
		[ 123.02454 123.02454] [ 123.02454 369.07363] [ 123.02454 617.21712]
	]  % With x => w-x

	[ /Array /Positions
		[1019.52664 123.02454] [1019.52664 388.15072] [1019.52664 664.86522]
		[ 812.24138 255.58763] [ 816.06307 526.50797]
		[ 604.95611 123.02454] [ 608.77781 393.94488] [ 612.59950 664.86522]
		[ 363.99033 172.78037] [ 363.99033 418.82945] [ 366.55042 664.86522]
		[ 123.02454 123.02454] [ 123.02454 369.07363] [ 123.02454 617.21712]
		14 -1 2 {1 roll} for
	]  % With x => w-x, reordered

That’s all you’re getting.

---

Computation of r for the style /Temple entails solving an octic equation. The above reasoning caused a worry: does /Temple have precision problems?

Answer: tolerable.

A similar analysis to the above (pdf) shows an error in the radius just under 0.02pt, so an error in the diameter of ≈ 14µm. For a 1200dpi printer, so 16⅔ pixels per point, 0.02pt is ⅓ of a pixel.

Such an error is de minimis.

---

Ten files: 2×.nb + 2×.ps + 2×.log + 2×.pdf, and 2×.png.

[jdaw1]

This question arose when making the placemats for a tasting in October 2021. The following two-frame GIF shows the used placemats in the /DiamondsAndRectangular style, and how they would have appeared in the /Bespoke14 style (implemented manually using the above /Array /Positions … code).

And the increase in the diameter (of ≈ 0.39mm ≈ 0.016″ ≈ 1.1pt ≈ 0.46%) is much less than the increase in ugliness. Hence Won’t Fix.