Software that makes placemats

[jdaw1]

Added RotationTitlesAboveBelowOverCirclearray, use of which can be seen in the placemats for Griff’s departure down under.

[Glenn E.]

Bug: /GlassesOnSheetsMaxPerSheet 999 def does not have the desired effect when /PaperType /USLegal def. Instead, it appears to revert to the default for /GlassesOnSheetsMaxPerSheet for that paper type, which is 9.

I was able to work around the problem by changing the default behavior to 10, which was the number of glasses that I wished to place on each sheet.

[Glenn E.]

While I'm doing QA, I just downloaded a fresh copy of the software from http://www.jdawiseman.com/placemat and it still contains the following comment:

% GlassesOnSheetsMaxPerSheet: 6 default, USLegal => 9; A3 or USL2 => 13. For all on one sheet replace with "/GlassesOnSheetsMaxGlassesPerSheetInDefault 999 def".

/GlassesOnSheetsMaxGlassesPerSheetInDefault is not used anywhere else in the software, so setting it to 999 will have no effect.

[jdaw1]

GlassesOnSheetsMaxGlassesPerSheetInDefault is used in the next line of the parameters.

Edit: I renamed parameter, but not in comment. Sorry. It should be GlassesOnSheetsMaxPerSheet. Fixed in new version of code.

[Glenn E.]

Bug: /GlassesOnSheetsMaxPerSheet 999 def does not have the desired effect when /PaperType /USLegal def. Instead, it appears to revert to the default for /GlassesOnSheetsMaxPerSheet for that paper type, which is 9.

I was able to work around the problem by changing the default behavior to 10, which was the number of glasses that I wished to place on each sheet.

I spoke too soon.

Caveat: I am working on Windows 8 and am unfamiliar with the applications that come pre-installed on a Windows 8 box. It is entirely possible, if not probable, that my difficulties are derived from this and not from the code. However...

