Software that makes placemats

[DRT]

mostly, people want glasses divvied over however many sheets it takes, up to six glasses on each. The default does that.

I suspect that the people who mostly want that are people who regularly drink Port at The Bunghole using white wine glasses that are significantly larger than ISO or Reidel Port glasses.

[jdaw1]

I suspect that the people who mostly want that are people who regularly drink Port at The Bunghole using white wine glasses that are significantly larger than ISO or Reidel Port glasses.

Fair, but that is the target audience of the default behaviour.

Anyway, any comment on either of:

• Maybe something like

  Code: Select all

  /GlassesOnSheetsMode /SpreadOverSheets def    % /SpreadOverSheets /Custom
  /GlassesOnSheetsMaxPerSheet 6 def    % For all glasses on one sheet set to a big integer
  /GlassesOnSheetsCustom [  [ 0 1 2 3 ]  [ 4 5 6 7 ]  [ 8 9 10 11 ]  ] def

• Actually, maybe ‟GlassesOnSheets” could have a better name. Suggestions?

[DRT]

any comment on either of:

• Maybe something like

  Code: Select all

  /GlassesOnSheetsMode /SpreadOverSheets def    % /SpreadOverSheets /Custom
  /GlassesOnSheetsMaxPerSheet 6 def    % For all glasses on one sheet set to a big integer
  /GlassesOnSheetsCustom [  [ 0 1 2 3 ]  [ 4 5 6 7 ]  [ 8 9 10 11 ]  ] def

• Actually, maybe ‟GlassesOnSheets” could have a better name. Suggestions?

The new parameters look fine to me.

Perhaps "GlassesPerSheet" describes it better?

[DRT]

Does "For all glasses on one sheet set to a big integer" mean what it says, or should it say "For more or fewer than 6 glasses on one sheet set to the required integer"?

[Glenn E.]

Code: Select all

/GlassesOnSheets [ 
	[ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ]
] def

or

Code: Select all

/GlassesOnSheets [ 
	[ 0 1 17 {} for ]
] def

Aha! That made it click. GlassesOnSheets is an array that specifies each of the glasses, so it must contain a number of elements equal to the size of the other arrays that detail the Ports being consumed (CircleArrays, Titles, et al). Thank you.

I also don’t like the default of GlassesOnSheets. But, mostly, people want glasses divvied over however many sheets it takes, up to six glasses on each. The default does that. Please suggest an alternative parameterisation that would capture the two possible modes: auto ≤6; and truly custom.

Edit: Maybe something like

Code: Select all

/GlassesOnSheetsMode /SpreadOverSheets def    % /SpreadOverSheets /Custom
/GlassesOnSheetsMaxPerSheet 6 def    % For all glasses on one sheet set to a big integer
/GlassesOnSheetsCustom [  [ 0 1 2 3 ]  [ 4 5 6 7 ]  [ 8 9 10 11 ]  ] def

That seems to come much closer to the intuition of what’s wanted, and keeps some nasty code out of the parameters. Objections?

Actually, maybe ‟GlassesOnSheets” could have a better name. Suggestions?

I don't speak PostScript, so I won't attempt actual code. However, could GlassesOnSheetsMode specify either /Multiple or /Single? Specifying /Multiple would then require /GlassesOnSheetsMaxPerSheet to be defined, while specifying /Single would attempt to put all glasses on a single sheet. (Essentially setting /GlassesOnSheetsMaxPerSheet to the size of CircleArrays, Titles, et al.)

[jdaw1]

Aha! That made it click. GlassesOnSheets is an array that specifies each of the glasses, so it must contain a number of elements equal to the size of the other arrays that detail the Ports being consumed (CircleArrays, Titles, et al). Thank you.

No. GlassesOnSheets is an array of arrays, outer length = number of sheets, innermostly holding pointers to the elements of Titles etc. But GlassesOnSheets can omit some elements of Titles, and can include duplicates.

[jdaw1]

However, could GlassesOnSheetsMode specify either /Multiple or /Single? Specifying /Multiple would then require /GlassesOnSheetsMaxPerSheet to be defined, while specifying /Single would attempt to put all glasses on a single sheet.

If GlassesOnSheetsMaxPerSheet is, say, 9999, what’s the difference?

