Software that makes placemats

[jdaw1]

Placemats updated here.

Updated here and emailed to you as .ps file.

Observe that PhilW has used different URLs for the two versions, ‘a’ and ‘b’.

I have tended to have one name for my placemat files, repeatedly overwritten as updated. You have done versioning. Hmm, a question for elsewhere, but do people need versioning?

Thoughts?

Edit:

Habitual due to software releases etc, where source is under version control, but releases (and release candidates) get revision numbers. Not expected to be part of the postscript.

[PhilW]

Two suggestions for additional features:

1. Water box formatting
Currently the designer can specify the desired number of water tick boxes, but cannot control the number of bozes per row. In some layouts it would be more aesthetically pleasing to have a 'clump' of boxes rather than a long single line, even if they would fit. Two suggested 'simple' options:
(a) Add a parameter to control the maximum boxes per line, e.g.
/WaterCountTarget 10 def % already provided
/WaterCountRowMax 6 def
(b) Add an optional array parameter to specify the number of bozes per line, e.g.
/WaterCountTarget 10 def % already provided
/WaterCountRows [4 3 2 1] def

2. Packing style selection
Currently the code allows the designer to specify a preferred ordered list of packing styles; User-specified layout can also be used. An additional feature which could be useful in some situations would be the ability to specify on a per-page basis, which of
the list should be used (rather than the program automatically determining this). An example would be a two-page user-specified layout where the style on each page is to be different, e.g.
/PermittedPackingStyles [
[ [2 5] [0 4] [4 4] [2 3] ] % desired layout for glasses page 1
[ [1 1] [0 2] [4 2] [2 1] ] % desired layout for glasses page 2
] def
/EnforcePackingStyles [ 1 2 ] def

n.b. for consistency with other naming, the above variables might perhaps be better renamed as /PackingStylesPermitted and /PackingStylesEnforce

[jdaw1]

Water box formatting
Currently the designer can specify the desired number of water tick boxes, but cannot control the number of bozes per row. In some layouts it would be more aesthetically pleasing to have a 'clump' of boxes rather than a long single line, even if they would fit. Two suggested 'simple' options:
(a) Add a parameter to control the maximum boxes per line, e.g.
/WaterCountTarget 10 def % already provided
/WaterCountRowMax 6 def
(b) Add an optional array parameter to specify the number of bozes per line, e.g.
/WaterCountTarget 10 def % already provided
/WaterCountRows [4 3 2 1] def

Form (b) has two awkwardnesses. First, what if the requested length overlaps a circle. Second, the array needs to be of huge length to cope with all cases. I could avoid this by renaming to /WaterCountMaxRowLengths, with the last item applying to all subsequent rows. Would that be OK? Would this second form be materially more useful than a single integer WaterCountMaxRowLength?

[jdaw1]

Packing style selection
Currently the code allows the designer to specify a preferred ordered list of packing styles; User-specified layout can also be used. An additional feature which could be useful in some situations would be the ability to specify on a per-page basis, which of
the list should be used (rather than the program automatically determining this). An example would be a two-page user-specified layout where the style on each page is to be different, e.g.
/PermittedPackingStyles [
[ [2 5] [0 4] [4 4] [2 3] ] % desired layout for glasses page 1
[ [1 1] [0 2] [4 2] [2 1] ] % desired layout for glasses page 2
] def
/EnforcePackingStyles [ 1 2 ] def

n.b. for consistency with other naming, the above variables might perhaps be better renamed as /PackingStylesPermitted and /PackingStylesEnforce

What about something like

Code: Select all

/PermittedPackingStyles [ {SheetNum 0 eq {/This} {/None} ifelse} ! ]

or even

Code: Select all

/PermittedPackingStyles [ {[/This /That /None] SheetNum get} ! ] def

(where This and That are to be replaced with something else)? (Neither of which need any change to the code.)

[PhilW]

I could avoid this by renaming to /WaterCountMaxRowLengths, with the last item applying to all subsequent rows. Would that be OK? Would this second form be materially more useful than a single integer WaterCountMaxRowLength?

Yes, that sounds good and second form more useful imo.

What about something like

Code: Select all

/PermittedPackingStyles [ {SheetNum 0 eq {/This} {/None} ifelse} ! ]

Would be fine, so can ignore this one; I tried something similar which was rejected by the parser so thought that might not be allowed for some semantic reason I was missing, but the semantic error was user-based

[jdaw1]