My work around above did indeed put 10 glasses on each sheet, but the sheets were USL and not USLegal. When printed they left a good chunk of white space (3") on the tail end of the sheet. The arrangement of glasses should have tipped me off, as the software created a hex-ish pattern 2-3-2-3 when I was expecting the more normal slightly staggered straight rows of 3-4-3.

[jdaw1]

Please post a link to a PDF and state clearly what you believe to be the bug.

[Glenn E.]

Neither pdf nor ps are allowed as uploads. I've spent too much time on this today... we'll do without placemats this time and I'll try to figure out what happened later.

[Glenn E.]

Success. The problem appears to have been with Windows 8's "Reader" app. It looks like it recognizes US Legal size paper, but in reality it appears that it does not because USLegal files sent to a printer are instead re-sized to fit on USL but then printed on USLegal anyway. I was able to print successfully once I forced Windows 8 to use Word to open the pdf, converted the pdf to Word format (at the risk of losing fidelity), then converted it again to editable format because it wouldn't let me print otherwise.

*sigh*

This bug remains:

/GlassesOnSheetsMaxPerSheet 999 def does not have the desired effect when /PaperType /USLegal def. Instead, it appears to revert to the default for /GlassesOnSheetsMaxPerSheet for that paper type, which is 9. It does have the desired effect when /PaperType /USL def or /PaperType /USL2 def.

[jdaw1]

The ante-penultimate bullet of the green box describes a bug with Konica Minolta printers. Please could you write a concise description of problem and solution for me to add int he same place?

/GlassesOnSheetsMaxPerSheet 999 def does not have the desired effect when /PaperType /USLegal def. Instead, it appears to revert to the default for /GlassesOnSheetsMaxPerSheet for that paper type, which is 9. It does have the desired effect when /PaperType /USL def or /PaperType /USL2 def.

I suspect that you are doing /GlassesOnSheetsMaxPerSheet 999 def, without having deleted the usual definition of GlassesOnSheetsMaxPerSheet, which is therefore redefined to its default value. If not that, please email me your code.

[jdaw1]

New draft of the placemats.

• Completely redone, hopefully in accordance with instructions received from DRT.

Could you please change the order of the subtitles to correspond with the above and set the parameters so that they appear as:

1 4 7 10 13
2 5 8 11 14
3 6 9 12 13

After which,

Updated draft of the placemats.

• Slightly redone, hopefully in accordance with instructions received from DRT.

In light of all of which, recall that

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

Action is needed.

[Glenn E.]

/GlassesOnSheetsMaxPerSheet 999 def does not have the desired effect when /PaperType /USLegal def. Instead, it appears to revert to the default for /GlassesOnSheetsMaxPerSheet for that paper type, which is 9. It does have the desired effect when /PaperType /USL def or /PaperType /USL2 def.

I suspect that you are doing /GlassesOnSheetsMaxPerSheet 999 def, without having deleted the usual definition of GlassesOnSheetsMaxPerSheet, which is therefore redefined to its default value. If not that, please email me your code.

Relevant code as used. This is the version that "worked" because I changed the USLegal default to 10, but I'm confused that it worked because I also attempted to comment out that section of the /GlassesOnSheetsMaxPerSheet definition. Note inserted 'def %'. Despite that insertion, the change from /USLegal eq {pop 9} to /USLegal eq {pop 10} had an effect.

I think. To be honest, after struggling to get the placemats created for a couple of hours (off and on while also working), I can't be 100% certain of which steps I tried in which order. I thought it would be a simple change due to a simple mistake every time I made a change, so didn't keep track as I made them. I also reverted to a clean copy of the software on more than one occasion to ensure that I hadn't accidentally totally mucked things up at some point.

% % % % % % % % % % % % % % % % % % % % % % %
% Page Organisation and Page-Level Features %
% % % % % % % % % % % % % % % % % % % % % % %

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

/GlassesOnSheetsMaxPerTNSheet GlassesOnSheetsMaxPerSheet dup 8 gt {pop 6} if def % 8 gives per page leaves just enough writing space.
/GlassesOnTastingNotePages [ % Consider "/GlassesOnTastingNotePages GlassesOnSheets def"
<< /p Titles length GlassesOnSheetsMaxPerTNSheet 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 % /GlassesOnTastingNotePages

[oscar quevedo]

Thank you Julian, I've made my first placemts! It is possible

[jdaw1]

Thank you Julian, I've made my first placemts! It is possible

And thank you for also mentioning it in a tweet.

[Glenn E.]

Thank you Julian, I've made my first placemts! It is possible

Don't let my struggles this time around mislead you. I use Julian's software for most of the tastings I do and it's great!

[jdaw1]

Bug: /GlassesOnSheetsMaxPerSheet 999 def does not have the desired effect when /PaperType /USLegal def. Instead, it appears to revert to the default for /GlassesOnSheetsMaxPerSheet for that paper type, which is 9.

Works for me, as I have replaced the default definition with that in your subsequent post.

I suspect that you are doing /GlassesOnSheetsMaxPerSheet 999 def, without having deleted the usual definition of GlassesOnSheetsMaxPerSheet, which is therefore redefined to its default value. If not that, please email me your code.

Still seems likely to me.

Please email your whole PS.

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

Done: +PackingNestingColumnMajor.

[Glenn E.]

Sent. Though in writing the email I believe I figured out where my comprehension of the code was failing. I was less than precise in previous posts, not understanding that the lack of precision was in fact the cause of my lack of comprehension.

/GlassesOnSheetsMaxPerSheet 999 def does in fact work exactly as desired.

/GlassesOnSheetsMaxPerSheet 999 def % /PaperType load dup /A3 eq exch /USL2 eq or {pop 13} if /PaperType load /USLegal eq {pop 10} if def does also because the '%' comments out the rest of the line.

/GlassesOnSheetsMaxPerSheet 999 /PaperType load dup /A3 eq exch /USL2 eq or {pop 13} if /PaperType load /USLegal eq {pop 10} if def does not work like I thought it was going to work because I didn't understand that the rest of the line was overriding the '999' I'd inserted when the paper type was set to A3, USL2, or USLegal. I thought that the '999' would set the default for all paper types because it was larger than 13 (for A3 and USL2) and 9 (for USLegal).

[Glenn E.]

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.

Done: +PackingNestingColumnMajor.

Am I correct to understand that the previous discussion's /PackingNestingOrder /ColumnsthenRows def is now performed by PackingNestingColumnMajor /True def?

That and the two /PackingDirection parameters are wonderfully useful. Thank you.

[jdaw1]

Am I correct to understand that the previous discussion's /PackingNestingOrder /ColumnsthenRows def is now performed by PackingNestingColumnMajor /True def?

Actually /PackingNestingColumnMajor true def.

[jdaw1]

Sent. !

/GlassesOnSheetsMaxPerSheet 999 def does in fact work exactly as desired.

It seems, from this and by email, that everybody is now happy.

[jdaw1]

How could PermittedPackingStyles be generalised?

The Malvedos blog has an article about a tasting of the 2011 ports, in which placemats had circles set in a pleasant semi-ellipse. Cynthia kindly responded to my request for a clearer picture.


Naturally, I could make /SemiEllipse a valid item in PermittedPackingStyles. Sure.

And there should be an upside down version, /SemiEllipseMirror. And there should be a version with one extra glass in the centre of the empty long edge (/SemiEllipsePlus1, /SemiEllipseMirrorPlus1), and with two such glasses side by side (/SemiEllipsePlus2, /SemiEllipseMirrorPlus2), and one with three in a triangle (/SemiEllipsePlus3, /SemiEllipseMirrorPlus3). Clunkytastic.

Indeed, this problem already exists:
• /PseudoHexagonal and /PseudoHexagonalMirror;
• /RectangularDislocation and /RectangularDislocationV;
• /RectangularAlternateNudge and /RectangularAlternateNudgeMirror and /RectangularAlternateNudgeIf2pt and /RectangularAlternateNudgeIf2ptMirror;
• /Irregular and /IrregularMirror and /IrregularPortrait and /IrregularLandscape and /IrregularMirrorPortrait and /IrregularMirrorLandscape;
• and, further, /Gaia and /GaiaElegant should acquire !Plusn variants.

PermittedPackingStyles should be generalised. But how? That is, how could a style set be parameterised?

I think the simplest way is to allow array entries. So valid items of PermittedPackingStyles might include (with some non-code punctuation suppressed for legibility):
â—Š /SemiEllipse
â—Š [ /SemiEllipse ]
â—Š [ /SemiEllipse /Mirror ]
â—Š [ /SemiEllipse /Mirror 0 ]
â—Š [ /SemiEllipse /Mirror 3 ]

An alternative would be to have extra parameters of the likes of PermittedPackingStylesMirrored and PermittedPackingStylesExtras. These arrays would have to be the same length as PermittedPackingStyles, with corresponding items in the same position.

Please could members of the Taylor ’77 Working Group reply with thoughts and preferences.

[PhilW]

Please could members of the Taylor ’77 Working Group reply with thoughts and preferences.

I think we need more Taylor '77, although I'd prefer some Fonseca '77...

oh, ok then... I would note that some of the modifiers (mirror, invert, rotate) could be post-layout applied, some could not (plus1, plus2, other variants). These could therefore be applied separately, by first definining a basePackingStyle array comprising the variants without translation, and then allow translation-only modifiers on these to form the permitted packing styles, e.g.

basePackingStyles
â—Š [ /SemiEllipse ]
â—Š [ /SemiEllipse /plus1 ]
â—Š [ /SemiEllipse /plus2 ]
...

permittedPackingStyles
â—Š [ /basePackingStyles ]
â—Š [ /basePackingStyles /mirror ]
â—Š [ /basePackingStyles /invert ]
â—Š [ /basePackingStyles /rotate_90 ]
...

Excuse the imprecise syntax, but hopefully the idea/intent is clear. however, this would only be a good solution if the code would be able/wanted to support all translation variations for all basePackingStles. If you prefer to restrict the translations to a subset available per basePackingStyle, then the single array defining all possible combinations as per your post would seem like the better approach.

[jdaw1]

if the code would be able/wanted to support all translation variations for all basePackingStles

Well, the user might want the code to choose the better (the larger radius) of base style X unmirrored, or base style Y mirrored. Which I don’t think your allows. Or I’ve misunderstood.

Also keep in mind that users range from weapon-grade geek to those who rarely, if ever, write a line of code. Simplicity of use is a desideratum.

[jdaw1]

â—Š [ /SemiEllipse /Mirror 3 ]

â—Š [ /SemiEllipse /plus2 ]

Just noticed this clash. As words in the PostScript language are lower case, my parameters are in CamelCase. So /Plus2 fits my style better than /plus2. But PhilW is correct about not using an unadorned integer, which might have multiple meanings, and in this context, must be ≤3.

The current code includes

Code: Select all

/RowsMinNum 1 def
/RowsMaxNum 65535 def

This is applying at the wrong level. But there is a large range of possible row numbers.

Which suggests, despite the upper bound of 3 on the /Plus’ness, we should allow the likes of:
◊ [ /PseudoHexagonal   /MinRows 3   /MaxRows 5   /Mirror ]
◊ [ /SemiEllipse   /ExtraCircles 2   /Mirror ]
Then the row control can be different for different base styles; and each style can be parameterised as suitable.

Again I ask, please could members of the T77WG reply with thoughts and preferences.

[jdaw1]

Slight change of mind again.

The first parameter of the array is the base class. After that things come in pairs, being the sub-parameter and its new value. So allowed items of PermittedPackingStyles include:
◊ [ /PseudoHexagonal   /MinRows 3   /MaxRows 5   /Mirror true ]
◊ [ /SemiEllipse   /ExtraCircles 2   /Mirror true ]

Hence items of PermittedPackingStyles are either /names, or arrays of odd length with the first and even-number items (starting at 1) being /names. Objections?

(Next post on next page: please help the reader by starting with a concise quote.)

[DRT]

How could PermittedPackingStyles be generalised?

The first parameter of the array is the base class. After that things come in pairs, being the sub-parameter and its new value. So allowed items of PermittedPackingStyles include:
â—Š [ /PseudoHexagonal /MinRows 3 /MaxRows 5 /Mirror true ]
â—Š [ /SemiEllipse /ExtraCircles 2 /Mirror true ]

Hence items of PermittedPackingStyles are either /names, or arrays of odd length with the first and even-number items (starting at 1) being /names. Objections?

None.

[PhilW]

◊ [ /PseudoHexagonal   /MinRows 3   /MaxRows 5   /Mirror true ]
◊ [ /SemiEllipse   /ExtraCircles 2   /Mirror true ]
Hence items of PermittedPackingStyles are either /names, or arrays of odd length with the first and even-number items (starting at 1) being /names. Objections?

No objection, just one alternative; each additional parameter could be in its own array, i.e.
â—Š [ /PseudoHexagonal [/MinRows 3] [/MaxRows 5] [/Mirror true] ]
â—Š [ /SemiEllipse [/ExtraCircles 2] [/Mirror true] ]
The reason for the suggestion is that this would allow for modifiers with either no parameters such as [/Mirror] and for more than one parameter [/Wibble 17 29] which might provide for more flexibility in the future.

[jdaw1]

The reason for the suggestion is that this would allow for modifiers with either no parameters such as [/Mirror] and for more than one parameter [/Wibble 17 29] which might provide for more flexibility in the future.

Hmmm. So PermittedPackingStyles becomes a triple-depth array. That won’t confuse anybody.

Compromise:
[ /BaseStyle   /WibbleOneParam 99   /OtherWibbleOneParam [99]   /WibbleTwoParam [ 98 99 ] ]
So parentheses optional for one-sub-param parameters, mandatory for ≥2.

[PhilW]

The reason for the suggestion is that this would allow for modifiers with either no parameters such as [/Mirror] and for more than one parameter [/Wibble 17 29] which might provide for more flexibility in the future.

Hmmm. So PermittedPackingStyles becomes a triple-depth array. That won’t confuse anybody.

Compromise:
[ /BaseStyle   /WibbleOneParam 99   /OtherWibbleOneParam [99]   /WibbleTwoParam [ 98 99 ] ]
So parentheses optional for one-sub-param parameters, mandatory for ≥2.

Note that the suggested compromise, while facilitating the 2+ param case (which we may or may not need at some future point) loses the potential benefit for simplicity of the [/WibbleNoParam] case (which we would use).

[jdaw1]

Still being indecisive about the extra layer of arrays.

Meanwhile, the following all apply globally:

Code: Select all

/NamesAtTop false def
/RowsMinNum 1 def
/RowsMaxNum 65535 def

/PackingDirectionVertical /TopToBottom def  % /TopToBottom /BottomToTop
/PackingDirectionHorizontal /LeftToRight def  % /LeftToRight /RightToLeft
/PackingNestingColumnMajor false def

Should they become sub-parameters of the individual base-styles? For RowsMinNum and RowsMaxNum, definitely. For NamesAtTop, hmm. Maybe? (The glass arrangement code also calculates the x position of the name, if top and if bottom.) Then PackingDirectionVertical, PackingDirectionHorizontal, and PackingNestingColumnMajor: I think yes.

[jdaw1]

Different question to those about PermittedPackingStyles.

Daniel, the newest member of the Placemat makers group, has remarked by email that he ‟can't find how to make the 'Wine of the Night' and 'What is it?' TopText smaller”. Indeed, this is because the size is embedded in the code, rather than being a parameter.

There are at least three possible courses of action.
• No change, keeping the text height at one fortieth of the non-margin page height.
• Change the constant embedded in the code, perhaps to one sixty-fourth of the non-margin page height (that being ⅝ = 62½% of the current size).
• Add another parameter, allowing the user to change this height. But I’m the most aggressive user of obscure parameters, and have never needed this.

Preferences? Thoughts?

[djewesbury]

Option 2, I think. We don't need access to this feature, it's a one-off change. Can you post before / after grabs though?

[jdaw1]

Can you post before / after grabs though?

See www.jdawiseman.com/2013/20130512_TopTextHeight_Test.pdf, from which three extracts follow.







I prefer the largest, the original, but with sufficiently little certainty to be willing to follow the majority, or even a lone strongly-held opinion.

[djewesbury]

I see that I have missed the parameter that rotates names 180º. This makes your PDF look much less crowded than mine. I will return to the drawing board now and see what findings I produce.

[djewesbury]

I cannot find the parameter that controls this (orientation of names at top of VotingRecorder columns)...

[jdaw1]

I cannot find the parameter that controls this (orientation of names at top of VotingRecorder columns)...

No such parameter (again!), as it is automatic, being determined by the length of the longest name, the number of glasses, the width of most columns, the page height, and the like. If you need to know the full logic (recommendation: you don’t) ⌘F in the code for ‟VoteRecorderColWidth VoteRecorderHeightFirstRow 0.875 mul gt” and read the ¶s above and below.

[djewesbury]

Fiendish. Well in that case I have a feeling that your middle option, one fiftieth, makes my page tidier. We are not comparing like with like however. Your oranges look better than my apples, but I have just decanted a D80 and it smells very nicely of bananas.

[PhilW]

Still being indecisive about the extra layer of arrays.

Meanwhile, the following all apply globally:
<snipped>
Should they become sub-parameters of the individual base-styles? For RowsMinNum and RowsMaxNum, definitely. For NamesAtTop, hmm. Maybe? (The glass arrangement code also calculates the x position of the name, if top and if bottom.) Then PackingDirectionVertical, PackingDirectionHorizontal, and PackingNestingColumnMajor: I think yes.

Yes to all except /NamesAtTop - this seems more of a page setting than a packing style parameter to me.

Daniel, the newest member of the Placemat makers group, has remarked by email that he ‟can't find how to make the 'Wine of the Night' and 'What is it?' TopText smaller”. Indeed, this is because the size is embedded in the code, rather than being a parameter.

There are at least three possible courses of action.
• No change, keeping the text height at one fortieth of the non-margin page height.
• Change the constant embedded in the code, perhaps to one sixty-fourth of the non-margin page height (that being ⅝ = 62½% of the current size).
• Add another parameter, allowing the user to change this height. But I’m the most aggressive user of obscure parameters, and have never needed this.
Preferences? Thoughts?

Preference for automatic rather than parameter unless necessary. Happy with any considered size variant.

Additional issue noted from Daniel's draft placemats; If the wine names are very short ("1", "2" etc in this case) then the text in top left corner of WOTN and other voting sheets which says "Record points, not rank" can become very compressed (see Daniel's draft). Suggest this should be (a) on two rows, and (b) if column is so narrow that the point size becomes too small, should perhaps be rotated?

[jdaw1]

The current ‟40 div” is used for the page heading of vote-recorder, cork-display and decanting-notes pages. If I’m changing one, I’d prefer to change all. Objections?

[jdaw1]

Yes to all except /NamesAtTop - this seems more of a page setting than a packing style parameter to me.

Agreed.

Preference for automatic rather than parameter unless necessary. Happy with any considered size variant.

Agreed. It’s looking like dropping 20% of its linear size, so becoming ‟50 div”.

Additional issue noted from Daniel's draft placemats; If the wine names are very short ("1", "2" etc in this case) then the text in top left corner of WOTN and other voting sheets which says "Record points, not rank" can become very compressed (see Daniel's draft). Suggest this should be (a) on two rows, and (b) if column is so narrow that the point size becomes too small, should perhaps be rotated?