[Glenn E.]

However, could GlassesOnSheetsMode specify either /Multiple or /Single? Specifying /Multiple would then require /GlassesOnSheetsMaxPerSheet to be defined, while specifying /Single would attempt to put all glasses on a single sheet.

If GlassesOnSheetsMaxPerSheet is, say, 9999, what’s the difference?

Effectively none. Having /Single would simply be an obvious shorthand method of setting GlassesOnSheetsMaxPerSheet appropriately. That functionality could also be covered by an appropriate comment.

[jdaw1]

But you prefer changing /Multiple to /Single to changing 6 to 9999? OK, I can live with that.

[Glenn E.]

But you prefer changing /Multiple to /Single to changing 6 to 9999? OK, I can live with that.

I think it makes the code more readable and more understandable for the non-programmers who use it.

I'm fine with either because your commenting of the code is outstanding.

[jdaw1]

your commenting of the code is outstanding.

Nobody has ever said that to me before I’ll enjoy a moment of smugness.

[Glenn E.]

I just noticed that São isn't generating properly for me. I cut & paste the 'ã' character into the .ps file and it saves correctly as a text file, but when I generate the .pdf using ps2pdf.com it gets rendered as a superscript 'a' instead.

What am I doing wrong?

[jdaw1]

[(S) /atilde (o)]
(see www.jdawiseman.com/papers/placemat/plac ... oundstring).

Your ‟㔝 is in a Windows encoding. If PS2PDF.com runs on a different OS, it might have a different encoding. Hence this robust and general ASCII-generated methodology.

[jdaw1]

Postponing the definition of GlassesOnSheets, as suggested above, requires changing the setting of FlightSeparationLines, BackgroundTextsGlassesTexts, PageOrderingNonDecanterLabelGlasses, FillTextAngle, CrossHatchingCentreX, CrossHatchingCentreY, WaterCountShowLeft, WaterCountShowRight, PageOrderingPrePourPages, PageOrderingDecanterLabels, and PageOrderingStickyLabels.

GlassesOnTastingNotePages would presumably have a similar handling to that proposed above for GlassesOnSheets. But that is used in GlassesClusteredOnVoteRecorders, PageOrderingTastingNotePages, GlassesClusteredOnDecantingNotes, and GlassesClusteredOnCorkDisplay.

A few of these are easy to fix. That leaves the remainder. pulling on this string will have lots of consequences. So I might try to ‘disconnect’ the consequences before doing the important bit.

[Glenn E.]

[(S) /atilde (o)]
(see www.jdawiseman.com/papers/placemat/plac ... oundstring).

Your ‟㔝 is in a Windows encoding. If PS2PDF.com runs on a different OS, it might have a different encoding. Hence this robust and general ASCII-generated methodology.

Obrigado.

[jdaw1]

I’m stuck. Currently we might have something like:

Code: Select all

/GlassesOnSheets [
	[ 0 1 2 3 4 ]
	[ 5 6 7 8 ]
	[ 9 10 11 12 13 ]
] def

after which we know that there are 3 glasses sheets, containing 5, 4 and 5 glasses. So far, so good.

Later, by default, we have

Code: Select all

/PageOrderingNonDecanterLabelGlasses [ GlassesOnSheets length {0} repeat ] def

which says that each of these three sheets has PageOrdering 0. That is, they will print together. That is, they are for the same session. Note that defining PageOrderingNonDecanterLabelGlasses required knowing how many sheets there were = GlassesOnSheets length. But if we had done /GlassesOnSheets /Multiple def (start reading from post 448), we wouldn’t know the number of sheets.

Suggestions from programmer-type readers would be welcomed.

Does "For all glasses on one sheet set to a big integer" mean what it says, or should it say "For more or fewer than 6 glasses on one sheet set to the required integer"?

Sorry, failed to notice this. Consider: arrange on as few sheets as possible subject to each sheet having ≤6. That’s the default. Now consider: arrange on as few sheets as possible subject to each sheet having ≤9999. That would be the same as saying ‟put them on one sheet”.

Perhaps "GlassesPerSheet" describes it better?

That feels like an integer, rather than a richer description of which glasses on which sheets.

[Glenn E.]

