Software that makes placemats

[JacobH]

With regard to the issue of ports with two names (one blinded, one unveiled), a small change has been made. In vote-recorder sheets the names of the ports have been moved from the middle of the row (see, for example, the 16th May Crusting Pipe voting sheet) to the top of the row (see page 10 of the example placemats). That creates a better space in which to write an unveiled name, without further crowding the voting area.

Ah, that’s quite a nice, simple solution to the problem!

[jdaw1]

Food Menus and the Placemat Software

I’m trying to reduce the bloat of the code, the parameters, and of the manual. With that in mind, I observe that we never use the food-menu feature.

Do any readers object to it being deleted?

To be actioned on or soon after Sat 28 May 2011, failing cogent objection being received by then.

Edit: this feature adds about 410 lines of code and parameters, ≈ 4.3% of the total.

[Glenn E.]

I have no objection to deleting this feature.

[DRT]

Nor do I.

[Alex Bridgeman]

Nor me. With the menu of TCP changing regularly at the moment, it is difficult to keep the code up to date.

I vote delete.

[jdaw1]

at the moment

Deletion from the code is intended to be permanent.

If the TCP were to have an unchanging menu, would this feature be used? If yes, a stay of execution becomes appropriate.

[Alex Bridgeman]

at the moment

Deletion from the code is intended to be permanent.

If the TCP were to have an unchanging menu, would this feature be used? If yes, a stay of execution becomes appropriate.

If TCP were to have an unchanging menu then the feature would be much more practical to use and would probably be used.

However, if TCP were to have an unchanging menu then TCP might find other problems arise that would still mean the code was impractical

I maintain my vote to delete.

[Axel P]

Happy with deletion.

Axel

[jdaw1]

I’ll give my reasoning for deletion, in case it affects others’ views.

The placemats are about wines × people. Some are about just wines (Decanting Notes, Pre-Pour, Decanter Labels, sometimes Sticky Labels); some about just the people (Place Names); and the bulk about both (Glasses, Tasting Notes, Vote Recorders, sometimes Sticky Labels).

But the Food-Menu pages contain something fundamentally different, being about foods × people. This doesn’t really fit with the ‘narrative’ of the placemats as a whole, and the new thing is why it so lengthens the parameters all those foods need specifying.

[jdaw1]

Done.

[DRT]

Done.

Good.

[jdaw1]

Abovetitles, Belowtitles, Overtitles
Software tidying, continued!

There is the parameter OverlapSubtitlesOnTitles, which controls whether the Subtitles are below or overlapping the Titles. This seems muddledly incomplete, for two reasons.

1. There are three obvious positions for a subtitle: above, below, or overlapping. The current parameterisation can access only the last two of these.
2. And only one subtitle can be used. For example, imagine a vertical, the Titles being large two-digit years. It is natural to superimpose, delicately, the name of the house (e.g., Dow, Cockburn). But what if a few bottles require extra words such as ‟Cask Sample”, or, the relevant deities willing, ‟Double Magnum”? The natural solution would be to put the shipper name in one subtitle location, and other information in another.

The first of these problems could be fixed by replacing the boolean OverlapSubtitlesOnTitles with SubtitlesPosition, which would have valid values /Above, /Below, or /Over. That would fix the first problem, but not the second.

Alternatively, there could be three sets of subtitles, named Abovetitles, Belowtitles, and Overtitles. That allows multiple ‘subtitles’, in any of the three obvious locations, so fixing both problems. (Obviously using all three would typically be cluttered: don’t do what the next diagram demonstrates.)


However, there would not be room on some of the other sheets (tasting-notes, vote-recorder, decanting-notes) for all three. So the recently-added parameters SubtitlesTastingNotes, SubtitlesVoteRecorder, and SubtitlesDecantingNotes would have to default to subtitles from just one location. For example /SubtitlesTastingNotes Belowtitles def, which would be easy for a user to change.

This is relatively easy to implement, and seems like a natural completion of the OverlapSubtitlesOnTitles parameter first added in July 2006, since when I have had the pleasure of larger and better organised port tastings. But is it too much fuss for the user? Some of that fuss can be hidden, by moving some of the subtitle parameters further down, but, nonetheless, is it too much fuss for the user?

[Alex Bridgeman]

As a recipient of the output of the code - but not a user of the code - I do like the appeal of being able to use all three options of subtitle position and for different things, as suggested (eg. title = 58, subtitles being "Warre" "Late Bottled 1961" and "Magnum"). One of these subtitles could be the subtitle printed on the tasting notes sheet (user choice perhaps?) with the tasting event attendee being presumed sober and responsible enough to write by hand the other two pieces of information if considered relevant to the tasting note.

[jdaw1]

(eg. title = 58, subtitles being "Warre" "Late Bottled 1961" and "Magnum"). One of these subtitles could be the subtitle printed on the tasting notes sheet (user choice perhaps?) with the tasting event attendee being presumed sober and responsible enough to write by hand the other two pieces of information if considered relevant to the tasting note.

Which appears on the TN sheet would indeed be under the control of the maker of the placemat, the default being Below. And the one that should be chosen is whichever distinguishes it from the others: so if there are two W58s, with different bottling dates, the bottling dates should be chosen.

Usually all of the information would appear in the Circlearrays, so the taster would not need to be ‟responsible” enough to record any of the ‘subtitles’.