Splendid observation. Failing cogent objection, I’ll rotate the text if the cell’s width is less than â…ž of the height (thus embedding a gentle preference for non-rotated). Doing two rows would be some coding fuss I have not coded routines that insert line breaks, and this isn’t enough motivation to start.

[djewesbury]

Agree with all. I noticed the tiny type but it was too low town on my list!
Ah, labour-saving...

[jdaw1]

Done 40 div → 50 div.

Rotation of VoteRecorderInstruction to follow soon.

• Edit: done.

Larger work on PermittedPackingStyles to follow subsequently.

[jdaw1]

OK, a decision has been reached on the new format for items of PermittedPackingStyles.

If all the sub-parameters are at their default value, then it can be the name of the base style. E.g., ‟/TopRow”.

or it can be an array, containing sub-parameters, Base styles have settings than can be changed. Each setting is a name, followed by a fixed number of values. E.g., /Mirror takes no values; /RowsNumMin and /RowsNumMax each take one, a positive integer; /OnlyIfOrientation takes one, either /Landscape or /Portrait; /ImprovementPointsMin takes one non-negative real; /PackingDirectionTopToBottom, /PackingDirectionLeftToRight, and /PackingNestingColumnMajor each take a single boolean.

So a valid item of PermittedPackingStyles could be:
[ /Diamonds   /PackingNestingColumnMajor true   /Mirror   /RowsNumMin 4 ]

