Software that makes placemats

[jdaw1]

I understand the theory, but the last time I printed a very large set of placemats, it did take a disproportional amount of time. I think the problem was because of the density of complex vector patterns in the file which are inexpensive in terms of instructions--hence the small file size--but expensive in terms of rendering. I think when the file is unpacked into the printing stream the amount of data exponentially increased to such an extent that it choked the printer (100s of megabytes). Looking around this seems to be a general issue with PDFs (particularly with patterns), although apparently when printed on a printer without postscript support, since those with postscript support can print the vectors in the document natively.

Perhaps fair I don’t know. Clipping might be arduous.

What can I do about this? Please suggest a line of attack.

[jdaw1]

Re the 272-page placemats of the Fonseca Guimaraens tasting:

worry not - printing went smoothly (approx 6 - 7 minutes)

That is something like a very acceptable 42ish sheets a minute: no action to be taken.

[jdaw1]

By request of DRT, ∃ additional parameter PrePourCollate, defaulting to true. The placemats for the forthcoming Sandeman tasting show this in action.

[jdaw1]

Drafting placemats for The London Olympiad Vertical showed me how slow is the combination of FillTitles and PlaceNames.

So the old code has been improved, with the addition of a new parameter FillTextPrintQuickerDistillSlower. If this is true the text-filling distillation is now about 1½× faster than before, if false then much much faster. In particular, for the current draft placemats of The London Olympiad Vertical, the old code took 60 minutes; new with true about 40 minutes; new with false an edge more than one minute.

If not using PlaceNames then new with false takes 29 seconds.

[jdaw1]

At the Sandeman vertical on 13 May 2011 two possible improvements were devised.

1. At a vertical we generally arrange things as we write: left-to-right, and then top-bottom, going oldest to youngest. But for decanting and pre-pouring we want to work in the opposite order, youngest to oldest. So it would help to have a boolean parameter, perhaps called PrePourReverseOrder, which reverses the order of the pre-pour sheets. Default value = true.
2. JacobH suggested an extra sheet to hold Decanting Notes. The left column would name the wines, much like the left column in the vote-recorder sheet. A one inch column would be headed ‟Times”. The bulk of the space, titled ‟Notes”, could hold the likes of ‟cork protruding 1mm” or ‟light seepage”.

Thoughts?

[DRT]

I like both suggestions.

[jdaw1]

JacobH suggested an extra sheet to hold Decanting Notes. The left column would name the wines, much like the left column in the vote-recorder sheet. A one inch column would be headed ‟Times”. The bulk of the space, titled ‟Notes”, could hold the likes of ‟cork protruding 1mm” or ‟light seepage”.

Please comment on:

The title has been made grey, and right-aligned, to increase the visual contrast with the vote-recorder sheets. Other than that, it is fairly vanilla.

[JacobH]

JacobH suggested an extra sheet to hold Decanting Notes. The left column would name the wines, much like the left column in the vote-recorder sheet. A one inch column would be headed ‟Times”. The bulk of the space, titled ‟Notes”, could hold the likes of ‟cork protruding 1mm” or ‟light seepage”.

Please comment on:
http://www.jdawiseman.com/port/20110519 ... gnotes.png
The title has been made grey, and right-aligned, to increase the visual contrast with the vote-recorder sheets. Other than that, it is fairly vanilla.

Looks good to me! Thanks!

[jdaw1]

Consider the draft of the placemats for the matrix tasting, {Dow, Fonseca, Graham, Taylor} × {1963, 1966, 1970, 1977}.

Ports will be labelled α63 β63 γ63 δ63, ε66 ζ66 η66 θ66, ι70 κ70 λ70 μ70, ν77 ξ77 ο77 Ï€77. But at the time of decanting, at which the decanting notes are taken, the wines will be known, not yet blinded, as decanter juggling happens later.

I think that this completely beats my model, and separate decanting-notes pages from separate data will have to be made.

[JacobH]

Consider the draft of placemats for the matrix tasting, {Dow, Fonseca, Graham, Taylor} × {1963, 1966, 1970, 1977}.

Ports will be labelled α63 β63 γ63 δ63, ε66 ζ66 η66 θ66, ι70 κ70 λ70 μ70, ν77 ξ77 ο77 Ï€77. But at the time of decanting, at which the decanting notes are taken, the wines will be known, not yet blinded, as decanter juggling happens later.