I could avoid this by renaming to /WaterCountMaxRowLengths, with the last item applying to all subsequent rows. Would that be OK? Would this second form be materially more useful than a single integer WaterCountMaxRowLength?

Yes, that sounds good and second form more useful imo.

+WaterCountMaxRowLengths done.

Easiest way to update your code would be to search for ‟WaterCountMaxRowLengths”, and splice in that line. Then search in the new code for ‟%%%”, copy from there down, and paste into same place in yours. If being pedantic also substitute line 6.

[jdaw1]

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

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.

Done.

[DRT]

On my last trip to Porto and the Douro I purchased a notebook that I intend to use for future trips. I know of others who take the same notebook time after time to use as an immediate source of reference at tastings.

Perhaps it would be good to have the option of a Tasting Summary Sticker that included:

Tasting Name:
Date:
Location:
Attendees:
Wines:

These stickers could then be placed into notebooks in which tasting notes are to be written.

Yes, I know. It's just laziness not to write all of those things directly into the notebook. But not everything produced by the placemats programme is essential, so these would simply be for convenience of those who need them.

Default should be /TastingSummaryStickers = False

[jdaw1]

My immediate reaction is not enthusiastic.

Tasting Name:
Date:
Location:
Attendees:
Wines:

Much of this information isn’t available. Yes, there are headers defined, into which we typically put some of this, but not in a structured way. ‟Tasting Name”, ‟Date”, and ‟Location” will need extra parameters unless reproducing headers is sure to be satisfactory. Attendees are known to the code; as are the ‟Wines” (with the information spread around Circlearrays, Titles, Belowtitles, Abovetitles, and Overtitles). So it seems that this request doesn’t fit the mojo of the rest of the code.

But if others are enthusiastic I’ll reconsider.

[DRT]

it seems that this request doesn’t fit the mojo of the rest of the code.

I am unlikely to lose sleep as a result of this suggestion being rejected

[jdaw1]

In implementing WaterCountMaxRowLengths I forgot to re-include the parameters that control which pages hold water boxes. PhilW remarked on this bug at the Warre versus Fonseca vertical, and in the PM quoted here. It has been remedied, and is regretted.

[jdaw1]

• Layout was enforced since with minor margin change the default layout was sometimes varying from that intended (rows of 1-2-1-2-1 wanted, default varied between this and 2-2-1-2).

Code: Select all

% /PseudoHexagonal trivia: fix the number of glasses at eight, and vary the page's usable Height/Width ratio. At which ratios does the number of rows change?
% 2 -> 3    0.44444444      4 9 div                                                = 4/9
% 3 -> 4    0.68572971      7 sqrt 1 sub 5 mul 12 div                              = (Sqrt(7)-1) * 5/12
% 4 -> 3    0.70562062      35 sqrt 15 sqrt add 2 mul 21 sqrt sub 3 sub 17 div     = ( (Sqrt(35)+Sqrt(15))*2 - Sqrt(21) - 3 ) / 17
% 3 -> 5    1               1                                                      = 1
% 5 -> 4    1.41719214      35 sqrt 15 sqrt sub 2 mul 3 sub 21 sqrt add 4 div      = ( (Sqrt(35)-Sqrt(15))*2 - 3 + Sqrt(21) ) / 4
% 4 -> 5    1.45830052      7 sqrt 1 add 2 mul 5 div                               = (Sqrt(7)+1) * 2/5
% 5 -> 8    2.25            9 4 div                                                = 9/4

Excepting unity these are in pairs of rationalised reciprocals.

So PermittedPackingStyles being [ /PseudoHexagonal ] causes the less elegant four-row arrangement to happen with a height÷width ratio in the narrow range between ½âˆš35 + ¼√21 ”“ ½âˆš15 ”“ ¾ ≈ 1.4172, and â…–(1+√7) ≈ 1.4583.

[RAYC]

http://vintuswines.com/blog/2012/09/ An intersting approach to placemants by Noval - i like!

[jdaw1]

http://vintuswines.com/blog/2012/09/ An intersting approach to placemants by Noval - i like!

I like too.

[Alex Bridgeman]

http://vintuswines.com/blog/2012/09/ An intersting approach to placemants by Noval - i like!

Round glass bases on a rectangularly divided tasting mat - where the divisions are too small to hold the base of the glass? Hmmm. Not as much to my taste as the current tasting mats we use.

[jdaw1]