[djewesbury]

Is there an update at jdawiseman.com?

[jdaw1]

Is there an update at jdawiseman.com?

There often is. Line 6 of the code is the version date.

Code: Select all

% This version as of 21:30 Sunday 12th May 2013

That fixes the vote-recorder font-size issue, but not yet the PermittedPackingStyles changes.

[jdaw1]

OK, a decision has been reached on the new format for items of PermittedPackingStyles.

If all the sub-parameters are at their default value, then it can be the name of the base style. E.g., ‟/TopRow”.

or it can be an array, containing sub-parameters, Base styles have settings than can be changed. Each setting is a name, followed by a fixed number of values. E.g., /Mirror takes no values; /RowsNumMin and /RowsNumMax each take one, a positive integer; /OnlyIfOrientation takes one, either /Landscape or /Portrait; /ImprovementPointsMin takes one non-negative real; /PackingDirectionTopToBottom, /PackingDirectionLeftToRight, and /PackingNestingColumnMajor each take a single boolean.

So a valid item of PermittedPackingStyles could be:
[ /Diamonds   /PackingNestingColumnMajor true   /Mirror   /RowsNumMin 4 ]

One slight issue, when the user specifies an array. E.g., in the old formulation, the user could specify ‟[ [0 2] [2 2 3 2] [4 2 3 2] [6 2]   [0 1] [3 1] [6 1]   [0 0] [3 0] [6 0] ]”.

