ThePortForum.com

DRT wrote:

jdaw1 wrote:

DRT wrote:

jdaw1 wrote:

DRT wrote:Printing each person's placemat followed by their tasting note sheets solves that problem completely.

Which has been the default behaviour for some years.

Perhaps that is why I perceived the set provided for this tasting to be a problem.

That would be these placemats, exhibiting exactly the same default behaviour, would it? Unless Rob’s faffing caused the problem.

User error.

jdaw1 wrote:

jdaw1 wrote:

PhilW wrote:I'd suggest that the [x y] scales should be of the same proportion (which they are either not, above, or you have additional column gaps which I don't believe you don't intend if they are). So for the example you are creating, with proportionate scales the elements would be [ [0 4] [2 4] [4 4] [6 4] [0 2] [3 2] [6 2] [0 0] [3 0] [6 0] ].

In most other layout designs I have adopted the general principle of using the whole page. For example, in the placemats for the Star Quality tasting, observe the small gap between the columns the constraint on circle size was y not x. If this code scaled the two directions the same, then typically there would two large gaps, either left and right, or top and bottom.

Or have I misunderstood what you are advocating?

jdaw1 wrote:

PhilW wrote:I'd suggest that the [x y] scales should be of the same proportion (which they are either not, above, or you have additional column gaps which I don't believe you don't intend if they are). So for the example you are creating, with proportionate scales the elements would be [ [0 4] [2 4] [4 4] [6 4] [0 2] [3 2] [6 2] [0 0] [3 0] [6 0] ].

In most other layout designs I have adopted the general principle of using the whole page. For example, in the placemats for the Star Quality tasting, observe the small gap between the columns the constraint on circle size was y not x. If this code scaled the two directions the same, then typically there would two large gaps, either left and right, or top and bottom.

Or have I misunderstood what you are advocating?

jdaw1 wrote:That code fragment has been updated to

Code: Select all

		<<
			/OutputFaceUp DefaultOutputFaceUp 4 index {not} if  /Duplex false
			/ImagingBBox null  /PageSize [PageWidth OuterMarginL OuterMarginR add add  PageHeight OuterMarginB OuterMarginT add add]
		>> setpagedevice

this starting with two things on the stack, the lower of which is the rotation boolean.

AHB wrote:a possible approach that has not been discussed yet would be for the person applying the output from the PS programme to count the bloody sheets as they are being laid out.