I think that this completely beats my model, and separate decanting-notes pages from separate data will have to be made.

For what it’s worth, I note that this isn’t a very common occurrence. I can only think of one previous tasting done like this (the 66v67).

Does PrePourReverseOrder affect the order on Decanting Notes sheet? I think there are arguments that it should.

[jdaw1]

Also, at DRT’s request, some defaults have been changed. These generally bring the unaltered default nearer to our standard medium-sized tasting at which everybody knows everybody.

• No decanter labels;
• No pre-pour sheets;
• No placename sheets;
• icons appearing by default.

[DRT]

Consider the draft of the placemats for the matrix tasting, {Dow, Fonseca, Graham, Taylor} × {1963, 1966, 1970, 1977}.

Ports will be labelled α63 β63 γ63 δ63, ε66 ζ66 η66 θ66, ι70 κ70 λ70 μ70, ν77 ξ77 ο77 Ï€77. But at the time of decanting, at which the decanting notes are taken, the wines will be known, not yet blinded, as decanter juggling happens later.

I think that this completely beats my model, and separate decanting-notes pages from separate data will have to be made.

We will know which wines are in the line-up so you could drive the DecantingNoteSheet from a list of DecantingTitles that default to the values of Titles when absent. For example...

/Titles [
(α63)
(β63)
] def

/DecantingTitles [
(G63)
(T63)
] def

...would put G63 and T63 on the DecantingNoteSheets and the blind names on everything else. The ordering is irrelevant as the Decanting Notes would be matched to the appropriate wine once revealed at the end of the tasting.

The default should be that...

/Titles [
(JDAW)
(DRT)
] def

/DecantingTitles [

] def

Should result in the Titles appearing on the DecantingNoteSheet. This avoids having to enter the same list of names twice.

[DRT]

Another suggestion.

When creating placemats one of the things that takes up time (for me) is searching around previous tasting reviews to confirm everyone's initials. It would be helpful to have a list of names and initials in the header that builds up as new members join us so that whoever is creating the placemats can find this data in the code header rather than having to search for it elsewhere. Some cleverness could be applied to the construction of this list to allow relationships between intials, full name and handedness to be used by the code. For example, entering a recognised set of initials such as JDAW at a Title could make the corresponding Circlearray default to "Julian D. A. Wiseman".

[jdaw1]

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

However, I could easily change, within the code for the decanting-notes pages, every reference to Titles to, say, TitlesDecantingNotes, and add in the parameters the obvious default something like /TitlesDecantingNotes Titles def. There would be several such variants of the Titles, and likewise Subtitles and Circlearrays.

This would make much easier such variations. Good idea.

Perhaps others could comment on whether this is worth the possible user confusion.

[jdaw1]

It would be helpful to have a list of names and initials in the header that builds up as new members join us so that whoever is creating the placemats can find this data in the code header rather than having to search for it elsewhere. Some cleverness could be applied to the construction of this list to allow relationships between intials, full name and handedness to be used by the code. For example, entering a recognised set of initials such as JDAW at a Title could make the corresponding Circlearray default to "Julian D. A. Wiseman".

This tickles me less.

• Do we really want a mini-database of TPFers in my code?
• How should the code detect that what has been supplied is the usual abbreviation for Domaine de la Romanée-Turnbull, rather than something else?
• In the placemats for the g-man welcome on 6 May 2011, some elements of Titles contained the likes of ‟Jeff”, ‟Steph”, ‟Ed”, ‟Alex”, ‟Jacob”, ‟Ray”, ‟Tom”, and ‟Wolfgang”. For a blind tasting, you could do likewise.

[DRT]

Good idea.

[DRT]

This tickles me less.

[jdaw1]

could easily change, within the code for the decanting-notes pages, every reference to Titles to, say, TitlesDecantingNotes, and add in the parameters the obvious default something like /TitlesDecantingNotes Titles def. There would be several such variants of the Titles, and likewise Subtitles and Circlearrays.

Having allowed this to breathe, and thought about it some more, I really like it.

Awaiting comment from JacobH before implementing.

If he approves, the new parameters would be:

• • TitlesTastingNotes;
  • TitlesVoteRecorder;
  • TitlesDecantingNotes;