Could now become ‟[ /Array   /OnlyIfOrientation /Landscape   /ImprovementPointsMin 2   /Positions [0 2] [2 2 3 2] [4 2 3 2] [6 2]   [0 1] [3 1] [6 1]   [0 0] [3 0] [6 0] ]”?

[Glenn E.]

In the past, I could swear that I have printed 10 glasses on 8.5" x 14" /USLegal paper and received a PseudoHexagonal pattern of 3 rows, with the rows containing 3, 4, and 3 glasses.

When I attempt to repeat this memory, I receive a PseudoHexagonal pattern of 4 rows, with the rows containing 3, 2, 3, and 2 glasses (top to bottom).

Has something changed in the software that might have affected the arrangement of 10 glasses on /USLegal, or is my memory faulty?

[jdaw1]

I’ve slightly shrunk the default margins, from 36 pt = to 30 pt, which might have that effect. Let me test.

Edit: no. Could it be 8 glasses rather than 10, and /RectangularAlternateNudgeIf2pt (a recently constructed base style) rather than /PseudoHexagonal?

[Glenn E.]

I’ve slightly shrunk the default margins, from 36 pt = to 30 pt, which might have that effect. Let me test.

Edit: no. Could it be 8 glasses rather than 10, and /RectangularAlternateNudgeIf2pt (a recently constructed base style) rather than /PseudoHexagonal?

I could be mis-remembering 8 glasses in 3-2-3 arrangement. It would be from long enough ago that I doubt /RectangularAlternateNudgeIf2pt is the answer. I'll go back through my saved placemats when I get home tonight, but thought I'd ask since I'm attempting to put together another set of placemats at work today.

[jdaw1]

Also beware that PermittedPackingStyles is being changed, a new version being likely to appear soon.