Software that makes placemats

[jdaw1]

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.

One might think that the solution is to prevent such faffing. But the anti-faffing technology

uses A3 paper. When paper sizes are different, all of one is printed, then all of the next, to simplify control of the printer. Which brings us back to the same problem, for which the 180° technique is the best solution yet available. (E.g., 15 Dec 2011, The Bell.)

[jdaw1]

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?

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

[PhilW]

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?

I could have been clearer; quick diag:


- 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 )

[Alex Bridgeman]

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.

I have come up with a possible alternative approach that could cope with either faffed output (ie. all tasting mats together, all notes sheets together) or unfaffed output (ie. tasting mats and notes sheets printed as a set for each person). Provided the parameter NumberOfSheetsPerPerson is known then 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.

Are we not in danger of calling for a working group meeting just to open another bottle of T77?

[jdaw1]

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?

[jdaw1]

- 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 )

So, in your scheme, if the user wants to fill the page radius as large as possible the user has to know the paper size, the margins, and solve the quadratic. Hmmm: me no like. Typically we want to say ‟these in the same column, these in the same row, and these between that other column|row”. My scheme allows that.

Also, though I am applying a scaling factor to the user’s [x y] parameters, the circles will still be circles.”  I’m spreading them over the page.

”  Which is why the radius equation is a full quadratic, rather than an elementary square root.

[DRT]

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?

I am starting to feel like a Scottish Conservative Party candidate trying to win a seat in a general election. Perhaps I should form a coalition with Rob and say that I have have been a firm believer of using little sticky labels between each set all along?

[jdaw1]

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

User error.

[jdaw1]

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.

[PhilW]

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.

I think we're talking at cross-purposes - I don't disagree with anything in your last two posts; The only change I was suggesting was that in specifying the indices for the arbitrary arrangement, that I would have naturally used values for the y co-ordinate which were scaled by a factor of two compared with those you had used; the diagrams were intended to illustrate why. I agree that the user should not be consider page sizes, margins or quadratics in providing the arrangement.

[jdaw1]

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

[PhilW]

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

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]

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?

[PhilW]

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?

I don't think I'm suggesting any change to the next steps, I was only ever intending to help clarify the initial indexes so am reluctant to jump in with code... however since asked, I would expect the next steps to be (probably roughly as currently?) along the lines of:

Code: Select all

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.

thereby creating a list of [realx,realy] centred circles with diameter circ_dia

Hope that helps; I have a feeling that the confusion between us is probably something very simple which would be worked out in about 10sec face to face with a piece of paper... it might be better simply to ignore me for now - I wasn't suggesting something significant, it was supposed to be a minor clarification for ease of use!

[jdaw1]

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] ].

[PhilW]

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] ].

True, I was indeed assuming a unit radius for the layout specification and your counter-example shows the problem of overlapping. With the centre-points specified, it would still be necessary to test largest valid radius to avoid overlap (with/without spacing).

[jdaw1]

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.

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]

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.

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

Are we disagreeing?

Maybe not, if you can resolve this for me:
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]

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?

[PhilW]

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?

Am both pleased and surprised; happiness and silence is achieved.

[jdaw1]

Phil,

[ [0 2] [2 2] [4 2] [6 2] [0 1] [3 1] [6 1] [0 0] [3 0] [6 0] ]

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

Idea!

Currently the array contains items of the form [ x y ]. Perhaps, also allowed, could be [ x y x1 y1 ]. As now, glasses are placed at (x y), and then the code chooses

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.

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.)

So [ [0 2] [2 2 3 2] [4 2 3 2] [6 2] [0 1] [3 1] [6 1] [0 0] [3 0] [6 0] ] would make the two A1s touch.

Objections?

[DRT]

I have no wish to prolong this, but 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]

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.

[jdaw1]

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.)

The simple algorithm has the advantage of simplicity. Can better be done?

As an example, let the pattern include [ ! [-1 0 0 0] [0 1 0 0] [0 -1 0 0] ! ], and that the ellipses include circles much closer to each other, such that the three circles shown aren’t initially touching, and by a good margin. Then there are multiple solutions: for example, any of the three could land at (0, 0). And what about [ ! [-1 0 0 0] [0 2 0 0] [0 -1 0 0] ! ]?

Algorithm suggestions welcomed.

[DRT]

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.

I disagree. We have many tastings where two ports are more closely related than some others and have never had the need to do anything similar to this.

[PhilW]

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.)