People liked the circle watermarks on the TN sheets. The code has just been changed such that these default to being present.

[jdaw1]

+CircletextsSameFontSizeIfRadiiShrunkToBeSame. The need for a feature like this had been on the placemat software’s to-do list since 2007.

[jdaw1]

Is The Bung Hole a confirmed venue or simply the default parameter now in the placemat software?!

It is the default of the placemat software’s main user but not of the software itself.

Though it’s not a bad idea. Why not write ‟The Bung Hole” rather than ‟London”?

Appropriate values also added to the default of ExternalLinks.

[jdaw1]

Very rarely one might want the centre heading non-centred (e.g.). This can be controlled with HeaderFooterCenterRelativeX, which is the centre of the HeaderCenterText, 0 being at the left margin, 1 being at the right, and 0.5 in the centre.

Also see the organisation thread for the tasting of a smattering of Graham.

[jdaw1]

The following quotations come from the parameters for the Smattering of Graham and Malvedos tasting.

Code: Select all

/HeaderFooterCenterRelativeX {TypeOfPagesBeingRendered /Glasses eq {GlassPositions SheetNum get 6 get 0 get MgnL sub PageWidth MgnL MgnR add sub div} {0.5} ifelse} def

Also the position of centre header needed to be changed, for which the code had been altered to add the parameter HeaderFooterCenterRelativeX. This was then assigned to some 132 characters of code, the complication of which might suggest that the form of this parameter was not optimally chosen.

The default value for HeaderFooterCenterRelativeX is plain ‟0.5”, as simple as can be. But the first time this parameter was used the value had to be changed to something computed from something deep in an array. Is that acceptable? Is this a question for the Taylor 1977 committee?

[DRT]

Would it be possible to print the left have portion of GM76 and G91 on the left hand sheet so that when the sheets are overlapped there is continuity in the spacing of the circles?

[jdaw1]

Would it be possible to print the left have portion of GM76 and G91 on the left hand sheet so that when the sheets are overlapped there is continuity in the spacing of the circles?

I thought about that, and it seems to me that would require a major reworking of the software.

What might perhaps be possible would be to print it to a custom paper size (about twice A3), and have a post-process to cut the print job into pieces.

But even if that could be done, in practice would the paper be positioned sufficiently accurately? And stay so positioned? Methinks not. And a similar question could be asked again with the answer presumed to be negative about the accuracy of the trimming of the margin area on which a printer won’t print.

[PhilW]

Would it be possible to print the left have portion of GM76 and G91 on the left hand sheet so that when the sheets are overlapped there is continuity in the spacing of the circles?

I thought about that, and it seems to me that would require a major reworking of the software.

What might perhaps be possible would be to print it to a custom paper size (about twice A3), and have a post-process to cut the print job into pieces.

But even if that could be done, in practice would the paper be positioned sufficiently accurately? And stay so positioned? Methinks not. And a similar question could be asked again with the answer presumed to be negative about the accuracy of the trimming of the margin area on which a printer won’t print.

Alternatively, just using A3, you could print the left-hand sheet as is, and print a right-hand sheet which included the right-hand 5 columns (i.e. from 75/90 inclusive). Then, any vertical slice on the right-hand sheet through 63/83 would create a page which would overlap directly onto the left page to provide the continuous image, without onerous precision on the cutting.

[jdaw1]

Alternatively, just using A3, you could print the left-hand sheet as is, and print a right-hand sheet which included the right-hand 5 columns (i.e. from 75/90 inclusive). Then, any vertical slice on the right-hand sheet through 63/83 would create a page which would overlap directly onto the left page to provide the continuous image, without onerous precision on the cutting.

That was completely obvious, but not quite so completely obvious that I thought of it. An excellent solution to the cutting problem. (Even if not quite to the precision-positioning problem.)

And the only change in the code needed, though not even needed in this case, would be in the internal variable TitleAboveBelowOverRandomSeeds, which would need to change such that the same item of Circlearrays/Titles/Belowtitles/etc in multiple locations would have the same ‘random’ positions of stars of flowers. Easily done. (Edit: done.)

[jdaw1]

There is the side-effect that it causes there to be two pre-pour sheets for the overlapping circles. The obvious and easy solution would be to have an extra boolean parameter, PrePourRemoveDuplicatesAndSortByWithinTitles (having the obvious interaction with PrePourReverseOrder), and StickyLabelsRemoveDuplicatesAndSortByWithinTitles.