• • SubtitlesTastingNotes;
  • SubtitlesVoteRecorder;
  • SubtitlesDecantingNotes;
• • CirclearraysTastingNotes;
  • CirclearraysVoteRecorder;
  • CirclearraysDecantingNotes.

Proposed defaults:

Code: Select all

/TitlesTastingNotes Titles def
/TitlesVoteRecorder TitlesTastingNotes def
/TitlesDecantingNotes TitlesTastingNotes def
/SubtitlesTastingNotes Subtitles def
/SubtitlesVoteRecorder SubtitlesTastingNotes def
/SubtitlesDecantingNotes SubtitlesTastingNotes def
/CirclearraysTastingNotes Circlearrays def
/CirclearraysVoteRecorder CirclearraysTastingNotes def
/CirclearraysDecantingNotes CirclearraysTastingNotes def

For technical reasons it would be much more work to make this feature work for pre-pour and sticky-labels sheets.

[jdaw1]

Does PrePourReverseOrder affect the order on Decanting Notes sheet? I think there are arguments that it should.

Those attending such tastings may well have developed intuition about the typical order of a TN sheet. The DN sheets are sufficiently similar that such a rhyme with TN sheets might work better.

I suspect that it is marginal either way, permitting the triumph of laziness.

[JacobH]

This all makes sense to me. Is there a big need to have a TitlesVoteRecorder, since in most blind tastings half the people vote with the anonymous initials and the other half with the actual name of the Port?

What this has made me wonder about is whether there should be a feature to add the text ‟Revealed to be:” to the tasting note sheets and the placemats when blind tasting? This is to remind people to take a note of what they are actually tasting since there have been a few tastings where I have written the revealed name on the placemat but not on my tasting note sheet and therefore wondered which is which when I come to write them up.

[jdaw1]

This all makes sense to me. Is there a big need to have a TitlesVoteRecorder, since in most blind tastings half the people vote with the anonymous initials and the other half with the actual name of the Port?

No, but it makes more sense to an attentive user to do the whole set.

What this has made me wonder about is whether there should be a feature to add the text ‟Revealed to be:” to the tasting note sheets and the placemats when blind tasting?

This is in two halves.

• It is awkward to write on the glasses sheets. Especially if they are A3 holding ≥12 glasses, but even with smaller sheets it takes a narrow steady hand to do that.
• As for the TN sheets, that is a good idea, needing no extra code. TastingNotesColumnHeadings defaults to [ (Times) (Eye) (Nose) (Mouth) (Score) ], but could specify an extra column. For these purposes it would presumably at the end = far-right, headed ‟Unblinded”, ‟Unveil”, ‟St John the Divine”, or, given our usual identification powers, ‟Apocalypse of the Ego”.

[JacobH]

As for the TN sheets, that is a good idea, needing no extra code. TastingNotesColumnHeadings defaults to [ (Times) (Eye) (Nose) (Mouth) (Score) ], but could specify an extra column. For these purposes it would presumably at the end = far-right, headed ‟Unblinded”, ‟Unveil”, ‟St John the Divine”, or, given our usual identification powers, ‟Apocalypse of the Ego”.[/list]

That makes sense. Is there any easy way of adding the text to the voting sheets?

[jdaw1]

Is there any easy way of adding the text to the voting sheets?

Not at the moment. Would it be sufficient to add an extra parameter like VoteRecorderFirstColMinWidth?

[JacobH]

Is there any easy way of adding the text to the voting sheets?

Not at the moment. Would it be sufficient to add an extra parameter like VoteRecorderFirstColMinWidth?

Perhaps, or would that be more hassle then it’s worth, since most Ports can be abbreviated to <5 letters?

[jdaw1]

Code updated to include:

• • TitlesTastingNotes;
  • TitlesVoteRecorder;
  • TitlesDecantingNotes;
• • SubtitlesTastingNotes;
  • SubtitlesVoteRecorder;
  • SubtitlesDecantingNotes;
• • CirclearraysTastingNotes;
  • CirclearraysVoteRecorder;
  • CirclearraysDecantingNotes.

An example of use can be found on page 113 of the current draft of the placemats for the matrix tasting, {Dow, Fonseca, Graham, Taylor} × {1963, 1966, 1970, 1977}.

Changes to manual implemented about 20:55 GMT.

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.

(The next post will be on a new page, so quote that to which you are replying.)

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