But if we had done /GlassesOnSheets /Multiple def (start reading from post 448), we wouldn’t know the number of sheets.

Suggestions from programmer-type readers would be welcomed.

My thought when suggesting /Multiple was to preserve the current default, which is to say that /Multiple implies however many sheets are required to keep the number of glasses per sheet at or below 6. My thought was also that when the number of glasses isn't evenly divisible by 6 that the glasses would be as evenly distributed among the required number of sheets as possible. So 5-5-4 rather than 6-6-2. I believe that all of that is how the software currently works, correct?

Perhaps "GlassesPerSheet" describes it better?

That feels like an integer, rather than a richer description of which glasses on which sheets.[/quote]
Or perhaps /MaxGlassesPerSheet, which defaults to 6? That would pair nicely with /Multiple to replicate the current default behavoir while also allowing greater flexibility. /Single would then be shorthand for /MaxGlassesPerSheet == 9999.

At this point, though, I recognize that we are overloading /GlassesOnSheets. (It seems that I have not been a programmer for too long.) /Multiple and /Single are inappropriate for /GlassesOnSheets, but the functionality can be covered by something like what Derek is suggesting.

[jdaw1]

the glasses would be as evenly distributed among the required number of sheets as possible. So 5-5-4 rather than 6-6-2. I believe that all of that is how the software currently works, correct?

Correct.

At this point, though, I recognize that we are overloading /GlassesOnSheets. (It seems that I have not been a programmer for too long.) /Multiple and /Single are inappropriate for /GlassesOnSheets, but the functionality can be covered by something like what Derek is suggesting.

I think the problem is different. Several parameters are arrays of the same length as GlassesOnSheets (e.g., BackgroundTextsGlassesTexts, PageOrderingNonDecanterLabelGlasses and PageOrderingStickyLabels). Currently, at the moment those parameters are set, it is possible to know how long is the array GlassesOnSheets (length = GlassesOnSheets length, which is easy). But if GlassesOnSheets /Multiple def, then those parameters cannot know how long is GlassesOnSheets. Which would be difficult.

[Glenn E.]

Currently, at the moment those parameters are set, it is possible to know how long is the array GlassesOnSheets (length = GlassesOnSheets length, which is easy). But if GlassesOnSheets /Multiple def, then those parameters cannot know how long is GlassesOnSheets. Which would be difficult.

I have not dug into the code in depth, so the answer to this question may be obvious. Or obviously difficult.

At what point is the current behavior set to 6 glasses per sheet? Could the code that sets that to 6 instead use a new parameter /MaxGlassesPerSheet that could be explained and set by the user early enough to avoid the difficulty with knowing the length of GlassesOnSheets?

[jdaw1]

At what point is the current behavior set to 6 glasses per sheet? Could the code that sets that to 6 instead use a new parameter /MaxGlassesPerSheet that could be explained and set by the user early enough to avoid the difficulty with knowing the length of GlassesOnSheets?

In that long line of code embedded in the default value of GlassesOnSheets. So it would be trivially easy to replace the 6 by a parameter deffed the line before: /GlassesOnSheetsMaxGlassesPerSheetInDefault 6 def. Would that make you happier?

[PhilW]

I must admit to not liking the definition option of /Multiple for /GlassesOnSheets; it seems confusing syntax to me.

If the problem being addressed is that the current code selects too small a default value for maximum number of glasses on certain paper sizes, could we not address that directly, perhaps by defining an array of default maximum glasses per paper-size or as an approximation based on paper length and width? This function is then used by the default /GlassesOnSheets (instead of '6'), and the user can override only by own definition of /GlassesOnSheets as currently (which I find clear and easy). Would this provide the required functionality more simply?

[jdaw1]

perhaps by defining an array of default maximum glasses per paper-size or as an approximation based on paper length and width? This function is then used by the default /GlassesOnSheets (instead of '6')

It is worth re-visiting an earlier observation on a related problem:

In the placemat code, the parameters lines are playing two roles - one as plain old code, another as user interface.

The same problem is happening here: both code, and UI.

