Software that makes placemats

[jdaw1]

At The Bell, for the Christmas tasting on 16 December 2010, for the first time, glass stickers were used rather than placemats. At the Bell glasses and space is tight, there just not being space for each person to use three pages of A4 of table.

The following quotations all come from the review thread.

• Paperwork (tasting-note sheets, and several sets of stickers).

This was the first placemat-free tasting, with glasses being identified with stickers. Feedback welcomed.

Stickers for glasses works really well, except that we need one sheet of stickers person (or per two people) as we were constantly passing the sheets around and trying to find our respective labels - at one point [somebody] put one of his on his forehead so he could find it later!

Problems:

• At the time the PDF is made, it isn’t yet known who will be sitting next to whom.
• One sheet has 65 stickers, so one sheet per person would waste two-thirds to three-quarters of each sheet.

Indeed one sheet per person would be too much waste; but would it be possible to slot the stickers of two or three people on equal sections onto one sheet (each person has ~20 stickers)? They could be after printing cut into the portions of the individual person.

The stickers also worked extremely well; thanks Julian. As Wolfgang suggested, the only improvement would be to have each person’s stickers as a block so they could be cut up and distributed before the tasting starts. Also, for blind tastings it might be nice if the number took up only half the sticker so that we can write the name of the wine in when revealed.

The glass stickers were also rather hackerish to produce, so some improvement to the code is required.

It would be relative easy to add boolean flags that produce one sticker per glass per person, with some number of extra blank people, and that the Names loop be outermost. This would put all of each person’s stickers on the same page, except those who crossed a page boundary. Extra boolean controls could prohibit crossing page boundaries. But this could still be difficult to cut, as roughly illustrated in the following text diagram, in which the people are A, B, C, etc.

Code: Select all

AAAAA  FFFFF
AAAAA  FFGGG
AABBB  GGGGG
BBBBB  GGGGH
BBBBC  HHHHH
CCCCC  HHHHH
CCCCC  HIIII
CDDDD  IIIII
DDDDD  IIIJJ
DDDEE  JJJJJ
EEEEE  JJJJJ
EEEEE  KKKKK
FFFFF  KKKKK

(If boundary-crossing is prohibited pages would look like the left of these, with the last row empty.)

The cutting would have awkward 90° turns. Better suggestions welcomed.

[Cookie]

My Niepoort 1942 had Woolfgangs' sticker on it but I do not recall this having any adverse effect on the contents of my glass

[jdaw1]

My Niepoort 1942 had Woolfgangs sticker on it but I do not recall this having any adverse effect on the contents of my glass

Would your cool have survived Wolfgang drinking your Ni42? (You’ll be pleased to know that your post made it to Apostrophe crimes.)

Back to the subject. Would it suffice to have a boolean compelling each person’s stickers to start on a new line? That strikes a balance between simplicity of cutting and not wasting too many stickers.

Code: Select all

AAAAA  EEEEE
AAAAA  EE   
AA     FFFFF
BBBBB  FFFFF
BBBBB  FF   
BB     GGGGG
CCCCC  GGGGG
CCCCC  GG   
CC     HHHHH
DDDDD  HHHHH
DDDDD  HH   
DD     IIIII
EEEEE  IIIII

[JacobH]

Back to the subject. Would it suffice to have a boolean compelling each person’s stickers to start on a new line? That strikes a balance between simplicity of cutting and not wasting too many stickers.

Does Postscript have a modulo operand? If so a slight optimisation would be to test to see whether the stickers should be arranged horizontally or vertically by calculating the number of wasted stickers left. For example, consider 4 people (A-D), tasting 5 wines, with a 5 by 4 set of stickers:

Code: Select all

Hoz. Vert.
AAAA ABCD
A... ABCD
BBBB ABCD
B... ABCD
.... ABCD


