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.