The simple algorithm has the advantage of simplicity. Can better be done?

As an example, let the pattern include [ ! [-1 0 0 0] [0 1 0 0] [0 -1 0 0] ! ], and that the ellipses include circles much closer to each other, such that the three circles shown aren’t initially touching, and by a good margin. Then there are multiple solutions: for example, any of the three could land at (0, 0). And what about [ ! [-1 0 0 0] [0 2 0 0] [0 -1 0 0] ! ]?

Algorithm suggestions welcomed.

I see what you're aiming to achieve, but I think this might be over-complicating? For the more advanced case where a simple [x y] with subsequent affine transform (as currently) is not sufficient, I would suggest an easier option for the advanced user to make specific patterns would be to use an [x y] with affine=off - still performing suitable H/W scaling and max circle size selection as before.

In the example we've been using, you could move from the following with affine=on which creates the pattern with four regular along the top:
[ [0 4]; [2 4]; [4 4]; [6 4]; [0 2]; [3 2]; [6 2]; [0 0]; [3 0]; [6 0]; ];
to using the following with affine=off which would keep the required pair together.
[ [0 4]; [2.5 4]; [4.5 4]; [7 4]; [0 2]; [3.5 2]; [7 2]; [0 0]; [3.5 0]; [7 0]; ];
(or scaled up by 10 if we're only allowed to use integers, you get the idea).

This would then seem straightforward to use for any unusual bespoke patterns required?

[RAYC]

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.)

The simple algorithm has the advantage of simplicity. Can better be done?

As an example, let the pattern include [ ! [-1 0 0 0] [0 1 0 0] [0 -1 0 0] ! ], and that the ellipses include circles much closer to each other, such that the three circles shown aren’t initially touching, and by a good margin. Then there are multiple solutions: for example, any of the three could land at (0, 0). And what about [ ! [-1 0 0 0] [0 2 0 0] [0 -1 0 0] ! ]?

Algorithm suggestions welcomed.

This makes my head hurt...but i will be more than happy to give an opinion based on napkin sketches at the next tasting!

In general, the critical element to my eye is symmetry, and alignment of the first and fourth columns. I do not think i feel strongly about what i think you are debating.

[jdaw1]

over-complicating?

I plead the fifth.