Yes, there could be a predefined function that converts paper types to numbers of maximum numbers of Bung-Hole standard glasses, coping with non-standard paper sizes (of form [d₁ d₂] with 0<d₁≤d₂). Then there could be longer code in the default for GlassesOnSheets, using this. But part of GEE’s complaint was having lots of code in the parameters. Solving this by adding more code to the parameters won’t bother some users (me, perhaps PW), but will both many others. So yes, I see why, but I think no.

[PhilW]

The intention of my suggestion was to extend the current "non-user-intelligible" code for /GlassesOnSheets, not to modify the user variant (and hence parameters) in any way. However, I may be implicitly suggesting a separate of the code from the configuration which might not be possible in postscript as I am not familiar enough with the language.

My suggestion was the users could still override with the same syntax as currently (no additional parameters), such as
/GlassesOnSheets [ [ 0 1 2 3 4 ] [ 5 6 7 8 ] ] def
but that if the user had not provided a definition, then the default code would work as currently but using a value from array lookup or calculation as the maximum it would allow per page, based on the defined page size (which I am assuming has been earlier defined, so does not need to be passed as a parameter).

BTW, I'm quite happy with the answer "no" but thought I should ensure I had been clear in the suggestion.

[jdaw1]

but that if the user had not provided a definition

The problem is that the default value of several parameters needs the length of GlassesOnSheets. If that is absent or /Multiple, then its length is not known whilst the other parameters are being defined. That’s the problem.

[PhilW]

but that if the user had not provided a definition

The problem is that the default value of several parameters needs the length of GlassesOnSheets. If that is absent or /Multiple, then its length is not known whilst the other parameters are being defined. That’s the problem.

I can see that issue based on the planned/updated implementation to allow use of /Multiple; I was suggesting an alternative - varying the original default definition of /GlassesOnSheets to take into account paper size for maximum number of glasses on each sheet; this should then be overridable by user with original syntax as previously; Similarly if no user definition were supplied then the default would set /GlassesOnSheets as it has done for the last few months (with the modification for page-size based limit on maximum glasses per page) and the length would thereby be being known for other parameters, as previously.

[PhilW]

pseudo-code of intended suggestion:

Change code from:

Code: Select all

/GlassesOnSheets [
 [ 0 Titles length 1 sub /e exch def /s exch def s 1 e {dup e lt e s sub 6 ge and {dup s sub e s sub 1 add dup 6 div ceiling cvi 3 -1 roll 3 copy mul exch idiv 4 1 roll 1 add mul exch idiv ne {][} if} if} for ]
] def % /GlassesOnSheets

To:

Code: Select all

/MaxGlassesOnSheets [
  page_height_in_mm page_width_in_mm mul 12000 div
] def % /MaxGlassesOnSheets

/GlassesOnSheets [
 [ 0 Titles length 1 sub /e exch def /s exch def s 1 e {dup e lt e s sub /MaxGlassesOnSheets ge and {dup s sub e s sub 1 add dup /MaxGlassesOnSheets div ceiling cvi 3 -1 roll 3 copy mul exch idiv 4 1 roll 1 add mul exch idiv ne {][} if} if} for ]
] def % /GlassesOnSheets

No other changes (no /Multiple etc), but solves Glenn's original issue of max per page for variety of page sizes.

[jdaw1]

That almost works for me. Alas we don’t know the paper size (/A4 and other cases needs converting) but that can be kludged.

Next table shows paper size, (Height”“2×30pt) × (Width”“2×30pt) in pt², and this divided by 64k.
/A4    419,482   6.55
/USL   404,064   6.31
/A3    885,928  13.84
/USL2  852,048  13.31

[jdaw1]

So a new parameter and better commenting:

Code: Select all

/GlassesOnSheetsMaxGlassesPerSheetInDefault  6  /PaperType load dup /A3 eq exch /USL2 eq or {pop 13} if  /PaperType load /USLegal eq {pop 9} if  def  % 6 default, USLegal => 9; A3 or USL2 => 13. For all on one sheet replace with "/GlassesOnSheetsMaxGlassesPerSheetInDefault 9999 def".

