ThePortForum.com

Posted: **13:37 Tue 07 Jun 2011**

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.

There are three obvious positions for a subtitle: above, below, or overlapping. The current parameterisation can access only the last two of these.
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?

Posted: **19:20 Tue 07 Jun 2011**

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.

Posted: **19:38 Tue 07 Jun 2011**

AHB wrote:(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’.

Posted: **20:40 Tue 07 Jun 2011**

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

Posted: **21:39 Tue 07 Jun 2011**

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

I have, but more is definitely needed.

JacobH wrote: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.

JacobH wrote: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.

JacobH wrote:
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?

JacobH wrote: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.

JacobH wrote:
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.

JacobH wrote: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?

JacobH wrote: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.

JacobH wrote: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.

JacobH wrote: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.

JacobH wrote: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.

JacobH wrote: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.

JacobH wrote: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.

JacobH wrote: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.

Posted: **21:42 Tue 07 Jun 2011**

jdaw1 wrote:
JacobH wrote: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.

Posted: **16:05 Wed 08 Jun 2011**

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.

Posted: **16:15 Wed 08 Jun 2011**

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.

Posted: **19:38 Wed 08 Jun 2011**

jdaw1 wrote: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

Posted: **21:12 Sat 11 Jun 2011**

jdaw1 wrote: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.

Posted: **21:19 Sun 12 Jun 2011**

jdaw1 wrote:(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!)

Posted: **12:07 Fri 17 Jun 2011**

jdaw1 wrote:
JacobH wrote:
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?

jdaw1 wrote: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.

jdaw1 wrote: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.

jdaw1 wrote: 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.

JacobH wrote: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.

jdaw1 wrote: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.

jdaw1 wrote: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).

jdaw1 wrote: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?

Posted: **12:14 Fri 17 Jun 2011**

jdaw1 wrote:
DRT wrote:/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.

Posted: **12:45 Fri 17 Jun 2011**

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

JacobH wrote:
jdaw1 wrote:
JacobH wrote:
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 Manual wrote: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.

JacobH wrote: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?

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

Simple: new default is to be 1.

JacobH wrote:! 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.

JacobH wrote: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.

JacobH wrote: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.

Posted: **23:16 Sat 25 Jun 2011**

Done.

Posted: **23:17 Sat 25 Jun 2011**

Well done. It's beautiful.

Posted: **16:07 Sun 26 Jun 2011**

[url=http://www.theportforum.com/viewtopic.php?p=39371#p39371]Here[/url] jdaw1 wrote: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.

Posted: **13:08 Thu 04 Aug 2011**

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?

Posted: **13:47 Thu 04 Aug 2011**

jdaw1 wrote: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.

Posted: **13:57 Thu 04 Aug 2011**

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.

Posted: **14:05 Thu 04 Aug 2011**

jdaw1 wrote: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.

Posted: **14:13 Thu 04 Aug 2011**

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.

Posted: **14:42 Thu 04 Aug 2011**

RAYC wrote: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?

Posted: **15:13 Thu 04 Aug 2011**

jdaw1 wrote: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) ] >>

Posted: **15:19 Thu 04 Aug 2011**

jdaw1 wrote: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.

Posted: **15:29 Thu 04 Aug 2011**

RAYC wrote: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

Posted: **22:41 Sat 06 Aug 2011**

