ThePortForum.com

Posted: **10:12 Sun 19 Dec 2010**

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.

The following quotations all come from the review thread.

jdaw1 wrote:
Paperwork (tasting-note sheets, and several sets of stickers).

jdaw1 wrote:This was the first placemat-free tasting, with glasses being identified with stickers. Feedback welcomed.

uncle tom wrote:Stickers for glasses works really well, except that we need one sheet of stickers person (or per two people) as we were constantly passing the sheets around and trying to find our respective labels - at one point [somebody] put one of his on his forehead so he could find it later!

jdaw1 wrote:Problems:
At the time the PDF is made, it isn’t yet known who will be sitting next to whom.
One sheet has 65 stickers, so one sheet per person would waste two-thirds to three-quarters of each sheet.

WS1 wrote:Indeed one sheet per person would be too much waste; but would it be possible to slot the stickers of two or three people on equal sections onto one sheet (each person has ~20 stickers)? They could be after printing cut into the portions of the individual person.

JacobH wrote:The stickers also worked extremely well; thanks Julian. As Wolfgang suggested, the only improvement would be to have each person’s stickers as a block so they could be cut up and distributed before the tasting starts. Also, for blind tastings it might be nice if the number took up only half the sticker so that we can write the name of the wine in when revealed.

The glass stickers were also rather hackerish to produce, so some improvement to the code is required.

It would be relative easy to add boolean flags that produce one sticker per glass per person, with some number of extra blank people, and that the Names loop be outermost. This would put all of each person’s stickers on the same page, except those who crossed a page boundary. Extra boolean controls could prohibit crossing page boundaries. But this could still be difficult to cut, as roughly illustrated in the following text diagram, in which the people are A, B, C, etc.

Code: Select all

AAAAA  FFFFF
AAAAA  FFGGG
AABBB  GGGGG
BBBBB  GGGGH
BBBBC  HHHHH
CCCCC  HHHHH
CCCCC  HIIII
CDDDD  IIIII
DDDDD  IIIJJ
DDDEE  JJJJJ
EEEEE  JJJJJ
EEEEE  KKKKK
FFFFF  KKKKK

(If boundary-crossing is prohibited pages would look like the left of these, with the last row empty.)

The cutting would have awkward 90Â° turns. Better suggestions welcomed.

Posted: **10:21 Sun 19 Dec 2010**

My Niepoort 1942 had Woolfgangs' sticker on it but I do not recall this having any adverse effect on the contents of my glass

Posted: **11:29 Sun 19 Dec 2010**

Cookie wrote:My Niepoort 1942 had Woolfgangs sticker on it but I do not recall this having any adverse effect on the contents of my glass

Would your cool have survived Wolfgang drinking your Ni42? (You’ll be pleased to know that your post made it to Apostrophe crimes.)

Back to the subject. Would it suffice to have a boolean compelling each person’s stickers to start on a new line? That strikes a balance between simplicity of cutting and not wasting too many stickers.

Code: Select all

AAAAA  EEEEE
AAAAA  EE   
AA     FFFFF
BBBBB  FFFFF
BBBBB  FF   
BB     GGGGG
CCCCC  GGGGG
CCCCC  GG   
CC     HHHHH
DDDDD  HHHHH
DDDDD  HH   
DD     IIIII
EEEEE  IIIII

Posted: **12:39 Mon 20 Dec 2010**

jdaw1 wrote:Back to the subject. Would it suffice to have a boolean compelling each person’s stickers to start on a new line? That strikes a balance between simplicity of cutting and not wasting too many stickers.

Does Postscript have a modulo operand? If so a slight optimisation would be to test to see whether the stickers should be arranged horizontally or vertically by calculating the number of wasted stickers left. For example, consider 4 people (A-D), tasting 5 wines, with a 5 by 4 set of stickers:

Code: Select all

Hoz. Vert.
AAAA ABCD
A... ABCD
BBBB ABCD
B... ABCD
.... ABCD

A further optimisation might be to allow two cuts to be made. That would avoid the problems illustrated in your first example since each of the two cuts could be made in a straight line from the boundary and would improve the fit of (e.g.) an 8-person tasting of 5 wines on a 4 by 10 set of stickers:

Code: Select all

1cut 2cuts
AAAA ACEG
A... ACEG
BBBB ACEG
B... ACEG
CCCC ACEG
C... BDFH
DDDD BDFH
D... BDFH
EEEE BDFH
E... BDFH

I am not sure, however, as to the complexity of solving this packing problem for arbitrary numbers.

Posted: **14:20 Mon 20 Dec 2010**

JacobH wrote:Does Postscript have a modulo operand?

Yes, mod, though even if it didn’t one could be written as something like /Mod {2 dict begin /n exch def /m exch def {m 0 ge {m n lt {m exit} if /m m n sub def} {/m m n add def} ifelse} loop end} def.