/GlassesOnSheets [

	% For a custom arrangement delete the next line and replace with the likes of [0 1 2 3] [4 5 6 7 8 9] [10 11 12 13]

	[ 0  Titles length 1 sub  /e exch def /s exch def  s 1 e {dup e lt e s sub GlassesOnSheetsMaxGlassesPerSheetInDefault ge and {dup s sub e s sub 1 add dup GlassesOnSheetsMaxGlassesPerSheetInDefault div ceiling cvi 3 -1 roll 3 copy mul exch idiv 4 1 roll 1 add mul exch idiv ne {][} if} if} for ]

] def  % /GlassesOnSheets

(I’ve added extra line breaks here for better reading with browser wrapping.)

Objections?

And yes, I need a hard think about TN-sheet arrangements.

[PhilW]

No objection; just one further thought. You could separate the user-specified version, so that all of the 'code' stays in the main untouched sections, by doing something like:

Code: Select all

% For a custom arrangement, modify the /UserGlassesOnSheets defintion below
%   e.g.  /UserGlassesOnSheets [ [0 1 2 3] [4 5 6 7 8 9] [10 11 12 13] ] def
/UserGlassesOnSheets [] def

/GlassesOnSheetsMaxGlassesPerSheetInDefault  6  /PaperType load dup /A3 eq exch /USL2 eq or {pop 13} if  /PaperType load /USLegal eq {pop 9} if  def  % 6 default, USLegal => 9; A3 or USL2 => 13. For all on one sheet replace with "/GlassesOnSheetsMaxGlassesPerSheetInDefault 9999 def".

/GlassesOnSheets [
  % PSEUDO-CODE!
  IF /UserGlassesOnSheets != [] THEN
    /UserGlassesOnSheets
  ELSE
    [ 0  Titles length 1 sub  /e exch def /s exch def  s 1 e {dup e lt e s sub GlassesOnSheetsMaxGlassesPerSheetInDefault ge and {dup s sub e s sub 1 add dup GlassesOnSheetsMaxGlassesPerSheetInDefault div ceiling cvi 3 -1 roll 3 copy mul exch idiv 4 1 roll 1 add mul exch idiv ne {][} if} if} for ]
  ENDIF
] def  % /GlassesOnSheets

Then for a user-specific defined layout, they just edit/move /UserGlassesOnSheets to the top and leave all the hidden workings untouched below.

[jdaw1]

I see what you’re doing, but occasionally I actually want /GlassesOnTastingNotePages [] def.

[PhilW]

I see what you’re doing, but occasionally I actually want /GlassesOnTastingNotePages [] def.

Could be handled:

Code: Select all

%!PS

%% --- user section
%
% uncomment this line for manual definition; leave commented for auto definition
/userValue (red) def

%% -- main "do not touch" section
%
/autoValue (blue) def
/Value {
  currentdict /userValue known {userValue} {autoValue} ifelse
} def
%
/Courier findfont
20 scalefont
setfont
72 500 moveto
Value show
showpage

[jdaw1]

New version went on website earlier today. I’ll re-peruse PW’s post tomorrow.

Whilst I was at it, I looked at he code Glenn E. hadn’t liked, and no longer understood it. And then I realised that it could be done more legibly and more concisely, and in a way that allowed there to be some slight further control. Whoopee!

[Glenn E.]

New version went on website earlier today. I’ll re-peruse PW’s post tomorrow.

Splendid.

Question re:

Code: Select all

% GlassesOnSheetsMaxPerSheet: 6 default, USLegal => 9; A3 or USL2 => 13. For all on one sheet replace with "/GlassesOnSheetsMaxGlassesPerSheetInDefault 999 def".
/GlassesOnSheetsMaxPerSheet  6  /PaperType load dup /A3 eq exch /USL2 eq or {pop 13} if  /PaperType load /USLegal eq {pop 9} if  def

Are these instructions correct? /GlassesOnSheetsMaxGlassesPerSheetInDefault does not appear to be used anywhere else in the program, so setting it to 999 seems like it would have no effect.

Whilst I was at it, I looked at he code Glenn E. hadn’t liked, and no longer understood it.

I'm somewhat relieved to know that it wasn't just me.

[jdaw1]

You quoted my draft from this thread, rather than that in the code.

Code: Select all