A further optimisation might be to allow two cuts to be made. That would avoid the problems illustrated in your first example since each of the two cuts could be made in a straight line from the boundary and would improve the fit of (e.g.) an 8-person tasting of 5 wines on a 4 by 10 set of stickers:

Code: Select all

1cut 2cuts
AAAA ACEG
A... ACEG
BBBB ACEG
B... ACEG
CCCC ACEG
C... BDFH
DDDD BDFH
D... BDFH
EEEE BDFH
E... BDFH


I am not sure, however, as to the complexity of solving this packing problem for arbitrary numbers.

[jdaw1]

Does Postscript have a modulo operand?

Yes, mod, though even if it didn’t one could be written as something like /Mod {2 dict begin /n exch def /m exch def {m 0 ge {m n lt {m exit} if /m m n sub def} {/m m n add def} ifelse} loop end} def.

You’re right about it being possible to find tighter fittings, still with complete cuts, but fewer cut or fewer wasted labels. However, my immediate reaction is that the problem of minimising could be a form of Knapsack problem. Also, before veering off to a completely general case, with the parameters actually likely to be used, is this really useful? With the 5×13 labels, and quite a few glasses per person, wastage will not be much worse than lightly sub-optimal. I’m reluctant to rearrange and rewrite code for a more general case that will be encountered rarely, and with little gain to the simple case.

Is that unreasonable?

[JacobH]

You’re right about it being possible to find tighter fittings, still with complete cuts, but fewer cut or fewer wasted labels. However, my immediate reaction is that the problem of minimising could be a form of Knapsack problem. Also, before veering off to a completely general case, with the parameters actually likely to be used, is this really useful? With the 5×13 labels, and quite a few glasses per person, wastage will not be much worse than lightly sub-optimal. I’m reluctant to rearrange and rewrite code for a more general case that will be encountered rarely, and with little gain to the simple case.

I suppose the simplest way of dealing with it is to have one option to choose whether force a line-break after each person's stickers or not, and another to choose whether to arrange the labels horizontally or vertically. That is especially true since the optimisation is perhaps a bit more subtle than I had first thought: the aim is to have the remaining labels in the largest block so they are most likely to be reusable. For example:

Code: Select all

xxx
x..
xxx
x..
xxx
x..
...

is less preferable to:
xxx
xxx
xxx
xxx
...
...
...


However, if we are looking for a simple solution would a test of: "if the modulo of the number of wines compared to the width of the sheet is less or equal to the modulo of the number of participants compared to the height of the sheet, then the labels should be laid-out horizontally, else lay them out vertically", suffice?

[jdaw1]

I was hoping to avoid the extra coding of allowing either order of laying out. But you’re basically right—though the code will directly compute wastage and go from there.

[JacobH]

Not so. The printing is of the PDF, which has been distilled. The calculations for each page have been done. (Average page size: only 4k!)

I understand the theory, but the last time I printed a very large set of placemats, it did take a disproportional amount of time. I think the problem was because of the density of complex vector patterns in the file which are inexpensive in terms of instructions--hence the small file size--but expensive in terms of rendering. I think when the file is unpacked into the printing stream the amount of data exponentially increased to such an extent that it choked the printer (100s of megabytes). Looking around this seems to be a general issue with PDFs (particularly with patterns), although apparently when printed on a printer without postscript support, since those with postscript support can print the vectors in the document natively.

[jdaw1]

I understand the theory, but the last time I printed a very large set of placemats, it did take a disproportional amount of time. I think the problem was because of the density of complex vector patterns in the file which are inexpensive in terms of instructions--hence the small file size--but expensive in terms of rendering. I think when the file is unpacked into the printing stream the amount of data exponentially increased to such an extent that it choked the printer (100s of megabytes). Looking around this seems to be a general issue with PDFs (particularly with patterns), although apparently when printed on a printer without postscript support, since those with postscript support can print the vectors in the document natively.

Perhaps fair—I don’t know. Clipping might be arduous.

