Software that makes placemats

[Alex Bridgeman]

Moved by jdaw1 from the thread entitled Thursday 17th December - The Christmas Offline.

Edit by jdaw1, by permission of AHB: current draft of the stickies and TN pages.

Please post-script expert sir, please could we have some water boxes to colour in while waiting for our next glass of port? There could be space on the tasting sheets sir.

[jdaw1]

Please post-script expert sir, please could we have some water boxes to colour in while waiting for our next glass of port? There could be space on the tasting sheets sir.

AHB might be very correct.

The tasting-note sheets are for writing on. That is their purpose. The glasses sheets are to be seen. Currently the only writing on the glasses sheets is in the water boxes. That feels like a type error: writing should not be on pages upon which one is mostly not writing.

So I’m in favour of moving the water counts to the TN sheets.

They could appear in a horizontal line, bottom-left, the same size as and just after the icon. Objections? Or, easier for the programmer, the icon could move or disappear.


This would have an extra advantage: in usual circumstances^†, being left-handed would make no difference. That’s a mistake that a placemat maker can no longer make.


† Being left-handed would still matter when there are so few ports, and so little space, that both glasses and TNs are on the same page. That is, when SideBySideGlassesTastingNotes is true.

[flash_uk]

For me, no. Firmly not. The glasses sheets end up firmly established in place and are ever accessible, and so I can always record water consumption. Tasting note pages get rotated around, moved about etc.

Your proposition that glasses sheets are to be seen is false. They are free to be annotated and written on.

[Alex Bridgeman]

I too have a preference that when glasses sheets are produced that it is the glasses sheet which carries the water boxes. For me the glasses sheets are where I will write everything I wish to leave behind and the tasting sheets is where I will record all I wish to retain. I do not wish to retain water.

So my preference - and which must be seen as that expressed by someone who has no idea of how difficult this might be to code - would be for the water glass marks to be on the glasses page when these are produced and the tasting notes sheets otherwise.

[jdaw1]

If the water boxes can go on either, then there will be two sets of parameters, only one of which will be active. I’m trying to lean against the extra complexity for the user (two sets of parameters) and for the programmer (two sets of code). So I would much rather that we choose one of glasses sheets and TN sheets, and live with the consequences of that choice.

My preference has become TN sheets, but I observe that choice has firm opponents.

[Glenn E.]

Glasses sheets. We do not use the TN sheets for our tastings, so if the water boxes are moved we will no longer have use of them.

Most people here have tasting notebooks that we keep all of our notes in, that's why we have no need for tasting note sheets.

[PhilW]

I would prefer glasses sheets over tasting sheets if there will only be a single location, for the reasons expressed by Flash - usually fixed position on table, water boxes clearly visible, which is often not true of the tasting notes, especially when multi-page.

Alex's suggestion of boxes on glasses sheet if available versus on tasting notes if not seems reasonable, though I don't feel overly strongly on the issue.

[jdaw1]

Something has to give, and the weakest argument was mine.

The parameter WaterCounts will be replaced by WaterBoxesGlasses and WaterBoxesTastingNotes (as, separate to the main question, I think ‘Boxes’ better than ‘Counts’). There is currently a parameter WaterCountNumSideTriangle: on TN pages, the number of boxes will be WaterBoxesNumSideTriangle × (1+WaterBoxesNumSideTriangle) ÷ 2.

There are two array parameters WaterCountShowLeft and WaterCountShowRight which I never change from their default values. I’m going to move then in to the code, so that equivalent parameters for TN sheets don’t have to be documented. If WaterBoxesOverrideShowEverySheet is false then the water boxes will be on each session’s first TN sheet.

Objections?

[PhilW]

The parameter WaterCounts will be replaced by WaterBoxesGlasses and WaterBoxesTastingNotes (as, separate to the main question, I think ‘Boxes’ better than ‘Counts’). There is currently a parameter WaterCountNumSideTriangle: on TN pages, the number of boxes will be WaterBoxesNumSideTriangle × (1+WaterBoxesNumSideTriangle) ÷ 2.
...
Objections?

Suggestion rather than objection:
- Unless you wish to allow for the possibility of both, then a single parameter WaterBoxes could be used, set to None, Glasses or TastingNotes.
- A single parameter WaterBoxesNumCols or WaterBoxesRowLenMax (or similar) could be commonly used which would suffice for both, while still clearly defining the length of triangle side for use on glass pages, or single row on tasting notes, OR
- Define a single parameter WaterBoxCount; For tasting note pages, this is a single line; For glasses pages, use rndup(sqrt(2*WaterBoxCount)) to define the long triangle side length (and optionally drop boxes from the top of the triangle if wanted for precise count)

[jdaw1]

- Unless you wish to allow for the possibility of both, then a single parameter WaterBoxes could be used, set to None, Glasses or TastingNotes.

And it could have a value /Both. Consider the case in which the parameter’s value is some code, probably depending on Names NameNum get: which would be easier? •••This is the only outstanding WaterBoxes question: two boolean parameters (WaterBoxesGlasses and WaterBoxesTastingNotes), or one four-valued parameters (WaterBoxes)? My slight preference is for former.•••

- A single parameter WaterBoxesNumCols or WaterBoxesRowLenMax (or similar) could be commonly used which would suffice for both, while still clearly defining the length of triangle side for use on glass pages, or single row on tasting notes,

This suggests a rectangular layout, which isn’t the plan for the glasses page.

- Define a single parameter WaterBoxCount; For tasting note pages, this is a single line; For glasses pages, use rndup(sqrt(2*WaterBoxCount)) to define the long triangle side length (and optionally drop boxes from the top of the triangle if wanted for precise count)