[JacobH]

Julian, might you give some thought to the ordering of the code at the start of the file? When I make a placemat, I tend to go through the following processes: enter the titles, names and other text; choose a typeface; make decisions as to the decoration; and, finally, worry about which extra sheets are needed. It would therefore be helpful if the parameters were declared in that order.

I might therefore might be tempted to:

• Declare paper / orientation first (I only expect this because it tends to be traditional to do so in similar languages)
• Move /HeaderRightText to the same area as where /HeaderLeftText is declared.
• Put /ThePortForumIcon[...] declarations just under that (and add a comment listing the alternatives to /None and /LowerNonWaterCount
• Then have the font declarations
• Then the decoration declarations
• Then the other declarations (e.g. /GlassesOnSheets, /GlassesOnTastingNotePages, /PageOrderingNonDecanterLabelGlasses, /PageOrderingTastingNotePages, /NameHandedness, Water Counts, Extra Pages &c.) which are changed quite frequently but not all the time.

I might also be tempted to split the decoration declarations between the basic boolean (e.g. /Rays /FillTitles) which could go higher up the file and the more advanced options (e.g. /FillTextAngle, /RaysLinesPerGlass). I would also treat /OverlapSubtitlesOnTitles as a decorative question and put it with those declarations.


Could the /NamesHandedness function default to the Right and have a simple command like /LeftHandedTasters [(ABC) (DEF)] def for those who are left-handed?

A few of the parameters have quite complex defaults. For example,

/VoteRecorderNumCopies Titles length 2 le {0} {{GlassesOnTastingNotePages length dup 2 gt {pop 2} if}} ifelse def
/SideBySideGlassesTastingNotes {Titles length 3 le {GlassesOnSheets length 0 gt GlassesOnTastingNotePages length 0 gt and} {false} ifelse} def

Might there be a way of simplifying them since I am not sure how to modify them and what the result will be? If they are not intended to be modified, perhaps they could be put somewhere else in the file. I also think that the 8 lines from 131, starting /TitlesTastingNotes Titles def are probably quite unlikely to be changed so could go down the file.

In terms of the subtitles, I would be in favour of having the three parameters for the above, on and below options (though called, surely, /Subtitles, /Supertitles and /Surtitles?). I agree with the suggestion of making one of these the default for other pages. Though wonder if it could be defaulted to "/Subtitle, /Supertitle, /Surtitles" so by default you get all three separated by commas? (The code would, of course, have to be a touch more complex to deal with situations where only one or two exist and so fewer commas are required).

[jdaw1]

might you give some thought to the ordering of the code at the start of the file?

I have, but more is definitely needed.

When I make a placemat, I tend to go through the following processes: enter the titles, names and other text; choose a typeface; make decisions as to the decoration; and, finally, worry about which extra sheets are needed. It would therefore be helpful if the parameters were declared in that order.

Our processes differ.

I start with the Circlearrays, because my Titles and Subtitles are often derived from Circlearrays. But I don’t want to have the default parameters start with Circlearrays, as that would make the manual slightly more confusing.

II might therefore might be tempted to:

• Declare paper / orientation first (I only expect this because it tends to be traditional to do so in similar languages)
• Move /HeaderRightText to the same area as where /HeaderLeftText is declared.

But for many, perhaps most, users the PaperType doesn’t need changing. I’m willing to concede HeaderRightText, even though it typically doesn’t need changing.

• Put /ThePortForumIcon[...] declarations just under that (and add a comment listing the alternatives to /None and /LowerNonWaterCount

I don’t think that I have ever used an alternative to /None//LowerNonWaterCount: have you? Often?

Then have the font declarations

Happy to move them up. How can the list of example fonts be improved, and ideally made more compact? Restrict to a few widely-available examples? But that would be less helpful to me and I am a user as well as the programmer. Please advise.

• Then the decoration declarations
• Then the other declarations (e.g. /GlassesOnSheets, /GlassesOnTastingNotePages, /PageOrderingNonDecanterLabelGlasses, /PageOrderingTastingNotePages, /NameHandedness, Water Counts, Extra Pages &c.) which are changed quite frequently but not all the time.

There are competing influences in the ordering of parameters. Important influences include: basics early; frequently-changed early; conceptually related things together; not muddling the manual.

For me, GlassesOnSheets is tightly related to the Titles, so I want it near. If that isn’t so for you, perhaps things can move.

I might also be tempted to split the decoration declarations between the basic boolean (e.g. /Rays /FillTitles) which could go higher up the file and the more advanced options (e.g. /FillTextAngle, /RaysLinesPerGlass).

I have split the decorative options into often changed, and rarely changed. Do you want a three-way split, or a two-way split into boolean and all others?

Could the /NamesHandedness function default to the Right and have a simple command like /LeftHandedTasters [(ABC) (DEF)] def for those who are left-handed?

Please allow me to re-interpret this. You want NamesHandedness replaced with a new parameter LeftHanders. I had considered this. But what if two tasters with the same name are of different handedness? Impossible, you might think. No. Consider /Names [ () () ] def, with /NamesHandedness [ /Right /Left ] def thus becoming plausible.

In the light of this reasoning, what do you think best?
Edit: scrap this reasoning. If each item of LeftHanders sets the handedness of only one item of Names, then duplicates are handled nicely. Your parameterisation will be used.
Edit edit: such a good idea that it has been done: LeftHanders is an array of known lefties. If some elements of Names are duplicated, the user might or might not wish to duplicate elements of LeftHanders.

I would also treat /OverlapSubtitlesOnTitles as a decorative question and put it with those declarations.

Good idea. But, given my post three above, and AHB’s favourable reply two above, perhaps too late.

A few of the parameters have quite complex defaults. For example,

/VoteRecorderNumCopies Titles length 2 le {0} {{GlassesOnTastingNotePages length dup 2 gt {pop 2} if}} ifelse def
/SideBySideGlassesTastingNotes {Titles length 3 le {GlassesOnSheets length 0 gt GlassesOnTastingNotePages length 0 gt and} {false} ifelse} def

Might there be a way of simplifying them since I am not sure how to modify them and what the result will be?

Over time complicated defaults have become split into multiple parameters that separately handle the various cases. E.g., TitleMaxHeightIfSubtitleBelowProportionDecanterLabelSmaller, and PermittedPackingStyles gained the possibility /IrregularLandscape. Likewise, perhaps VoteRecorderNumCopies needs to be split into cases. Or perhaps I have the wrong default behaviour. Please consider further and advise.

If they are not intended to be modified, perhaps they could be put somewhere else in the file.

Fair, but, again, is there an advantage in having them with related conceptually-similar parameters.

I also think that the 8 lines from 131, starting /TitlesTastingNotes Titles def are probably quite unlikely to be changed so could go down the file.

Some of these new parameters, most especially TitlesTastingNotes, have already been used by me.

In terms of the subtitles, I would be in favour of having the three parameters for the above, on and below options (though called, surely, /Subtitles, /Supertitles and /Surtitles?).

Splendid names. Just splendid.

Though wonder if it could be defaulted to "/Subtitle, /Supertitle, /Surtitles" so by default you get all three separated by commas? (The code would, of course, have to be a touch more complex to deal with situations where only one or two exist and so fewer commas are required).

And then code is brought back into some parameters. Hmmm.

Consider a vertical. /TitlesTastingNotes [ (1955) (1963) (1966) (1970) (1977) (1985) (1991) (1994) (1997) (2000) (2003) (2007) (2009) ] def
/Titles [ TitlesTastingNotes {2 2 getinterval} forall ] def
Assume that all of these are from the same Shipper, to which every element of Supertitles is set. But then do we really require Shipper on every TN subtitle? I think that we would want the TN subtitles to be the distinguishing elements of Surtitles/Subtitles/Supertitles, rather than all three of them.

[jdaw1]

In terms of the subtitles, I would be in favour of having the three parameters for the above, on and below options (though called, surely, /Subtitles, /Supertitles and /Surtitles?).

Splendid names. Just splendid.

Do others have an opinion on the relative merits of:

• JDAW’s original suggestion of Abovetitles, Belowtitles, and Overtitles; or
• JGH’s proposed alternative of Surtitles, Subtitles, and Supertitles?

Edit: there is a disadvantage to the SuSuSu naming, rather than AbBeOv. What are we to call the lesser-title thing on the tasting-notes/vote-recorder/decanting-notes pages? Recall that this can be any of the AbBeOv/SuSuSu-titles from the glasses page, or indeed something else. But if it is named Subtitles, and one of the glasses-page things is also Subtitles, a user might think, not unreasonably, that they are more closely related than is the TN subtitles with a glasses page non-sub-title. This risks confusion.

Whereas if the glasses page has Abovetitles, Belowtitles, and Overtitles, then none of these is more closely related than any other to SubtitlesTastingNotes. Hmmm: unless we can think of a better name for SubtitlesTastingNotes et al, I might be changing my mind back to AbBeOv.

[jdaw1]

Jacob: the problem with the organisation of the parameters might be the lack of it. Would it help to divide the parameters into sections? Possible sections might be: • Essentials; • Non-Glasses Pages; • Fonts and Greys; • Page Organisation and Page-Level Features; • Glasses: Decoration Controls; • Obscure and Little-Used Parameters.

At jdawiseman.com/port/20110608_possible_parameters_rearangement.ps is a sketch of a possible arrangement. It doesn’t quite follow your order, as some default values depend on the values of other parameters.

Please comment.

[jdaw1]

Jacob: more advice wanted. There are a slew of parameters controlling various aspects of the subtitles. Most, if not all, of these will need to be split into three for the three new arrays. Are there any exceptions: things for which you strongly belief that the three arrays must be the same?

• SameSizeSubtitlesIfAllOf (also need a parameter to control size-matching between the new arrays);
• SubtitlesFont;
• ColourSchemeSubtitles;
• ShapesInSubtitles, ShapesSubtitlesFill, ShapesSubtitlesStroke;
• CrossHatchingSubtitles, CrossHatchingSubtitlesStrokeCode;
• InlineSubtitles, InlineSubtitlesMaxNumberContours, InlineSubtitlesBlackWidth;
• OutlineTitlesAlsoSubtitles;
• FillSubtitles, FillSubtitlesPrioritiseSmallFileSizeOverPortability;
• VerticalMiddlingSubtitles, VerticalMiddlingIncludeBaselineSubtitles, VerticalMiddlingStringSubtitles.

[SushiNorth]

Jacob: the problem with the organisation of the parameters might be the lack of it. Would it help to divide the parameters into sections? Possible sections might be: • Essentials; • Non-Glasses Pages; • Fonts and Greys; • Page Organisation and Page-Level Features; • Glasses: Decoration Controls; • Obscure and Little-Used Parameters.

At jdawiseman.com/port/20110608_possible_parameters_rearangement.ps is a sketch of a possible arrangement. It doesn’t quite follow your order, as some default values depend on the values of other parameters.

Please comment.

Yes, i think organizing the parameters into sections might help, and perhaps even offering two subsections within each. For example, you might want:
*Global themes
** (in this you might include a standard house, or year. Then one might keep for themselves a template for verticals and a template for horizontals)
* Bottles
** bottle names (with a defined format)
** include decanter tags
** Automatic Generation of circles (with code for automatically deriving sur, sub, super, etc)
** Manual Generation of circles (with a template for manually creating sur, sub, super, etc)
* Attendees
** include information about how many pages
* Location and Date
* Layouts for glasses and tasting sheets

[jdaw1]

There are a slew of parameters controlling various aspects of the subtitles. Most, if not all, of these will need to be split into three for the three new arrays. Are there any exceptions: things for which you strongly belief that the three arrays must be the same?

• SameSizeSubtitlesIfAllOf (also need a parameter to control size-matching between the new arrays);

There are technical complications if there are separate versions of SameSizeSubtitlesIfAllOf. Given how rarely this parameter is changed, even by me, one joint control is being deemed sufficient.

[jdaw1]

(also need a parameter to control size-matching between the new arrays)

It isn’t obvious how best to capture this, there being several obvious possibilities.

• % Ignored if array contains fewer than two of these possibilities.
  /SubtitlesWithinGlassSizeMatching [ /Above /Below /Over ] def
• % Ignored if fewer than two of these are true
  /AbovetitlesWithinGlassSameSize true def
  /BelowtitlesWithinGlassSameSize true def
  /OvertitlesWithinGlassSameSize true def
• % Either font sizes are the same, or they differ by at least this ratio of larger/smaller.
  /WithinGlassMinDifferentRatioAboveBelow 9999 def
  /WithinGlassMinDifferentRatioAboveOver 1.333333 def
  /WithinGlassMinDifferentRatioBelowOver 1.333333 def
  % These example parameters impose Above = Below,
  % and that Over is either the same or >= 4/3 times, or <= 3/4 times.

Preference? (I favour the third of these also see the explanation of a numerical value within SameSizeTitlesIfAllOf.) Better possibilities? (Please!)

[JacobH]

• Put /ThePortForumIcon[...] declarations just under that (and add a comment listing the alternatives to /None and /LowerNonWaterCount

I don’t think that I have ever used an alternative to /None//LowerNonWaterCount: have you? Often?

No, but just because I didn’t know what other options there were! If those are the only two, perhaps change it to a boolean?

How can the list of example fonts be improved, and ideally made more compact? Restrict to a few widely-available examples? But that would be less helpful to me and I am a user as well as the programmer. Please advise.

I think it’s fine as it is. The only thing I note is that I’ve never got that command to produce a list of available fonts working, but that may be my machine.

For me, GlassesOnSheets is tightly related to the Titles, so I want it near. If that isn’t so for you, perhaps things can move.

As a less advanced user, I don’t think I’ve ever changed the defaults on it but if you do all the time then perhaps it should stay near /Titles.

Likewise, perhaps VoteRecorderNumCopies needs to be split into cases. Or perhaps I have the wrong default behaviour. Please consider further and advise.

I think if the definition of a variable is anything more complex than a string or array (e.g. it contains a command or expression) then it is either: a) a definition which is unlikely to be modified in normal use (and so should go down the file); b) a definition which needs to be split up so the user-modifiable part can be reduced to an array or string; or c) an exceptional case where the longer definition can remain but with a comment which explains what it is doing and suggesting some changes which the user may wish to make.

