/ placemat Public

/Bespoke14 for /A3#151

Closed
opened this issue Jul 3, 2021 · 1 comment
Closed

/Bespoke14 for /A3 #151

opened this issue Jul 3, 2021 · 1 comment
Labels
enhancement New feature or request wontfix This will not be worked on

 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. The text was updated successfully, but these errors were encountered:
added enhancement New feature or request wontfix This will not be worked on labels Jul 3, 2021

jdaw1 commented Oct 19, 2021

 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.

mentioned this issue Oct 24, 2021
closed this as completed Jan 1, 2022