% GlassesOnSheetsMaxPerSheet: 6 default, USLegal => 9; A3 or USL2 => 13. For all on one sheet replace with "/GlassesOnSheetsMaxGlassesPerSheetInDefault 999 def".
/GlassesOnSheetsMaxPerSheet  6  /PaperType load dup /A3 eq exch /USL2 eq or {pop 13} if  /PaperType load /USLegal eq {pop 9} if  def
/GlassesOnSheets [
	% For a custom arrangement replace the next line  with something of the form "[0 1 2 3] [4 5 6 7 8 9] [10 11 12 13]"
	% The code below spreads glasses evenly over the sheets, the one-larger sheets being last. For them to be early replace "floor" with "ceiling"; for them to be evenly distributed with "round".
	<< /p Titles length GlassesOnSheetsMaxPerSheet div ceiling cvi  /g 0 >> begin 0 1 p 1 sub {[exch p sub g Titles length sub exch div floor cvi {g /g g 1 add def} repeat]} for end
] def  % /GlassesOnSheets

[/size]There are three relevant changes to the default definition of GlassesOnSheets.

1. The default used to be take-it-or-leave-it. Now it has a parameter, GlassesOnSheetsMaxPerSheet, which itself has a useful default. E.g., /GlassesOnSheetsMaxPerSheet 8 def, makes the default GlassesOnSheets as few pages as possible, subject to the limit of ≤8 glasses per sheet ⇒ ⌈ (Titles length) ÷ 8 ⌉ sheets). So /GlassesOnSheetsMaxPerSheet 999 def will put all on ⌈ ε ⌉ = 1 sheet.

2. There is comment to help use or replace the default.

3. The code is less cryptic, and admits of (slight) alteration, as described in the comments.

The manual will be updated soon.

[Glenn E.]

Hmm. Very strange, as I went to jdawiseman.com and checked the code there. Perhaps my browser had it cached? No matter.

[jdaw1]

! Also the position of centre header needed to be changed, for which the code had been altered to add the parameter HeaderFooterCenterRelativeX. This was then assigned to some 132 characters of code, the complication of which might suggest that the form of this parameter was not optimally chosen. (See software thread.)

Using this again for the Taylor tasting, it was suddenly obvious that HeaderFooterCenterX, so not Relative, would be much easier to use. Change made.

Edit: also see parameters used for the Taylor tasting.

[jdaw1]