PhilW wrote:- If you draw radius 1 circles with the co-ordinates you specified as centre locations, you get the overlapping circles as shown in top left.
- If you draw radius 0.5 circles with your centre co-ords you get large spaces between columns, as per top right.
- You can achieve what I assume you intend as per middle left, but only by the x and y axes being non equal; if you make the axes equal (i.e. equal indices per inch) then you get the diagram at the middle right. Effectively you are not drawing circles in x,y (though you are drawing them in transformed axes).
- All I was suggesting was that to keep things simple for the user, using axes with equal indices to physical spacing would be simpler. The alternative co-ords I suggested with radius 1 circles generates the bottom left image, effectively identical to the mid-left which I assumed was as intended, but with equally spaces axes.
(minor note, I made the radii 0.95 rather than 1 for all the above to provide a little separation, if we're being precise )

jdaw1 wrote:

AHB wrote:a possible approach that has not been discussed yet would be for the person applying the output from the PS programme to count the bloody sheets as they are being laid out.

Yes, but could DRT do that without complaint?

DRT wrote:Scottish Conservative Party candidate trying to win a seat in a general election

DRT wrote:User error.

jdaw1 wrote:Extra reasoning for PhilW. If a user wished to have some arrangement of circles, on some paper size, that used all the available space, how should the user specify that? Bear in mind that the centres have x values from MgnL+Radius to PageWidth”“MgnR”“Radius, and that the user does not at this time know the Radius.

My view is that the user may specify circles over arbitrary x and y ranges, and that then a radius will be computed and an affine transformation applied to the centres.

jdaw1 wrote:Are you saying that the code should scale x and y by the same factor?

PhilW wrote:No (although that could be a further option were a sparse design required) I was only suggesting that (for an arbitrary design) I would find it simpler to specify the [x y] pairs as if they represented co-ordinates of the centre of circles drawn on an equally spaced grid with equally spaced axes; and then you then fit that pattern of circles with appropriate circle sizing, spacing etc as best fits page/margin criteria as usual.

jdaw1 wrote:

PhilW wrote:No (although that could be a further option were a sparse design required) I was only suggesting that (for an arbitrary design) I would find it simpler to specify the [x y] pairs as if they represented co-ordinates of the centre of circles drawn on an equally spaced grid with equally spaced axes; and then you then fit that pattern of circles with appropriate circle sizing, spacing etc as best fits page/margin criteria as usual.

Your answer appears to be self-contradictory. I am too deeply puzzled to continue without some pseudo-code from you. Given the array, and a usable W and H (they being page dimensions less margins), what happens next?

pattern_width=(max(x[1..n])+1) - (min(x[1..n])-1)
pattern_height=(max(y[1..n])+1) - (min(x[1..n])-1)
scale_x = W/pattern_width
scale_y = H/pattern_height
realx[1..n] = scale_x * x[1..n]      // (but see *note)
realy[1..n] = scale_y * y[1..n]      // (but see *note)
max_circ_dia_x = 2*scale_x
max_circ_dia_y = 2*scale_y
if max_circ_dia_x > max_circ_dia_y then circ_dia = max_circ_dia_y else circ_dia = max_circ_dia_x

*note: this scaling only works if min(x)-1==0 and min(y)-1==0 and otherwise would need the appropriate offset taking into account; I have omitted this for clarity.

jdaw1 wrote:Thank you. Typically I want the radius to be as large as possible. I think that you assume that the radius, on at least one of the scales of the user, is unit. In easy rectangular cases that won’t overly tax a user, but in general isn’t so good. E.g., [ [0 2] [2 2] [1 1] [3 1] [0 0] [2 0] ].

jdaw1 wrote:My code would then choose the radius and separately scale the x and y directions such that things fit as snugly as possible, obviously subject to the other upper bounds on the radius.

PhilW wrote:With the centre-points specified, it would still be necessary to test largest valid radius to avoid overlap (with/without spacing).

jdaw1 wrote:

jdaw1 wrote:My code would then choose the radius and separately scale the x and y directions such that things fit as snugly as possible, obviously subject to the other upper bounds on the radius.

PhilW wrote:With the centre-points specified, it would still be necessary to test largest valid radius to avoid overlap (with/without spacing).

Are we disagreeing?

PhilW wrote:Test1 : [0,0] [1,1] [2,1] [3,0]
Test2 : [0,0] [2,2] [4,2] [6,0]
Test3 : [0,0] [2,1] [4,1] [6,0]
How would the above three examples differ in final rendered appearance?
I think (hope) you can the desired pattern achieved; if any of the above differ, which spec would the user be expected to supply, and why?

jdaw1 wrote:

PhilW wrote:Test1 : [0,0] [1,1] [2,1] [3,0]
Test2 : [0,0] [2,2] [4,2] [6,0]
Test3 : [0,0] [2,1] [4,1] [6,0]
How would the above three examples differ in final rendered appearance?
I think (hope) you can the desired pattern achieved; if any of the above differ, which spec would the user be expected to supply, and why?

‟They ought to be the same”, I thought. And then tested them, and they were the same. Is that happiness?

jdaw1 wrote:[ [0 2] [2 2] [4 2] [6 2] [0 1] [3 1] [6 1] [0 0] [3 0] [6 0] ]

jdaw1 wrote:

jdaw1 wrote:However, I do agree that it would be neater if the two A1s touched. But how should that be expressed that in the parameter?

jdaw1 wrote:the radius and separately scale the x and y directions such that things fit as snugly as possible, obviously subject to the other upper bounds on the radius.

DRT wrote:I disagree that it would be neater if the two A1s touched. The image in the above post shows four glasses spaces on the top line that are evenly spaced. That is neat. Four glasses spaces on a line that are unevenly spaced would be less neat.

jdaw1 wrote:The radius chosen, those of the new form are then moved along the straight line from (x y) to (x1 y1), as far as possible without crashing into another circle. This will be done pairwise, each circle being moved a proportion p along the line, p chosen to be the lesser of 1 and first crash. Each circle will be moved the least of its pairwise p’s. (This is robust and simple, but wouldn’t handle complicated sequences of possible collisions.)

jdaw1 wrote:

DRT wrote:I disagree that it would be neater if the two A1s touched. The image in the above post shows four glasses spaces on the top line that are evenly spaced. That is neat. Four glasses spaces on a line that are unevenly spaced would be less neat.

Imagine that 0 = 1963, 1 = 1966, 2 = 1970. The touching is to bring together the two shipper-A 1966s (perhaps different sizes or different bottlers). Obviously if the four bottles in the top row had relationships to each other that were of the same type, such as all being different vintages, then equal spacing would be better.