In the example we've been using, you could move from the following with affine=on which creates the pattern with four regular along the top:
[ [0 4]; [2 4]; [4 4]; [6 4]; [0 2]; [3 2]; [6 2]; [0 0]; [3 0]; [6 0]; ];
to using the following with affine=off which would keep the required pair together.
[ [0 4]; [2.5 4]; [4.5 4]; [7 4]; [0 2]; [3.5 2]; [7 2]; [0 0]; [3.5 0]; [7 0]; ];
(or scaled up by 10 if we're only allowed to use integers, you get the idea).

This achieves something different. In the general case it could shrink the radii of the circles. I was trying to have, in order: the general pattern specified; radius as large as possible; then things touched. If the touching is done too early the radius would be shrunk.

Also, no requirement that numbers be integers. Easier for examples, but reals fine, subject only to the requirement that yi≠yj ⇒ division by (yi”“yj) does not produce an error.

[PhilW]

This achieves something different.

True, although I thought it might be useful for the general case for other purposes too (rather than simply enabling the touching issue) as well as providing a possible solution to that specific example. Agreed that it could lead to non-maximised circles, which I would have accepted in return for ease of use. Always just suggestions though, no problem with them being rejected

[jdaw1]

So, just to check, please confirm that you think that the current generality of outcomes is sufficient.

[DRT]

So, just to check, please confirm that you think that the current generality of outcomes is sufficient.

Rob and I vote yes. Three times each.

[PhilW]

So, just to check, please confirm that you think that the current generality of outcomes is sufficient.

Aye. For now

[jdaw1]

This makes my head hurt...but i will be more than happy to give an opinion based on napkin sketches at the next tasting!

The proposed new feature would allow a move of the two circles from their evenly-spaced position (green) to a central-touching position (black). I thought that this is what you wanted for the GC/SW/QH tasting, with the horizontally central circles being the 1977s.

However, the consensus is that it isn’t needed, so won’t be added. (Unless I’m bored, at home, and for some reason unable to work on the book.)

[jdaw1]

First feedback on sticky sheets do we have water tick-boxes?

(There was also a link to this post on FTLoP, but it was deleted. Still pretending to be the only port forum on the web. Cool.)

[jdaw1]

Presumably there should be a flag specifying whether the water boxes go on the glasses sheets or the TN sheets. If the latter, a possible location is shown in green. (This example derived from the first page of the ‘Placemats’ (meaning stickers and tasting-note sheets) used at The Bell on Thu 15 Dec 2011.)

Does that work? It certainly intrudes into the space for the last port’s tasting note. Should the boxes be on the other side, so also switching ↔ name? Or should the boxes surround the name?

Indeed, should the water boxes always be on the TN sheets?

[g-man]

I check off on the placements actually since i usually drink some water with pen still in hand after drinking previous port.

This way I check off, put pen down, grab next glass all from the same sheet.

[jdaw1]

I check off on the placements actually since

You probably check the glasses sheets because that is where the check-boxes are, at least currently. But should they be?

[jdaw1]

Alternative arrangement in dark red.


Or the name could be one box to the left, with the boxes starting one row further down (shown in purple).


Comments?

[SushiNorth]

Presumably there should be a flag specifying whether the water boxes go on the glasses sheets or the TN sheets.
Indeed, should the water boxes always be on the TN sheets?

Choices: Tasting Note, Placemat, Both

I might choose both, and print that way, then the taster can decide.

[jdaw1]

Choices: Tasting Note, Placemat, Both

‘Both’ is an excellent suggestion. What should be the default? And where on the TN sheet should the boxes go.

Currently there is a line

Code: Select all

/WaterCounts true def

This might become something like

Code: Select all

/WaterCountLocations /Both def  % /Glasses /TastingNotes /Both /None

[Glenn E.]

Indeed, should the water boxes always be on the TN sheets?

No. I have a notebook that I use when taking Port TNs, as do most of the people with whom I taste, so I typically do not even print the TN sheets. Yet I do find the water boxes useful and would like to continue having the option of them being on the placemat itself.

[jdaw1]

and would like to continue having the option of them being on the placemat itself.

Wilco. SushiNorth’s ‟Both” is looking better and better.

[SushiNorth]

Presumably there should be a flag specifying whether the water boxes go on the glasses sheets or the TN sheets.
Indeed, should the water boxes always be on the TN sheets?

Btw, I vote for a solid line (clarification: of tickboxes) across the bottom -- after all, I'll probably have it flat on the table, it's good to just be able to tick them casually as I go. Unlike the placemats, they won't be covered with glasses.

[PhilW]

Presumably there should be a flag specifying whether the water boxes go on the glasses sheets or the TN sheets.
Indeed, should the water boxes always be on the TN sheets?

Btw, I vote for a solid line (clarification: of tickboxes) across the bottom -- after all, I'll probably have it flat on the table, it's good to just be able to tick them casually as I go. Unlike the placemats, they won't be covered with glasses.

Agree with horizontal preference over vertical (though am happy with current 'cluster'). Personally prefer them bottom right (since am right handed), either next to the name or would happy with initials being bottom left instead with logo+glasses cluster at right (option: left side for lefties, right side for righties?).

[jdaw1]

Henceforth let’s assume right-handed. Obviously sides reversed for lefties.

I think I would prefer having icon and name on the left, and water boxes on the right. The water boxes would be in a cluster, like the green example above, excepting on the right.

Does that work for others?

[DRT]

That works for me.

[PhilW]

Henceforth let’s assume right-handed. Obviously sides reversed for lefties.

I think I would prefer having icon and name on the left, and water boxes on the right. The water boxes would be in a cluster, like the green example above, excepting on the right.

Does that work for others?

Sounds fine.

[Alex Bridgeman]

My preference would be to have the tick boxes on the glass sheet (because I will often make my notes, fold up and safely stow away for later use and then carry on drinking) but where no glass sheets are used then having checkboxes on the tasting notes pages would work.

Of course, instead of glass labels 23 and 24, perhaps I could have had an adhesive water glass label that I stuck on my water glass and ticked off as I went along.

[jdaw1]

perhaps I could have had an adhesive water glass label that I stuck on my water glass and ticked off as I went along.

Interesting idea. If water glasses are large wine glasses, with stem and foot, that might work. But it would be more awkward on a pint glass.

[jdaw1]

and would like to continue having the option of them being on the placemat itself.

Wilco.

But what if there aren’t placemats? What if it’s stickies? AHB’s suggestion of a water-box sticky is growing on me and it wouldn’t have to be stuck to a glass.