You’re right about it being possible to find tighter fittings, still with complete cuts, but fewer cut or fewer wasted labels. However, my immediate reaction is that the problem of minimising could be a form of Knapsack problem. Also, before veering off to a completely general case, with the parameters actually likely to be used, is this really useful? With the 5×13 labels, and quite a few glasses per person, wastage will not be much worse than lightly sub-optimal. I’m reluctant to rearrange and rewrite code for a more general case that will be encountered rarely, and with little gain to the simple case.

Is that unreasonable?

Posted: **16:39 Mon 20 Dec 2010**

jdaw1 wrote:You’re right about it being possible to find tighter fittings, still with complete cuts, but fewer cut or fewer wasted labels. However, my immediate reaction is that the problem of minimising could be a form of Knapsack problem. Also, before veering off to a completely general case, with the parameters actually likely to be used, is this really useful? With the 5×13 labels, and quite a few glasses per person, wastage will not be much worse than lightly sub-optimal. I’m reluctant to rearrange and rewrite code for a more general case that will be encountered rarely, and with little gain to the simple case.

I suppose the simplest way of dealing with it is to have one option to choose whether force a line-break after each person's stickers or not, and another to choose whether to arrange the labels horizontally or vertically. That is especially true since the optimisation is perhaps a bit more subtle than I had first thought: the aim is to have the remaining labels in the largest block so they are most likely to be reusable. For example:

Code: Select all

xxx
x..
xxx
x..
xxx
x..
...

is less preferable to:
xxx
xxx
xxx
xxx
...
...
...

However, if we are looking for a simple solution would a test of: "if the modulo of the number of wines compared to the width of the sheet is less or equal to the modulo of the number of participants compared to the height of the sheet, then the labels should be laid-out horizontally, else lay them out vertically", suffice?

Posted: **17:22 Mon 20 Dec 2010**

I was hoping to avoid the extra coding of allowing either order of laying out. But you’re basically right though the code will directly compute wastage and go from there.

Posted: **22:30 Sat 02 Apr 2011**

jdaw1, in ‟[url=http://theportforum.com/viewtopic.php?f=3&t=4447&st=0&sk=t&sd=a&start=125#p41767]A birthday tasting 2011 - 4th April 2011[/url]” wrote:Not so. The printing is of the PDF, which has been distilled. The calculations for each page have been done. (Average page size: only 4k!)

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.

Posted: **08:07 Sun 03 Apr 2011**

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

Posted: **22:51 Thu 07 Apr 2011**

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

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

Posted: **14:28 Sat 09 Apr 2011**

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

Posted: **10:11 Sun 24 Apr 2011**

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.

Posted: **10:20 Sun 15 May 2011**

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

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

Posted: **17:18 Sun 15 May 2011**

I like both suggestions.

Posted: **13:49 Thu 19 May 2011**

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

Posted: **13:54 Thu 19 May 2011**

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

Posted: **16:24 Thu 19 May 2011**

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.

Posted: **16:29 Thu 19 May 2011**

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

Posted: **16:35 Thu 19 May 2011**

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.

Posted: **16:42 Thu 19 May 2011**

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

Posted: **16:49 Thu 19 May 2011**

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

Posted: **20:12 Thu 19 May 2011**

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.

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.

Posted: **20:21 Thu 19 May 2011**

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

Posted: **20:21 Thu 19 May 2011**

jdaw1 wrote:Good idea.

Posted: **20:22 Thu 19 May 2011**

jdaw1 wrote:This tickles me less.

Posted: **22:02 Thu 19 May 2011**

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

DRT wrote:

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.

Posted: **11:24 Fri 20 May 2011**

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

Posted: **11:28 Fri 20 May 2011**

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.

Posted: **11:53 Fri 20 May 2011**

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

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

Posted: **11:59 Fri 20 May 2011**

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

Posted: **12:10 Fri 20 May 2011**

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

Posted: **12:27 Fri 20 May 2011**

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

Posted: **14:15 Fri 20 May 2011**

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

Posted: **23:14 Fri 20 May 2011**

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

Posted: **14:46 Sat 21 May 2011**

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.

Posted: **16:00 Sat 21 May 2011**

I have no objection to deleting this feature.

Posted: **19:31 Sat 21 May 2011**

Nor do I.

Posted: **21:49 Sat 21 May 2011**

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.

Posted: **21:57 Sat 21 May 2011**

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

Posted: **22:00 Sat 21 May 2011**

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

Posted: **06:31 Sun 22 May 2011**

Happy with deletion.

Axel

Posted: **06:33 Sun 22 May 2011**

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.

Posted: **23:49 Fri 27 May 2011**

Done.

Posted: **23:53 Fri 27 May 2011**

jdaw1 wrote:Done.

Good.

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.

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