Software that makes placemats

[jdaw1]

Another feature is planned, about which readers might have opinions and ideas for improvements.

Too often there is faffing when ordering food, and again when it comes and people can’t remember what they ordered. So turn to the penultimate page of the example PDF output, on which votes for WOTN can be recorded. There is a column for each person, and a row for each wine.

Perhaps something similar could be done with food? One column for each person, one row per possible nosh. Rows could be ‘grouped’, the line between courses being heavier. For tastings at The Crusting Pipe the possibilities could be pre-entered (somebody please email me a picture of the menu); alternatively on the day the food titles could be hand-written in blank cells. The paper would circulate round the table, people entering into appropriate cells the likes of “✓” or “Bleu”. The completed paper could be handed to the waiter†.

Thoughts? Improvements? Indifference? Not worth it?

† I recognise that more interaction with some waitresses might be desired. As always, the paperwork is intended to be an optional aid, not a straitjacket.

[benread]

You have too much time on your hands! You need a job.

It is however an idea that appeals to my nature. A simpler option could simply be a small footer on each persons tasting note sheet to record "starter", "main" and "dessert".

[jdaw1]

Actually, it won’t take that much time to code.

The footer solution works only if people are choosing food several days in advance. It also fails to centralise things: when food arrives people need to look at their own footers, and getting attention is hard. Whereas a separate piece of paper can be held by an alert somebody who can then direct food to people.

[DRT]

I approve of this suggestion - and with the small print.

[Glenn E.]

I have never really found this to be a problem, so will be perfectly happy with whatever concensus is obtained by the masses.

[jdaw1]

Reminder for this week’s tasting at TCP:

(somebody please email me a picture of the menu)

[AHB]

I will try and remember to take a photo of the Crusting Pipe's menu when we are next there.

[jdaw1]

Thank you for volunteering to try to remember.

[AHB]

No, I didn't try and remember to remember and do that.

I said that I would try, and remember, to take a photograph of the menu but got lazy with my commas. For which, of course, I apologise to any I may have offended.

[jdaw1]

A first draft—comments welcomed. (To see unscaled right-click > View Image.)

[DRT]

Truely marvelous. I am most impressed by your choice of desert.

[jdaw1]

If somebody wants to share, we can share. If nobody wants to share, I’ll share with myself: half each.

[DRT]

If somebody wants to share, we can share. If nobody wants to share, I’ll share with myself: half each.

As you witnessed first hand last weekend, the same principle can be applied to "individual" steak and kidney pies.

[jdaw1]

For those not in the know, a vendor local to DRT does fantastic S&K pies, of a size best described as ‘generous’.

[jdaw1]

Done: uploaded.

[DRT]

A trend has been established recently that made me think of a suggested improvement to the software. By "trend" I mean something that has ocurred on at least 5 consecutive occassions.

It would perhaps be useful if all placemets designed for use at the Crusting Pipe would automatically generate a bonus space for the inevitable late addition of a Sandeman 1982?

[jdaw1]

In some multi-page tastings, for each page all the wines have something in common. A typical example is a multi-horizontal, in which wines from several houses are tasted from two or few vintages. As everything on a page has a common feature, perhaps this common feature should be marked, faintly, as in the two-session four-page example

 

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