What can I do about this? Please suggest a line of attack.

[jdaw1]

Re the 272-page placemats of the Fonseca Guimaraens tasting:

worry not - printing went smoothly (approx 6 - 7 minutes)

That is something like a very acceptable 42ish sheets a minute: no action to be taken.

[jdaw1]

By request of DRT, ∃ additional parameter PrePourCollate, defaulting to true. The placemats for the forthcoming Sandeman tasting show this in action.

[jdaw1]

Drafting placemats for The London Olympiad Vertical showed me how slow is the combination of FillTitles and PlaceNames.

So the old code has been improved, with the addition of a new parameter FillTextPrintQuickerDistillSlower. If this is true the text-filling distillation is now about 1½× faster than before, if false then much much faster. In particular, for the current draft placemats of The London Olympiad Vertical, the old code took 60 minutes; new with true about 40 minutes; new with false an edge more than one minute.

If not using PlaceNames then new with false takes 29 seconds.

[jdaw1]

At the Sandeman vertical on 13 May 2011 two possible improvements were devised.

1. At a vertical we generally arrange things as we write: left-to-right, and then top-bottom, going oldest to youngest. But for decanting and pre-pouring we want to work in the opposite order, youngest to oldest. So it would help to have a boolean parameter, perhaps called PrePourReverseOrder, which reverses the order of the pre-pour sheets. Default value = true.
   
   
2. JacobH suggested an extra sheet to hold Decanting Notes. The left column would name the wines, much like the left column in the vote-recorder sheet. A one inch column would be headed “Times”. The bulk of the space, titled “Notes”, could hold the likes of “cork protruding 1mm” or “light seepage”.

Thoughts?

[DRT]

I like both suggestions.

[jdaw1]

JacobH suggested an extra sheet to hold Decanting Notes. The left column would name the wines, much like the left column in the vote-recorder sheet. A one inch column would be headed “Times”. The bulk of the space, titled “Notes”, could hold the likes of “cork protruding 1mm” or “light seepage”.

Please comment on:

The title has been made grey, and right-aligned, to increase the visual contrast with the vote-recorder sheets. Other than that, it is fairly vanilla.

[JacobH]

JacobH suggested an extra sheet to hold Decanting Notes. The left column would name the wines, much like the left column in the vote-recorder sheet. A one inch column would be headed “Times”. The bulk of the space, titled “Notes”, could hold the likes of “cork protruding 1mm” or “light seepage”.

Please comment on:
http://www.jdawiseman.com/port/20110519 ... gnotes.png
The title has been made grey, and right-aligned, to increase the visual contrast with the vote-recorder sheets. Other than that, it is fairly vanilla.

Looks good to me! Thanks!

[jdaw1]

Consider the draft of the placemats for the matrix tasting, {Dow, Fonseca, Graham, Taylor} × {1963, 1966, 1970, 1977}.

Ports will be labelled α63 β63 γ63 δ63, ε66 ζ66 η66 θ66, ι70 κ70 λ70 μ70, ν77 ξ77 ο77 π77. But at the time of decanting, at which the decanting notes are taken, the wines will be known, not yet blinded, as decanter juggling happens later.

I think that this completely beats my model, and separate decanting-notes pages from separate data will have to be made.

[JacobH]

Consider the draft of placemats for the matrix tasting, {Dow, Fonseca, Graham, Taylor} × {1963, 1966, 1970, 1977}.

Ports will be labelled α63 β63 γ63 δ63, ε66 ζ66 η66 θ66, ι70 κ70 λ70 μ70, ν77 ξ77 ο77 π77. But at the time of decanting, at which the decanting notes are taken, the wines will be known, not yet blinded, as decanter juggling happens later.

I think that this completely beats my model, and separate decanting-notes pages from separate data will have to be made.

For what it’s worth, I note that this isn’t a very common occurrence. I can only think of one previous tasting done like this (the 66v67).