Though wonder if it could be defaulted to "/Subtitle, /Supertitle, /Surtitles" so by default you get all three separated by commas? (The code would, of course, have to be a touch more complex to deal with situations where only one or two exist and so fewer commas are required).

And then code is brought back into some parameters. Hmmm.

Consider a vertical. /TitlesTastingNotes [ (1955) (1963) (1966) (1970) (1977) (1985) (1991) (1994) (1997) (2000) (2003) (2007) (2009) ] def
/Titles [ TitlesTastingNotes {2 2 getinterval} forall ] def
Assume that all of these are from the same Shipper, to which every element of Supertitles is set. But then do we really require Shipper on every TN subtitle? I think that we would want the TN subtitles to be the distinguishing elements of Surtitles/Subtitles/Supertitles, rather than all three of them.[/quote]I suppose it will depend on use. In most normal vertical tastings, we don’t set a /SubTitle to be the shippers’ name, we just use the year. The subtitles are used for additional information (e.g. magnum, sqvp &c.). I assumed that we would continue the practice, setting the extra titles for extra information which would normally be interesting to have on all sheets. I would consider setting the /Supertitle of each wine to the same to be non-standard behaviour, for which the default might need to be modified. However, if that were to be usual practice, I understand why you might feel it undesirable to have that as the default.

