Ah, that’s quite a nice, simple solution to the problem!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.
Software that makes placemats
- JacobH
- Quinta do Vesuvio 1994
- Posts: 3300
- Joined: 16:37 Sat 03 May 2008
- Location: London, UK
- Contact:
Re: Software that makes placemats
Re: Software that makes placemats
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.
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.
Re: Software that makes placemats
Nor do I.
"The first duty of Port is to be red"
Ernest H. Cockburn
Ernest H. Cockburn
- Alex Bridgeman
- Graham’s 1948
- Posts: 14902
- Joined: 13:41 Mon 25 Jun 2007
- Location: Berkshire, UK
Re: Software that makes placemats
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.
I vote delete.
Top Ports in 2023: Taylor 1896 Colheita, b. 2021. A perfect Port.
2024: Niepoort 1900 Colheita, b.1971. A near perfect Port.
2024: Niepoort 1900 Colheita, b.1971. A near perfect Port.
Re: Software that makes placemats
Deletion from the code is intended to be permanent.AHB wrote:at the moment
If the TCP were to have an unchanging menu, would this feature be used? If yes, a stay of execution becomes appropriate.
- Alex Bridgeman
- Graham’s 1948
- Posts: 14902
- Joined: 13:41 Mon 25 Jun 2007
- Location: Berkshire, UK
Re: Software that makes placemats
If TCP were to have an unchanging menu then the feature would be much more practical to use and would probably be used.jdaw1 wrote:Deletion from the code is intended to be permanent.AHB wrote:at the moment
If the TCP were to have an unchanging menu, would this feature be used? If yes, a stay of execution becomes appropriate.
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.
Top Ports in 2023: Taylor 1896 Colheita, b. 2021. A perfect Port.
2024: Niepoort 1900 Colheita, b.1971. A near perfect Port.
2024: Niepoort 1900 Colheita, b.1971. A near perfect Port.
Re: Software that makes placemats
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.
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.
Re: Software that makes placemats
Good.jdaw1 wrote:Done.
"The first duty of Port is to be red"
Ernest H. Cockburn
Ernest H. Cockburn
Re: Software that makes placemats
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.
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?
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.
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
- Graham’s 1948
- Posts: 14902
- Joined: 13:41 Mon 25 Jun 2007
- Location: Berkshire, UK
Re: Software that makes placemats
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.
Top Ports in 2023: Taylor 1896 Colheita, b. 2021. A perfect Port.
2024: Niepoort 1900 Colheita, b.1971. A near perfect Port.
2024: Niepoort 1900 Colheita, b.1971. A near perfect Port.
Re: Software that makes placemats
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.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.
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
- Quinta do Vesuvio 1994
- Posts: 3300
- Joined: 16:37 Sat 03 May 2008
- Location: London, UK
- Contact:
Re: Software that makes placemats
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:
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).
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.
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).
Re: Software that makes placemats
I have, but more is definitely needed.JacobH wrote:might you give some thought to the ordering of the code at the start of the file?
Our processes differ.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.
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.
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: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.
I don’t think that I have ever used an alternative to /None//LowerNonWaterCount: have you? Often?JacobH wrote:
- Put /ThePortForumIcon[...] declarations just under that (and add a comment listing the alternatives to /None and /LowerNonWaterCount
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 have the font declarations
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.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.
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 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: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).
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.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?
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.
Good idea. But, given my post three above, and AHB’s favourable reply two above, perhaps too late.JacobH wrote:I would also treat /OverlapSubtitlesOnTitles as a decorative question and put it with those declarations.
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: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?
Fair, but, again, is there an advantage in having them with related conceptually-similar parameters.JacobH wrote:If they are not intended to be modified, perhaps they could be put somewhere else in the file.
Some of these new parameters, most especially TitlesTastingNotes, have already been used by me.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.
Splendid names. Just splendid.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?).
And then code is brought back into some parameters. Hmmm.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).
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.
Re: Software that makes placemats
jdaw1 wrote:Splendid names. Just splendid.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?).
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?
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.
Re: Software that makes placemats
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.
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.
Re: Software that makes placemats
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
- Martinez 1985
- Posts: 1341
- Joined: 07:45 Mon 18 Feb 2008
- Location: NJ & NY
Re: Software that makes placemats
Yes, i think organizing the parameters into sections might help, and perhaps even offering two subsections within each. For example, you might want:jdaw1 wrote:Jacob: the problem with the organisation of the parameters might be the lack of it. Would it help to divide the parameters into sections? Possible sections might be: • Essentials; • Non-Glasses Pages; • Fonts and Greys; • Page Organisation and Page-Level Features; • Glasses: Decoration Controls; • Obscure and Little-Used Parameters.
At jdawiseman.com/port/20110608_possible_parameters_rearangement.ps is a sketch of a possible arrangement. It doesn’t quite follow your order, as some default values depend on the values of other parameters.
Please comment.
*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
Re: Software that makes placemats
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 wrote:There are a slew of parameters controlling various aspects of the subtitles. Most, if not all, of these will need to be split into three for the three new arrays. Are there any exceptions: things for which you strongly belief that the three arrays must be the same?
- SameSizeSubtitlesIfAllOf (also need a parameter to control size-matching between the new arrays);
Re: Software that makes placemats
It isn’t obvious how best to capture this, there being several obvious possibilities.jdaw1 wrote:(also need a parameter to control size-matching between the new arrays)
- % 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.
- JacobH
- Quinta do Vesuvio 1994
- Posts: 3300
- Joined: 16:37 Sat 03 May 2008
- Location: London, UK
- Contact:
Re: Software that makes placemats
No, but just because I didn’t know what other options there were! If those are the only two, perhaps change it to a boolean?jdaw1 wrote:I don’t think that I have ever used an alternative to /None//LowerNonWaterCount: have you? Often?JacobH wrote:
- Put /ThePortForumIcon[...] declarations just under that (and add a comment listing the alternatives to /None and /LowerNonWaterCount
I think it’s fine as it is. The only thing I note is that I’ve never got that command to produce a list of available fonts working, but that may be my machine.jdaw1 wrote: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.
As a less advanced user, I don’t think I’ve ever changed the defaults on it but if you do all the time then perhaps it should stay near /Titles.jdaw1 wrote: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 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.jdaw1 wrote: Likewise, perhaps VoteRecorderNumCopies needs to be split into cases. Or perhaps I have the wrong default behaviour. Please consider further and advise.
And then code is brought back into some parameters. Hmmm.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).
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.
That looks very sensible and a big improvement. I imagine the devil will be in keeping the essentials to being essential, but I am sure you can cope! I would restore the longer comment about the fonts (I’m not sure if you had that in mind) and give some thought to /GlassesOnSheet and /VoteRecorderNumCopies for the reasons discussed above.jdaw1 wrote:Jacob: 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.
Hmm...no strong beliefs, but I wonder how often most of these will be set to different values (especially for sub-parameters, as it were, like /ShapesSubtitlesFill).jdaw1 wrote: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?
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?jdaw1 wrote:Preference? (I favour the third of these also see the explanation of a numerical value within SameSizeTitlesIfAllOf.) Better possibilities? (Please!)
- JacobH
- Quinta do Vesuvio 1994
- Posts: 3300
- Joined: 16:37 Sat 03 May 2008
- Location: London, UK
- Contact:
Re: Software that makes placemats
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 wrote:This is an interesting idea.DRT wrote:/DecantingTitles [ ! ] def
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.
Re: Software that makes placemats
Thank you for replying. The splitting of sub-titles, and rearrangement of parameters, will happen within a few weeks.
All is revealed:JacobH wrote:No, but just because I didn’t know what other options there were! If those are the only two, perhaps change it to a boolean?jdaw1 wrote:I don’t think that I have ever used an alternative to /None//LowerNonWaterCount: have you? Often?JacobH wrote:
- Put /ThePortForumIcon[...] declarations just under that (and add a comment listing the alternatives to /None and /LowerNonWaterCount
The Manual wrote:the parameter ThePortForumIconPlacement is set to one of /None, /LowerLeft, /LowerRight, /UpperLeft, /UpperRight, /LowerNonWaterCount, /UpperNonWaterCount or /UpperWaterCount, the last three evaluating to left or right according to the side on which the WaterCounts are placed.
Can you access the log file? And have you tried distilling www.jdawiseman.com/papers/placemat/fonts_illustrated.ps?JacobH wrote:The only thing I note is that I’ve never got that command to produce a list of available fonts working, but that may be my machine.
Simple: new default is to be 1.JacobH wrote:jdaw1 wrote: Likewise, perhaps VoteRecorderNumCopies needs to be split into cases. Or perhaps I have the wrong default behaviour.
Understandable, and partly satisfied by having all the information in the Circlearrays. I am wielding by authorial veto here: I don’t like the commas, so the default won’t add commas. The most interesting or distinguishing sub-title can be shown large on the non-glasses sheets; the Circlearrays having all. If experience shows that to be unsatisfactory, say so in this thread and it will be reconsidered.JacobH wrote:! 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.
To be aesthetically pleasing, it is important not to have too many type sizes. If ‟this” is in 26pt, and ‟that” in 24pt, and the ‟other” in 21pt, it looks sloppy. But we don’t want to set in the same size ‟Dow” and ‟Quinta Nova de Nossa Senhora do Carmo”: it is sensible to have the former larger than the latter. Controllably resolving the tension between these desiderata has proved challenging, even with only one type of sub-title. (The controls were recently changed.) So the complexity seems necessary. However, the defaults should be sufficiently satisfactory for most users.JacobH wrote:I wonder if the third is unnecessarily over-complex?
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.JacobH wrote:It may therefore make sense for there to be a separate decanting note for each one. Is the most sensible way of achieving this to redefine /DecantingNotesTitles &c. or is there a better way it could be achieved.