[quote="In the thread entitled ‟Parameters for the placemat software", jdaw1"]• Because the T35 and TV70 appear on both glasses sheets, they have twice as many labels as the others. Error. What to do? This could have been fixed in the parameters by making StickyLabelsNumCopies much more complicated, but that would be nasty. Of course there can’t be a !StickyLabels! equivalent of GlassesClusteredOnVoteRecorders, so it can’t be fixed that way. So instead I will code StickyLabels! equivalents to PrePourRemoveDuplicatesByWithinTitles and PrePourSortByWithinTitles.[/quote]

[PhilW]

[quote="In the thread entitled ‟Parameters for the placemat software", jdaw1"]• Because the T35 and TV70 appear on both glasses sheets, they have twice as many labels as the others. Error. What to do? This could have been fixed in the parameters by making StickyLabelsNumCopies much more complicated, but that would be nasty. Of course there can’t be a !StickyLabels! equivalent of GlassesClusteredOnVoteRecorders, so it can’t be fixed that way. So instead I will code StickyLabels! equivalents to PrePourRemoveDuplicatesByWithinTitles and PrePourSortByWithinTitles.

[/quote]
Perhaps early on in the page processing it might be worth creating/defining a UniqueGlasses from GlassesOnSheets, which could then be used by all such later processing?

[jdaw1]

Perhaps early on in the page processing it might be worth creating/defining a UniqueGlasses from GlassesOnSheets, which could then be used by all such later processing?

Good idea.

[jdaw1]

Extra settings, and their defaults:

Code: Select all

/StickyLabelsReverseOrder false def
/StickyLabelsRemoveDuplicatesByWithinTitles true def
/StickyLabelsSortByWithinTitles true def

Perhaps early on in the page processing it might be worth creating/defining a UniqueGlasses from GlassesOnSheets, which could then be used by all such later processing?

Not done, as the PrePour! and StickyLabels! settings might differ.

[jdaw1]

In setting up the recent Taylor vertical, AHB was pouring and DRT and I were distributing. Naturally enough, the young vintages were pre-poured first, and soon enough the front rows were filled with glasses. Then the older glasses had to be lifted awkwardly behind the already-full first row. It was fiddly.

This problem could be solved by reversing the order of rows of on the sheet. AHB remarked that having the older vintages nearer would help his smelling of them.

There is already a parameter, very rarely changed, PackingDirectionVertical, which can take values /TopToBottom or /BottomToTop. So the change isn’t tricky.

However, doing this by default would rather conflict with my sense of natural order. Vintage lists start old, and have the new at the end, allowing the list to be extended with the passage of time. My sense of old-to-new / top-to-bottom natural order is quite strong is that just me?

[DRT]

I had a similar thought while distributing the wines but either way the taster has to remove and replace glasses in the back row throughout the evening. For some inexplicable reason, this manoeuvre gets trickier as time goes by.

Perhaps a third parameter /TopLeftToBottomRight could be used so that the wines end up in columns of four working from left to right.

[jdaw1]

There are currently two relevant settings.
• PackingDirectionVertical, which can be /TopToBottom or /BottomToTop;
• PackingDirectionHorizontal, which can be /LeftToRight or /LeftToRight.

DRT seems to be asking for another setting, PackingNestingOrder, with allowed values of /RowsThenColumns (current behaviour) and /ColumnsThenRows.

Let’s have some examples in mind.

(These shown with glasses in current default order.)

For the first two examples, with an easy rectangular layout, any of the eight possibilities from these 2+1 parameters would make sense. So far, so good.

The third example can also cope with any of the eight parameter arrangements. But for the fourth, is the top-most glass (‘A0’) in a column of its own? Yes, I guess so. So that could work.

But what should be the default behaviour? Should it really be this:
/PackingNestingOrder /ColumnsThenRows def
/PackingDirectionVertical /BottomToTop def
/PackingDirectionHorizontal /LeftToRight def

This order seems weird to me. Just me?

[DRT]

The current default behaviour is perfect for smallish tastings so should remain the default. But the ability to produce the format that you find odd is useful for tastings where the tasting mats become elongated, such as was the case at the Taylor tasting on Friday.

[PhilW]

The current default behaviour is perfect for smallish tastings so should remain the default. But the ability to produce the format that you find odd is useful for tastings where the tasting mats become elongated, such as was the case at the Taylor tasting on Friday.

Agreed with preference for current behaviour as default; so if adding this extension, then defaults of:
/PackingNestingOrder /RowsThenColumns def
/PackingDirectionVertical /TopToBottom def
/PackingDirectionHorizontal /LeftToRight def
(though noting AHB's preference for BottomToTop).

[jdaw1]

DRT, PhilW: assuming settings of /ColumnsThenRows, /TopToBottom, and /LeftToRight, in which order would the following two layouts be? (Your answer should be of the form ‟A0, D3, !”, though not necessarily starting with those two.)

[jdaw1]

I’m hoping the answers are:
• G6, A0, D3, H7, B1, E4, I8, C2, F5, J9;
• D3, H7, A0, E4, I8, B1, F5, J9, C2, G6, K10.

[PhilW]

I’m hoping the answers are:
• G6, A0, D3, H7, B1, E4, I8, C2, F5, J9;
• D3, H7, A0, E4, I8, B1, F5, J9, C2, G6, K10.

I'd agree with both answers.

[Glenn E.]

I’m hoping the answers are:
• G6, A0, D3, H7, B1, E4, I8, C2, F5, J9;
• D3, H7, A0, E4, I8, B1, F5, J9, C2, G6, K10.

I'd agree with both answers.

+1

I'm also pleased to now know of the existence of /PackingDirectionVertical and /PackingDirectionHorizontal. This will save me from having to manually arrange the Ports in the various lists so that they come out with the oldest front left and the youngest back right! If I understand correctly, that would only require that I change /PackingDirectionVertical to /BottomToTop?

See, there really is a point to keeping up with this thread.

[jdaw1]

I'm also pleased to now know of the existence of /PackingDirectionVertical and /PackingDirectionHorizontal.

Happiness. But PackingNestingOrder is, currently, only a planned parameter. It does not yet exist.