Software that makes placemats

[JacobH]

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

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

[jdaw1]

Food Menus and the Placemat Software

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

Do any readers object to it being deleted?

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

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

[Glenn E.]

I have no objection to deleting this feature.

[DRT]

Nor do I.

[Alex Bridgeman]

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

I vote delete.

[jdaw1]

at the moment

Deletion from the code is intended to be permanent.

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

[Alex Bridgeman]

at the moment

Deletion from the code is intended to be permanent.

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

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

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

I maintain my vote to delete.

[Axel P]

Happy with deletion.

Axel

[jdaw1]

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

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

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

[jdaw1]

Done.

[DRT]

Done.

Good.

[jdaw1]

Abovetitles, Belowtitles, Overtitles
Software tidying, continued!

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

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

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

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


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

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

[Alex Bridgeman]

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

[jdaw1]

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

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

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

[JacobH]

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

I might therefore might be tempted to:

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

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


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

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

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

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

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

[jdaw1]

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

I have, but more is definitely needed.

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

Our processes differ.

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

II might therefore might be tempted to:

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

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

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

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

Then have the font declarations

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Splendid names. Just splendid.

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

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

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

[jdaw1]

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

Splendid names. Just splendid.

Do others have an opinion on the relative merits of:

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

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

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

[jdaw1]

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

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

Please comment.

[jdaw1]

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

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

[SushiNorth]

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

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

Please comment.

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

[jdaw1]

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

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

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

[jdaw1]

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

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

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

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

[JacobH]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[JacobH]

/DecantingTitles [ ! ] def

This is an interesting idea.

The functionality is already there, but fiddly to access. Start at the placemats for the Sandeman vertical on 13 May 2011: observe that on page 1, on a glasses sheet, there is the title ‟27”, but that on the tasting-note sheet on page 6 this is ‟1927”.

Observe also within the placematsfor the Fonseca Guimaraens vertical on 04 April 2011 that both OverlapSubtitlesOnTitles and InlineTitles vary.

So already it can be done.

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

[jdaw1]

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

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

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

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

All is revealed:

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

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

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

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

Simple: new default is to be 1.

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

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

I wonder if the third is unnecessarily over-complex?

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

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

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