[url=http://www.conandalton.net/]The competent programmer[/url], after reading the above, by email wrote: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:

In a subsequent email he wrote: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.

Posted: **17:05 Tue 09 Aug 2011**

[url=http://www.fortheloveofport.com/ftlopforum/viewtopic.php?p=70203#p70203]On :ftlop:[/url] Eric Menchen wrote: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.

Posted: **17:15 Tue 09 Aug 2011**

jdaw1 wrote:
[url=http://www.fortheloveofport.com/ftlopforum/viewtopic.php?p=70203#p70203]On :ftlop:[/url] Eric Menchen wrote: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.

Posted: **17:49 Tue 09 Aug 2011**

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

Posted: **10:34 Wed 10 Aug 2011**

In the thread entitled [url=http://www.theportforum.com/viewtopic.php?p=44162#p44162]Port from the Nineteen Nineties, Mon 08 August 2011[/url], jdaw1 wrote:
[url=http://www.theportforum.com/viewtopic.php?p=43927#p43927]Here[/url] jdaw1 wrote:
And, slightly kludged, a ‘What is it?’ page. Comment encouraged.
[url=http://www.theportforum.com/viewtopic.php?p=43952#43952]Here[/url] AHB wrote:A way to record guesses for posterity. I'm happy to try this out on 8th August.
[url=http://www.theportforum.com/viewtopic.php?p=43953#43953]Here[/url] jdaw1 wrote: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.

[url=http://www.theportforum.com/viewtopic.php?p=44122#p44122]Here[/url] RAYC wrote: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)
[url=http://www.theportforum.com/viewtopic.php?p=44124#44124]Here[/url] jdaw1 wrote: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.

RAYC wrote:- 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.

Earlier, in the [url=http://www.theportforum.com/viewtopic.php?p=44124#p44124]planning thread for that tasting[/url], jdaw1 wrote: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.

Posted: **10:34 Wed 10 Aug 2011**

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

RAYC wrote:- 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?

RAYC wrote:- 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.

Posted: **16:16 Wed 10 Aug 2011**

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.

Posted: **18:20 Wed 10 Aug 2011**

jdaw1 wrote: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.

Posted: **19:13 Wed 10 Aug 2011**

Glenn E. wrote:
jdaw1 wrote: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.

Posted: **23:24 Wed 10 Aug 2011**

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.

Posted: **23:28 Wed 10 Aug 2011**

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.

Posted: **12:52 Fri 19 Aug 2011**

Vote-recorder total rows, etc: done.

Posted: **23:09 Sun 21 Aug 2011**

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

Posted: **18:14 Sat 24 Sep 2011**

I like the document outline but have just noticed the external links section, which is a splendid addition.

Posted: **16:33 Sun 09 Oct 2011**

[url=http://www.theportforum.com/viewtopic.php?p=45355#p45355]Here[/url] RAYC wrote:Placemats printed.

Hitherto, when placemats have been printed, they have been deemed finished the online edition being frozen at the printed version.

But with the new ExternalLinks feature, there are placemat parameters that don’t affect what prints. There would be advantages in adding to the placemats a link to the review thread, as that thread has, front and prominent, all the links one could want.

Do users object to post-printing changes to the uploaded placemats, provided that the new version would print the same as the printed version?

Please vote one of:

‘Purist’ (the printed version is the final version);
‘Near-Purist’ (later uploads must be of something that would print the same to paper);
Other (detail).

My preference is Near-Purist, but I might be persuaded by interesting argument.

Posted: **16:59 Sun 09 Oct 2011**

I vote Near-Purist, but do wonder what sort of geek would find it necessary to print a set of placemats for a tasting that had already happened.

Posted: **17:03 Sun 09 Oct 2011**

DRT wrote:but do wonder what sort of geek would find it necessary to print a set of placemats for a tasting that had already happened.

That’s not quite the point, I think. The online placemats are part of the record of the tasting. Records are important. (Some might recall that DRT and I are meant to be writing a book based on various records relating to port.)

To what extent can we retrospectively change this ‘record’? My view is slightly, not so much as to change the print, and only very soon after the tasting. It isn’t quite purist, but nearly so.

Posted: **07:14 Mon 10 Oct 2011**

jdaw1 wrote:
DRT wrote:but do wonder what sort of geek would find it necessary to print a set of placemats for a tasting that had already happened.
That’s not quite the point, I think. The online placemats are part of the record of the tasting. Records are important. (Some might recall that DRT and I are meant to be writing a book based on various records relating to port.)

To what extent can we retrospectively change this ‘record’? My view is slightly, not so much as to change the print, and only very soon after the tasting. It isn’t quite purist, but nearly so.

I knew that the answer was "us"

Posted: **08:29 Mon 10 Oct 2011**

I'd vote purist, warts and all as necessary; it's the record of the event, with any notes or additional links provided in the review thread(s), rather than the corrected/updated event arrangements. Once you start adding extra helpful links, you risk incremental feature creep (links to tasting notes, WOTN scores etc); Perhaps that would only be appropriate for circumstances where you require the document to be the master record for the complete event, e.g. non-TPF use where these might be no associated forum etc?

Posted: **12:38 Mon 10 Oct 2011**

Purist+Other:

Purist: If the placemat is a historical document used to understand what happened at a tasting, it is important that it remains unaltered after the event. While one might only be adding links to the review, removing some embarrassing detail on the tasting sheet which caused great discussion would be too tempting. Similarly, if the website upgraded or moved, and the links changed, would we need to keep the placemat updated in perpetuity?

Other: If the placemat is not a historical document, but simply a tool we use to execute the tastings planned and recorded here on the site, then its accuracy and valuable content -- beyond the event -- is irrelevant. Are our placemats being stored and backed up? Are they ever revisited? I'd prefer that, so long as the website exists, the website be the authoritative source on what transpired at the tasting. And should the website cease to exist, the links on placemats would be useless.

Posted: **13:14 Mon 10 Oct 2011**

Don't think I understand the debate here, but:

What if a port emergency is declared at the end of the night and another bottle is added? Or there's a guest who turns up at the last minute with an extra bottle? The placemats as printed are no longer a historical record of events. Including the extra information somewhere at the back (but so that the actual placemats remain" as printed" seems neat.

Posted: **21:01 Mon 10 Oct 2011**

SushiNorth wrote:Are our placemats being stored and backed up?

The British Library archives copies of jdawiseman.com. These copies are derived by following the links from the home page, and the manual links to some but not all placemats. I could add a page listing all the placemats, so that all are archived.

PhilW and SushiNorth make a powerful argument (‟would be too tempting”; ‟incremental feature creep”; etc). Are these arguments lessened by self-restraint on the part of jdaw1? Surely a bit. But are they lessened enough?

So far the score is as follows.
• Purist: 2 (SushiNorth, PhilW);
• Near-Purist: 3 (jdaw1, DRT, RAYC).
My vote was a close call, and RAYC denies understanding, so that is statistically indistinguishable from a draw.

Posted: **22:08 Mon 10 Oct 2011**

jdaw1 wrote:I could add a page listing all the placemats, so that all are archived.

Done. Henceforth the British Library will find all these.

Posted: **22:31 Mon 10 Oct 2011**

jdaw1 wrote:
jdaw1 wrote:I could add a page listing all the placemats, so that all are archived.
Done. Henceforth the British Library will find all these.

Is this list intended to include all TPF Tastings, and if so would it be useful to DL the ones that we've done in NYC for inclusion in that archive?

ThePortForum.com

Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats

Re: Software that makes placemats