Jacob: the problem with the organisation of the parameters might be the lack of it. Would it help to divide the parameters into sections? Possible sections might be: • Essentials; • Non-Glasses Pages; • Fonts and Greys; • Page Organisation and Page-Level Features; • Glasses: Decoration Controls; • Obscure and Little-Used Parameters.

That looks very sensible and a big improvement. I imagine the devil will be in keeping the essentials to being essential, but I am sure you can cope! I would restore the longer comment about the fonts (I’m not sure if you had that in mind) and give some thought to /GlassesOnSheet and /VoteRecorderNumCopies for the reasons discussed above.

Jacob: more advice wanted. There are a slew of parameters controlling various aspects of the subtitles. Most, if not all, of these will need to be split into three for the three new arrays. Are there any exceptions: things for which you strongly belief that the three arrays must be the same?

Hmm...no strong beliefs, but I wonder how often most of these will be set to different values (especially for sub-parameters, as it were, like /ShapesSubtitlesFill).

Preference? (I favour the third of these also see the explanation of a numerical value within SameSizeTitlesIfAllOf.) Better possibilities? (Please!)

Gosh...this is quite technical. What practical impact of the three options do you think there would be? I wonder if the third is unnecessarily over-complex?

[JacobH]

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

Going back to this earlier question. At some tastings, one ‟bottle” is provided via two halves. We may also, at the London Olympiad tasting, have two bottles for each Port tasted. It may therefore make sense for there to be a separate decanting note for each one. Is the most sensible way of achieving this to redefine /DecantingNotesTitles &c. or is there a better way it could be achieved.