Does PrePourReverseOrder affect the order on Decanting Notes sheet? I think there are arguments that it should.

[jdaw1]

Also, at DRT’s request, some defaults have been changed. These generally bring the unaltered default nearer to our standard medium-sized tasting at which everybody knows everybody.

• No decanter labels;
• No pre-pour sheets;
• No placename sheets;
• icons appearing by default.

[DRT]

Consider the draft of the placemats for the matrix tasting, {Dow, Fonseca, Graham, Taylor} × {1963, 1966, 1970, 1977}.

Ports will be labelled α63 β63 γ63 δ63, ε66 ζ66 η66 θ66, ι70 κ70 λ70 μ70, ν77 ξ77 ο77 π77. But at the time of decanting, at which the decanting notes are taken, the wines will be known, not yet blinded, as decanter juggling happens later.

I think that this completely beats my model, and separate decanting-notes pages from separate data will have to be made.

We will know which wines are in the line-up so you could drive the DecantingNoteSheet from a list of DecantingTitles that default to the values of Titles when absent. For example...

/Titles [
(α63)
(β63)
] def

/DecantingTitles [
(G63)
(T63)
] def

...would put G63 and T63 on the DecantingNoteSheets and the blind names on everything else. The ordering is irrelevant as the Decanting Notes would be matched to the appropriate wine once revealed at the end of the tasting.

The default should be that...

/Titles [
(JDAW)
(DRT)
] def

/DecantingTitles [

] def

Should result in the Titles appearing on the DecantingNoteSheet. This avoids having to enter the same list of names twice.

[DRT]

Another suggestion.

When creating placemats one of the things that takes up time (for me) is searching around previous tasting reviews to confirm everyone's initials. It would be helpful to have a list of names and initials in the header that builds up as new members join us so that whoever is creating the placemats can find this data in the code header rather than having to search for it elsewhere. Some cleverness could be applied to the construction of this list to allow relationships between intials, full name and handedness to be used by the code. For example, entering a recognised set of initials such as JDAW at a Title could make the corresponding Circlearray default to "Julian D. A. Wiseman".

[jdaw1]

/DecantingTitles [ … ] def

This is an interesting idea.

The functionality is already there, but fiddly to access. Start at the placemats for the Sandeman vertical on 13 May 2011: observe that on page 1, on a glasses sheet, there is the title “27”, but that on the tasting-note sheet on page 6 this is “1927”.

Observe also within the placematsfor the Fonseca Guimaraens vertical on 04 April 2011 that both OverlapSubtitlesOnTitles and InlineTitles vary.

So already it can be done.

However, I could easily change, within the code for the decanting-notes pages, every reference to Titles to, say, TitlesDecantingNotes, and add in the parameters the obvious default something like /TitlesDecantingNotes Titles def. There would be several such variants of the Titles, and likewise Subtitles and Circlearrays.

This would make much easier such variations. Good idea.

Perhaps others could comment on whether this is worth the possible user confusion.

[jdaw1]

It would be helpful to have a list of names and initials in the header that builds up as new members join us so that whoever is creating the placemats can find this data in the code header rather than having to search for it elsewhere. Some cleverness could be applied to the construction of this list to allow relationships between intials, full name and handedness to be used by the code. For example, entering a recognised set of initials such as JDAW at a Title could make the corresponding Circlearray default to "Julian D. A. Wiseman".

This tickles me less.

• Do we really want a mini-database of TPFers in my code?
• How should the code detect that what has been supplied is the usual abbreviation for Domaine de la Romanée-Turnbull, rather than something else?
• In the placemats for the g-man welcome on 6 May 2011, some elements of Titles contained the likes of “Jeff”, “Steph”, “Ed”, “Alex”, “Jacob”, “Ray”, “Tom”, and “Wolfgang”. For a blind tasting, you could do likewise.

[DRT]

Good idea.

[DRT]

This tickles me less.