I agree with WaterBoxesNum. But your formula is wrong (test 1, 3, 5, 6, 9, 10). I’ll use ( √(1+8n) - 1 )÷2, rounded up, which, without testing, is WaterBoxesNum 8 mul 1 add sqrt 1.00001 sub 2 div ceiling cvi. (The extra .00001 is meant to fix PostScript’s single precision. In theory it should not introduce an error of its own until the number of water boxes is infeasibly large. Anyway the code fails for other reasons above 65535 boxes.)

[PhilW]

- Unless you wish to allow for the possibility of both, then a single parameter WaterBoxes could be used, set to None, Glasses or TastingNotes.

And it could have a value /Both. Consider the case in which the parameter’s value is some code, probably depending on Names NameNum get: which would be easier? •••This is the only outstanding WaterBoxes question: two boolean parameters (WaterBoxesGlasses and WaterBoxesTastingNotes), or one four-valued parameters (WaterBoxes)? My slight preference is for former.

Minor preference for latter from a nominal best-design perspective, since you could (though I'm not suggesting you should) define it on a per-person basis, and then for each person's sheets set the working values for the each page type. However, global use of the two Boolean values would not worry me either.

- Define a single parameter WaterBoxCount; For tasting note pages, this is a single line; For glasses pages, use rndup(sqrt(2*WaterBoxCount)) to define the long triangle side length (and optionally drop boxes from the top of the triangle if wanted for precise count)

I agree with WaterBoxesNum. But your formula is wrong (test 1, 3, 5, 6, 9, 10). I’ll use ( √(1+8n) - 1 )÷2, rounded up, which, without testing, is WaterBoxesNum 8 mul 1 add sqrt 1.00001 sub 2 div ceiling cvi. (The extra .00001 is meant to fix PostScript’s single precision. In theory it should not introduce an error of its own until the number of water boxes is infeasibly large. Anyway the code fails for other reasons above 65535 boxes.)

My formula was wrong (off the top of my head I had only considered even cases) but the correction is simpler: rounddown(0.5+sqrt(2n)) works for all cases for 1-60 boxes, at least.

[jdaw1]

Your formula works. Why? Is it obvious?

( √(1+8n) - 1 )÷2 works because:

[PhilW]

Your formula works. Why? Is it obvious?

( √(1+8n) - 1 )÷2 works because:

Nice geometric explanation; I reached the same equation by consideration of the triangle of n blocks with side y, so n=y*(y+1)/2; the only positive quadratic root of y²+y=2n is y=(-1+root(1+8n))/2 which is the same as your equation, also then rewritable as: y = sqrt(0.25 + 2n) - 0.5
This is precise, so the exact formula would be y = roundup(sqrt(0.25 + 2n) - 0.5) while y = rounddown(sqrt(2n) + 0.5) is a simplification thereof which while not exact, minimises computation.

[jdaw1]

If there are no glasses sheets, by default the WaterBoxes appear on the TN pages. Should there be WaterBoxes on every TN page, on the first TN page from each session, or some other rule? My preference is the first TN page from each session.

[jdaw1]

Done.

Comment welcomed.

[Alex Bridgeman]

Thank you for doing this, it will help to prevent a future hangover.

And for what it is worth, I also agree that we only need water boxes on the first tasting note sheet.

[PhilW]

Looks good. Just first TN page seems to make sense, though not strongly felt.
Can no fruit-branded device users make complex placemats again yet?

[jdaw1]

Can no fruit-branded device users make complex placemats again yet?

There was a problem with ps2pdf.com, believed circumvented as of the version of a few days ago (Ghostscript bug report). If you suspect that it hasn’t been circumvented then please submit or email details.

[jdaw1]

The placemats for the tasting of Sweet-spot Vintages include small sticky labels:


Detail:


As happens at the Bell Unknown-Shipper tastings, the Circlearrays have been replaced by Names (pedantically, with elements of NamesStickyLabels).

Both the top and bottom rows have been replaced. Should it just be one? Should the top row say “Dow 1966”, and only the bottom row say “MPM”?

I say yes: it will be done unless there is cogent objection.

[flash_uk]

Both the top and bottom rows have been replaced. Should it just be one? Should the top row say “Dow 1966”, and only the bottom row say “MPM”?

I say yes: it will be done unless there is cogent objection.

I agree - top row should say shipper in full, bottom row should say the name. The only potential headache I can see would be with long names on the top row. How would Feuerheerd, Constantino or Gould Campbell get on?

[jdaw1]

I agree - top row should say shipper in full, bottom row should say the name. The only potential headache I can see would be with long names on the top row. How would Feuerheerd, Constantino or Gould Campbell get on?

I haven’t written the code to have the rows different, but using the usual 5×13 small stickies, with most setting at or near default, the code can already make the following.

Which hopefully reassures.

[DRT]

I agree - top row should say shipper in full, bottom row should say the name.

I agree, or +1, whichever is preferred.

[flash_uk]

I agree - top row should say shipper in full, bottom row should say the name. The only potential headache I can see would be with long names on the top row. How would Feuerheerd, Constantino or Gould Campbell get on?

I haven’t written the code to have the rows different, but using the usual 5×13 small stickies, with most setting at or near default, the code can already make the following.

Which hopefully reassures.

Punch it Chewie.

[jdaw1]

Five posts moved to a new thread entitled Punch it Chewie.

[PhilW]

My personal preference would be as per existing detail example (shipper/year abbreviation as main item with person initials above and below), though I have no cogent objection to the planned approach.

Additional note: Although I am less keen, if providing shipper and year in above/below then shipper preceeding year would look better than year preceeding shipper as currently (i.e. "Feuerheed YYYY" rather than "YYYY Feuerheed").