[jdaw1]

Thank you for replying. The splitting of sub-titles, and rearrangement of parameters, will happen within a few weeks.

• Put /ThePortForumIcon[...] declarations just under that (and add a comment listing the alternatives to /None and /LowerNonWaterCount

I don’t think that I have ever used an alternative to /None//LowerNonWaterCount: have you? Often?

No, but just because I didn’t know what other options there were! If those are the only two, perhaps change it to a boolean?

All is revealed:

the parameter ThePortForumIconPlacement is set to one of /None, /LowerLeft, /LowerRight, /UpperLeft, /UpperRight, /LowerNonWaterCount, /UpperNonWaterCount or /UpperWaterCount, the last three evaluating to left or right according to the side on which the WaterCounts are placed.

The only thing I note is that I’ve never got that command to produce a list of available fonts working, but that may be my machine.

Can you access the log file? And have you tried distilling www.jdawiseman.com/papers/placemat/fonts_illustrated.ps?

Likewise, perhaps VoteRecorderNumCopies needs to be split into cases. Or perhaps I have the wrong default behaviour.

Simple: new default is to be 1.

! commas ! The subtitles are used for additional information (e.g. magnum, sqvp &c.). I assumed that we would continue the practice, setting the extra titles for extra information which would normally be interesting to have on all sheets.

Understandable, and partly satisfied by having all the information in the Circlearrays. I am wielding by authorial veto here: I don’t like the commas, so the default won’t add commas. The most interesting or distinguishing sub-title can be shown large on the non-glasses sheets; the Circlearrays having all. If experience shows that to be unsatisfactory, say so in this thread and it will be reconsidered.

I wonder if the third is unnecessarily over-complex?

To be aesthetically pleasing, it is important not to have too many type sizes. If ‟this” is in 26pt, and ‟that” in 24pt, and the ‟other” in 21pt, it looks sloppy. But we don’t want to set in the same size ‟Dow” and ‟Quinta Nova de Nossa Senhora do Carmo”: it is sensible to have the former larger than the latter. Controllably resolving the tension between these desiderata has proved challenging, even with only one type of sub-title. (The controls were recently changed.) So the complexity seems necessary. However, the defaults should be sufficiently satisfactory for most users.

It may therefore make sense for there to be a separate decanting note for each one. Is the most sensible way of achieving this to redefine /DecantingNotesTitles &c. or is there a better way it could be achieved.

Changing TitlesDecantingNotes can change the wording, but not the number. However ∃ GlassesClusteredOnDecantingNotes which can do some of the extra work. I will further consider this problem.

[jdaw1]

Done.

[DRT]

Well done. It's beautiful.

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

∃ StickyLabelsByNameWhichReplaceCirclearrays. For an example see the organisation thread for The Bell, 2011.

[jdaw1]

A competent programmer recently looked at the placemat software, and made a suggestion.

Many of the parameters are arrays, which must be of the same length. E.g.:

Code: Select all

/Circlearrays [
	[ (Sandeman) (1970) ]
	[ (Graham) (1970) ]
	[ (Graham) (1963) ]
	[ (Sandeman) (1977) ]
	[ (Graham) (1977) ]
	[ (Graham) (1985) (Single) ]
	[ (Sandeman) (1985) ]
	[ (Graham) (1985) (Magnum) ]
] def

/Titles [
	(S70)
	(G70)
	(G63)
	(S77)
	(G77)
	(G85)
	(S85)
	(G85)
] def

/Belowtitles [
	()
	()
	()
	()
	()
	(Single)
	()
	(Magnum)
] def

The competent programmer observed, rightly, that this doesn’t really fit PostScript’s Programmiersprachegeist. It is also awkward: most of the Belowtitles should be a default (); instead the user is forced to include multiple copies of the desired default.

So he suggested that there be a single array of dictionaries, with defaults outside:

Code: Select all

/Belowtitle () def
/GlassesData [
	<< /Title (S70)   /Circlearray [ (Sandeman) (1970) ] >>
	<< /Title (G70)   /Circlearray [ (Graham) (1970) ] >>
	<< /Title (G63)   /Circlearray [ (Graham) (1963) ] >>
	<< /Title (S77)   /Circlearray [ (Sandeman) (1977) ] >>
	<< /Title (G77)   /Circlearray [ (Graham) (1977) ] >>
	<< /Title (G85)   /Belowtitle (Single)   /Circlearray [ (Graham) (1985) (Single) ] >>
	<< /Title (S85)   /Circlearray [ (Sandeman) (1985) ] >>
	<< /Title (G85)   /Belowtitle (Magnum)   /Circlearray [ (Graham) (1985) (Magnum) ] >>
] def

Upon reflection, in a purist IT sense he is completely correct. But I am concerned that non-programmers, who might already be struggling to use the software, would find this even less intuitive.

Comments?

[RAYC]

A competent programmer recently...suggested that there be a single array of dictionaries, with defaults outside:

Code: Select all

/Belowtitle () def
/GlassesData [
<< /Title (S70) /Circlearray [ (Sandeman) (1970) ] >>
<< /Title (G70) /Circlearray [ (Graham) (1970) ] >>
<< /Title (G63) /Circlearray [ (Graham) (1963) ] >>
<< /Title (S77) /Circlearray [ (Sandeman) (1977) ] >>
<< /Title (G77) /Circlearray [ (Graham) (1977) ] >>
<< /Title (G85) /Belowtitle (Single) /Circlearray [ (Graham) (1985) (Single) ] >>
<< /Title (S85) /Circlearray [ (Sandeman) (1985) ] >>
<< /Title (G85) /Belowtitle (Magnum) /Circlearray [ (Graham) (1985) (Magnum) ] >>
] def

Upon reflection, in a purist IT sense he is completely. But I am concerned that non-programmers, who might already be struggling to use the software, would find this even less intuitive.

Comments?

As a non-programmer, I do quite like the look of this, though the original multi-array presentation is perfectly clear.

However, I would suggest including the /Belowtitle parameter in each line of the array, even if it is on most occasions left as a default (). To me, this would make it easier for amateur user to see how to adapt the code as required, though i appreciate that as a programmer it might be regarded as redundant.

[jdaw1]

Definitions would be needed for Circlearray, Title, Abovetitle, Belowtitle, Overtitle, and FillText. Most will be empty, so using a default would substantially lessen clutter in the parameters.

[RAYC]

Definitions would be needed for Circlearray, Title, Abovetitle, Belowtitle, Overtitle, and FillText. Most will be empty, so using a default would substantially lessen clutter in the parameters.

I don't exactly follow what you mean, but my suggestion is that each line of the array would be set out along the lines of the following:

<< /Title (S70) /Above () /Below () / Over () /Fill () /Circlearray [ (Sandeman) (1970) ] >>

This is then an easy template for a user to adapt as required (though in most instances "/Above" and "/Below" etc. will be left as default ()). I'm sure this is inelegant from a programming perspective if a definition can be used, but it is easier (in my opinion) for a non-programmer to use and understand how to introduce the different parameters into the placemat.

[jdaw1]

I accept your point about the template, but, in a typical placemat, almost all of this would be empty. So the GlassesData would be mostly clutter: it becomes harder to read, to see what will happen, and thereby to find errors.

Maybe the conclusion is to leave it as-is, with separate arrays of strings.

[jdaw1]

I don't exactly follow what you mean

Concise

Code: Select all

/Abovetitle () def
/Belowtitle () def
/Overtitle () def
/FillText () def
/GlassesData [
	<< /Title (S70)   /Circlearray [ (Sandeman) (1970) ] >>
	<< /Title (G70)   /Circlearray [ (Graham) (1970) ] >>
	<< /Title (G63)   /Circlearray [ (Graham) (1963) ] >>
	<< /Title (S77)   /Circlearray [ (Sandeman) (1977) ] >>
	<< /Title (G77)   /Circlearray [ (Graham) (1977) ] >>
	<< /Title (G85)   /Belowtitle (Single)   /Circlearray [ (Graham) (1985) (Single) ] >>
	<< /Title (S85)   /Circlearray [ (Sandeman) (1985) ] >>
	<< /Title (G85)   /Belowtitle (Magnum)   /Circlearray [ (Graham) (1985) (Magnum) ] >>
] def

Verbose

Code: Select all

/GlassesData [
	<< /Title (S70)   /Belowtitle ()   /Circlearray [ (Sandeman) (1970) ]   /Abovetitle ()   /Overtitle ()   /FillText () >>
	<< /Title (G70)   /Belowtitle ()   /Circlearray [ (Graham) (1970) ]   /Abovetitle ()   /Overtitle ()   /FillText () >>
	<< /Title (G63)   /Belowtitle ()   /Circlearray [ (Graham) (1963) ]   /Abovetitle ()   /Overtitle ()   /FillText () >>
	<< /Title (S77)   /Belowtitle ()   /Circlearray [ (Sandeman) (1977) ]   /Abovetitle ()   /Overtitle ()   /FillText () >>
	<< /Title (G77)   /Belowtitle ()   /Circlearray [ (Graham) (1977) ]   /Abovetitle ()   /Overtitle ()   /FillText () >>
	<< /Title (G85)   /Belowtitle (Single)   /Circlearray [ (Graham) (1985) (Single) ]   /Abovetitle ()   /Overtitle ()   /FillText () >>
	<< /Title (S85)   /Belowtitle ()   /Circlearray [ (Sandeman) (1985) ]   /Abovetitle ()   /Overtitle ()   /FillText () >>
	<< /Title (G85)   /Belowtitle (Magnum)   /Circlearray [ (Graham) (1985) (Magnum) ]   /Abovetitle ()   /Overtitle ()   /FillText () >>
] def

One copy of ‟/Abovetitle ()”, or many?

[RAYC]

Concise

Code: Select all

/Abovetitle () def
/Belowtitle () def
/Overtitle () def
/FillText () def
/GlassesData [
	<< /Title (S70)   /Circlearray [ (Sandeman) (1970) ] >>
	<< /Title (G70)   /Circlearray [ (Graham) (1970) ] >>
	<< /Title (G63)   /Circlearray [ (Graham) (1963) ] >>
	<< /Title (S77)   /Circlearray [ (Sandeman) (1977) ] >>
	<< /Title (G77)   /Circlearray [ (Graham) (1977) ] >>
	<< /Title (G85)   /Belowtitle (Single)   /Circlearray [ (Graham) (1985) (Single) ] >>
	<< /Title (S85)   /Circlearray [ (Sandeman) (1985) ] >>
	<< /Title (G85)   /Belowtitle (Magnum)   /Circlearray [ (Graham) (1985) (Magnum) ] >>
] def

No doubt.

But let's say, for arguments sake, i am tasting two bottles of G70 (one magnum bottled by Hedges and Butler and one single bottled by BBR) and a half of Dow 1963 (Oporto-bottled) and want to reflect this in the placemats.

As a non-programmer, I don't know what to do with your template. But with mine, I simply fill it out like a form:

Code: Select all

<< /Title (G70) /Above (Hedges & Butler) /Below (Magnum) / Over () /Fill (G70) /Circlearray [ (Graham) (1970) (Magnum) ] >>
<< /Title (G70) /Above (Berry Brothers) /Below (Single) / Over () /Fill (G70) /Circlearray [ (Graham) (1970) (Single) ] >>
<< /Title (D63) /Above (Oporto) /Below (Half) / Over () /Fill (D63) /Circlearray [ (Dow) (1963) (Half) ] >>

[RAYC]

I accept your point about the template, but, in a typical placemat, almost all of this would be empty. So the GlassesData would be mostly clutter: it becomes harder to read, to see what will happen, and thereby to find errors.

Maybe the conclusion is to leave it as-is, with separate arrays of strings.

Understood - it has worked very well to date and these are niche functions, so no need to change.

[jdaw1]

But let's say, for arguments sake, i am tasting two bottles of G70 (one magnum bottled by Hedges and Butler and one single bottled by BBR) and a half of Dow 1963 (Oporto-bottled) and want to reflect this in the placemats.

As a non-programmer, I don't know what to do with your template.

The following would work:

Code: Select all

/Abovetitle () def
/Belowtitle () def
/Overtitle () def
/FillText () def
/GlassesData [
	<< /Title (G70)  /Belowtitle (Magnum)   /Overtitle (Hedges & Butler)   /Circlearray [ (Graham) (1970) (Magnum) (H&B) ]>>
	<< /Title (G70)   /Overtitle (Berry Bros & Rudd)   /Circlearray [ (Graham) (1970) (Single) (BBR) ] >>
	<< /Title (D63)   /Belowtitle (Half)   /Circlearray [ (Dow) (1963) (Half) ] >>
] def

[jdaw1]

As you said, things might have been different for the code if you had started that way but it's tricky to change now. The same is true for your users. Only a few will be able to judge the merits of one approach over the other; everyone else will prefer what they're used to.

A more recent email makes a good observation:

RAYC has a point, that in a typical user interface, you'd likely show all the fields and ask the user to leave fields blank to get the default values. Whereas in code you want to kill clutter and hide stuff that doesn't need to be visible. In the placemat code, the parameters lines are playing two roles - one as plain old code, another as user interface.

So I guess the ultimate answer hinges on which of those two roles is more important for the lines in question.

[jdaw1]

I like the concise version, as long as there is a comment line above telling me all the options. Disclaimer: I write code for a living.

[Glenn E.]

I like the concise version, as long as there is a comment line above telling me all the options. Disclaimer: I write code for a living.

+1, emphasis mine

Disclaimer: I no longer write code for a living, but I used to.

When programming, leave function to the code and user interface to the comments.

[jdaw1]

If this change is done, all options would be plainly visible, but not necessarily in a comment line. Does that suffice?

[jdaw1]

• And, slightly kludged, a ‘What is it?’ page. Comment encouraged.

A way to record guesses for posterity. I'm happy to try this out on 8th August.

Please scan and upload the sheet it’s OK, you will all be rubbish, as would I if I were there and comment on the technology.

Should the "total" field in the guess recorder be a column corresponding to the wines (as currently drafted) or a row at the bottom to correspond to the drinkers? (or perhaps both, giving two totals - best guesser, most guessed)

Updated draft of the placemats.

• Kludged improvement to ‟What is it?” sheet. Comment on this would be welcomed.

What is written in the rectangles is the names of wines, abbreviated. So totalling these will be more arduous than totalling numerical scores (3 for first place; 2 for second; 1 third). Further design work probably needed.

Comment encouraged.

- Guesses are an interesting record of people's impressions of the port (see comment re: Roeda above)

- A slight concern from some that the process of gathering votes after every round got in the way of relaxed conversation. Though i would imagine that this would be less of an issue at a smaller tasting with fewer bottles.

- We are all terrible - top score was 6 points out of a possible 28 (1 point for vintage, 1 for shipper). Across all 8 people, there was only one correct guess at shipper. Scores for correct identification of vintage were no doubt flattered by the fact that we only had a choice of 10 years (or 9, discounting 1993)!

- The sheet worked well, and totalling points was not an arduous task. I had slight difficulty when drunk with recording votes in the correct columns...though this is not a criticism of the sheet itself!

- Inclusion of an extra row or two for extra ports would be good.

Note to self: there could be array parameters VoteRecorderRowTotalTitles and VoteRecorderColTotalTitles. The numbers of total rows and columns would be the length of these arrays, titled with their contents. Of course, the arrays themselves could depend on VoteRecorderSheetNum, so compelling a row in the ‘What is it?’ page but not in the ‘WOTN’ page. But that forces users doing an obvious thing to write code, which isn’t nice. Maybe these could be double-depth arrays, the outer array being of the same length as GlassesClusteredOnVoteRecorders. More complicated, but spares the ordinary user from code.

Later note to self: it’s complicated because there is too much flexibility only one total column or row is needed, so no need for the extra arrays depths that allow multiple. Instead have a non-array single piece of text, VoteRecorderTotalRowTitle and VoteRecorderTotalColTitle, both probably being (Total). Then have two arrays of booleans, of the same length as GlassesClusteredOnVoteRecorders, called VoteRecorderShowTotalRow and VoteRecorderShowTotalCol. That better captures what I actually want to do, with less needless excess.

[jdaw1]

Thank you for the comment. Code will be altered, hopefully not at lot, such that this can be a non-kludge.

- The sheet worked well, and totalling points was not an arduous task. I had slight difficulty when drunk with recording votes in the correct columns...though this is not a criticism of the sheet itself!

It wasn’t meant that way, but it is a criticism. A good user interface, which applies as much to paper as to electronic media, can be used by a drunk. Please ponder how it could be bettered. For instance, would it have helped if every fourth vertical line were thicker? Would it be worth repeating the names at the bottom of the page?

- Inclusion of an extra row or two for extra ports would be good.

That’s mildly inconvenient to do with GlassesClusteredOnVoteRecorders, but an extra integer parameter can be added.

[RAYC]

In addition to the Ryman labels, I can confirm that WH Smith's Large Self Adhesive Labels also work. Indeed, any labels expressed to be "L7165" should work - it appears to be a market standard template (at least in the UK). This may be old news to some - i have not trawled the whole thread.

I would add that 260gsm business cards are also available - if possible to programme, this strikes me as a much better alternative to scissors and glue. I would be happy to acquire and post a batch for testing.

[Glenn E.]

If this change is done, all options would be plainly visible, but not necessarily in a comment line. Does that suffice?

To me, no. As has already been pointed out, in this case the software is the user interface.

If no comment exists the natural assumption is that the code is self-explanatory. Most of this code is in fact self-explanatory, which gives the comments greater weight. If a comment is needed it must be important.

If a comment exists the natural assumption, therefore, is that it explains everything that you need to know. If the comment is read and then something not explained in the comment is discovered in the code, one wonders which is incorrect.

[jdaw1]

If this change is done, all options would be plainly visible, but not necessarily in a comment line. Does that suffice?

To me, no.

Noted. Thank you.

[DRT]

I have read all of the above with interest, but note that most of the comment comes from people who fundamentally understand how to write/read code. RAYC and I seem to be the only "users" who really are "users".

I have debated the prospect of having a proper user interface on this application many times with its creator. I have so far met with resistance. I think this conversation lends weight to my side of that debate in that I think it would be extremely useful, and would increase the number of people who could use the software, if it had a form/wizard on the front end that allowed non-code-savy users to set the parameters. There would be no need to include all of the infrequently used parameters as those could be accessed by an expert user who can edit the code. But it would be good to be able to launch a form, type in the names of a few ports and people and then hit a print button.

[jdaw1]

Writing a good wizard would be a lot of work. Writing a bad wizard would be pointless.

I am happy to co-operate with any who volunteer to write a wizard.

[jdaw1]

Vote-recorder total rows, etc: done.

[jdaw1]

To aid navigation, a document outline has been added (mark ! /OUT pdfmark). There are no parameters it should be automatically visible when opening a placemat of more than nine pages. E.g., 15 December 2011, The Unknown Shipper at the Bell and 11 October 2011, {Dow, Fonseca, Graham, Taylor} × {1963, 1966, 1970, 1977}.