Software that makes placemats

[jdaw1]

• And, slightly kludged, a ‘What is it?’ page. Comment encouraged.

A way to record guesses for posterity. I'm happy to try this out on 8th August.

Please scan and upload the sheet it’s OK, you will all be rubbish, as would I if I were there and comment on the technology.

Should the "total" field in the guess recorder be a column corresponding to the wines (as currently drafted) or a row at the bottom to correspond to the drinkers? (or perhaps both, giving two totals - best guesser, most guessed)

Updated draft of the placemats.

• Kludged improvement to ‟What is it?” sheet. Comment on this would be welcomed.

What is written in the rectangles is the names of wines, abbreviated. So totalling these will be more arduous than totalling numerical scores (3 for first place; 2 for second; 1 third). Further design work probably needed.

Comment encouraged.

- Guesses are an interesting record of people's impressions of the port (see comment re: Roeda above)

- A slight concern from some that the process of gathering votes after every round got in the way of relaxed conversation. Though i would imagine that this would be less of an issue at a smaller tasting with fewer bottles.

- We are all terrible - top score was 6 points out of a possible 28 (1 point for vintage, 1 for shipper). Across all 8 people, there was only one correct guess at shipper. Scores for correct identification of vintage were no doubt flattered by the fact that we only had a choice of 10 years (or 9, discounting 1993)!

- The sheet worked well, and totalling points was not an arduous task. I had slight difficulty when drunk with recording votes in the correct columns...though this is not a criticism of the sheet itself!

- Inclusion of an extra row or two for extra ports would be good.

Note to self: there could be array parameters VoteRecorderRowTotalTitles and VoteRecorderColTotalTitles. The numbers of total rows and columns would be the length of these arrays, titled with their contents. Of course, the arrays themselves could depend on VoteRecorderSheetNum, so compelling a row in the ‘What is it?’ page but not in the ‘WOTN’ page. But that forces users doing an obvious thing to write code, which isn’t nice. Maybe these could be double-depth arrays, the outer array being of the same length as GlassesClusteredOnVoteRecorders. More complicated, but spares the ordinary user from code.

Later note to self: it’s complicated because there is too much flexibility only one total column or row is needed, so no need for the extra arrays depths that allow multiple. Instead have a non-array single piece of text, VoteRecorderTotalRowTitle and VoteRecorderTotalColTitle, both probably being (Total). Then have two arrays of booleans, of the same length as GlassesClusteredOnVoteRecorders, called VoteRecorderShowTotalRow and VoteRecorderShowTotalCol. That better captures what I actually want to do, with less needless excess.

[jdaw1]

Thank you for the comment. Code will be altered, hopefully not at lot, such that this can be a non-kludge.

- The sheet worked well, and totalling points was not an arduous task. I had slight difficulty when drunk with recording votes in the correct columns...though this is not a criticism of the sheet itself!

It wasn’t meant that way, but it is a criticism. A good user interface, which applies as much to paper as to electronic media, can be used by a drunk. Please ponder how it could be bettered. For instance, would it have helped if every fourth vertical line were thicker? Would it be worth repeating the names at the bottom of the page?

- Inclusion of an extra row or two for extra ports would be good.

That’s mildly inconvenient to do with GlassesClusteredOnVoteRecorders, but an extra integer parameter can be added.

[RAYC]

In addition to the Ryman labels, I can confirm that WH Smith's Large Self Adhesive Labels also work. Indeed, any labels expressed to be "L7165" should work - it appears to be a market standard template (at least in the UK). This may be old news to some - i have not trawled the whole thread.

I would add that 260gsm business cards are also available - if possible to programme, this strikes me as a much better alternative to scissors and glue. I would be happy to acquire and post a batch for testing.

[Glenn E.]

If this change is done, all options would be plainly visible, but not necessarily in a comment line. Does that suffice?

To me, no. As has already been pointed out, in this case the software is the user interface.

If no comment exists the natural assumption is that the code is self-explanatory. Most of this code is in fact self-explanatory, which gives the comments greater weight. If a comment is needed it must be important.

If a comment exists the natural assumption, therefore, is that it explains everything that you need to know. If the comment is read and then something not explained in the comment is discovered in the code, one wonders which is incorrect.

[jdaw1]

If this change is done, all options would be plainly visible, but not necessarily in a comment line. Does that suffice?

To me, no.

Noted. Thank you.

[DRT]

I have read all of the above with interest, but note that most of the comment comes from people who fundamentally understand how to write/read code. RAYC and I seem to be the only "users" who really are "users".

I have debated the prospect of having a proper user interface on this application many times with its creator. I have so far met with resistance. I think this conversation lends weight to my side of that debate in that I think it would be extremely useful, and would increase the number of people who could use the software, if it had a form/wizard on the front end that allowed non-code-savy users to set the parameters. There would be no need to include all of the infrequently used parameters as those could be accessed by an expert user who can edit the code. But it would be good to be able to launch a form, type in the names of a few ports and people and then hit a print button.

[jdaw1]

Writing a good wizard would be a lot of work. Writing a bad wizard would be pointless.

I am happy to co-operate with any who volunteer to write a wizard.

[jdaw1]

Vote-recorder total rows, etc: done.

[jdaw1]

To aid navigation, a document outline has been added (mark ! /OUT pdfmark). There are no parameters it should be automatically visible when opening a placemat of more than nine pages. E.g., 15 December 2011, The Unknown Shipper at the Bell and 11 October 2011, {Dow, Fonseca, Graham, Taylor} × {1963, 1966, 1970, 1977}.

[DRT]

I like the document outline but have just noticed the external links section, which is a splendid addition.

[jdaw1]

Placemats printed.

Hitherto, when placemats have been printed, they have been deemed finished the online edition being frozen at the printed version.

But with the new ExternalLinks feature, there are placemat parameters that don’t affect what prints. There would be advantages in adding to the placemats a link to the review thread, as that thread has, front and prominent, all the links one could want.

Do users object to post-printing changes to the uploaded placemats, provided that the new version would print the same as the printed version?

Please vote one of:

• ‘Purist’ (the printed version is the final version);
• ‘Near-Purist’ (later uploads must be of something that would print the same to paper);
• Other (detail).

My preference is Near-Purist, but I might be persuaded by interesting argument.

[DRT]

I vote Near-Purist, but do wonder what sort of geek would find it necessary to print a set of placemats for a tasting that had already happened.

[jdaw1]

but do wonder what sort of geek would find it necessary to print a set of placemats for a tasting that had already happened.

That’s not quite the point, I think. The online placemats are part of the record of the tasting. Records are important. (Some might recall that DRT and I are meant to be writing a book based on various records relating to port.)

To what extent can we retrospectively change this ‘record’? My view is slightly, not so much as to change the print, and only very soon after the tasting. It isn’t quite purist, but nearly so.

[DRT]

but do wonder what sort of geek would find it necessary to print a set of placemats for a tasting that had already happened.

That’s not quite the point, I think. The online placemats are part of the record of the tasting. Records are important. (Some might recall that DRT and I are meant to be writing a book based on various records relating to port.)

To what extent can we retrospectively change this ‘record’? My view is slightly, not so much as to change the print, and only very soon after the tasting. It isn’t quite purist, but nearly so.

I knew that the answer was "us"

[PhilW]

I'd vote purist, warts and all as necessary; it's the record of the event, with any notes or additional links provided in the review thread(s), rather than the corrected/updated event arrangements. Once you start adding extra helpful links, you risk incremental feature creep (links to tasting notes, WOTN scores etc); Perhaps that would only be appropriate for circumstances where you require the document to be the master record for the complete event, e.g. non-TPF use where these might be no associated forum etc?

[SushiNorth]

Purist+Other:

Purist: If the placemat is a historical document used to understand what happened at a tasting, it is important that it remains unaltered after the event. While one might only be adding links to the review, removing some embarrassing detail on the tasting sheet which caused great discussion would be too tempting. Similarly, if the website upgraded or moved, and the links changed, would we need to keep the placemat updated in perpetuity?

Other: If the placemat is not a historical document, but simply a tool we use to execute the tastings planned and recorded here on the site, then its accuracy and valuable content -- beyond the event -- is irrelevant. Are our placemats being stored and backed up? Are they ever revisited? I'd prefer that, so long as the website exists, the website be the authoritative source on what transpired at the tasting. And should the website cease to exist, the links on placemats would be useless.

[RAYC]

Don't think I understand the debate here, but:

What if a port emergency is declared at the end of the night and another bottle is added? Or there's a guest who turns up at the last minute with an extra bottle? The placemats as printed are no longer a historical record of events. Including the extra information somewhere at the back (but so that the actual placemats remain" as printed" seems neat.

[jdaw1]

Are our placemats being stored and backed up?

The British Library archives copies of jdawiseman.com. These copies are derived by following the links from the home page, and the manual links to some but not all placemats. I could add a page listing all the placemats, so that all are archived.

PhilW and SushiNorth make a powerful argument (‟would be too tempting”; ‟incremental feature creep”; etc). Are these arguments lessened by self-restraint on the part of jdaw1? Surely a bit. But are they lessened enough?

So far the score is as follows.
• Purist: 2 (SushiNorth, PhilW);
• Near-Purist: 3 (jdaw1, DRT, RAYC).
My vote was a close call, and RAYC denies understanding, so that is statistically indistinguishable from a draw.

[jdaw1]

I could add a page listing all the placemats, so that all are archived.

Done. Henceforth the British Library will find all these.

[SushiNorth]

I could add a page listing all the placemats, so that all are archived.

Done. Henceforth the British Library will find all these.

Is this list intended to include all TPF Tastings, and if so would it be useful to DL the ones that we've done in NYC for inclusion in that archive?

[jdaw1]

Is this list intended to include all TPF Tastings, and if so would it be useful to DL the ones that we've done in NYC for inclusion in that archive?

If not on a ‘British’ website that the BL archives, it would retain the links but not archive the content.

I intended it to be for placemats made by me and held at www.jdawiseman.com. Maybe that could be expanded.

[jdaw1]

During the tasting on Tue 11 Oct 2011, five changes to the software were requested.

• At DRT’s request, HeaderRightText no longer depends on any other parameters, making it easier to move it to the top.
• Based on a suggestion of PhilW, BackgroundTextsGlassesPaintCode changed from 25% black to 6¼% black.  
• When RAYC prints, he prints the placenames to card. This is stiff enough to require one fold rather than three, so PlaceNamesFirstAndThirdFoldsFromEdge should be set to zero. I promised to add a feature that checked this parameter’s equality to zero, and if so, not to print the lines and instructions. Except that this was already being checked in just this manner. So, no change to software required. But note to self: if RAYC is to print then set /PlaceNamesFirstAndThirdFoldsFromEdge 0 def.
• I noticed that the ‘which shipper’ sheet still had the instruction ‟Record points, not rank.” These words have been moved to the parameter VoteRecorderInstruction.
• RAYC requested a sheet on which corks and cork fragments could be put, both for photography and for observation by others. This has not yet been done, whilst I ponder the range of variations that might be wanted.

And a bonus:

• All placemats now include a link to this thread.

[PhilW]

[*]Based on a suggestion of PhilW, BackgroundTextsGlassesPaintCode changed from 25% black to 6¼% black.

I would also suggest reducing their overall (font) size to 80% of current, and either increasing the line width by 40% or possible solid filling the characters (at 6.25 or 5%)

[jdaw1]

increasing the line width by 40%

Increased by a factor of 1.5.

[jdaw1]

• RAYC requested a sheet on which corks and cork fragments could be put, both for photography and for observation by others. This has not yet been done, whilst I ponder the range of variations that might be wanted.

I think that parameters needed are as follows:

• /CorkDisplay true def, saying whether or not to bother.
• /GlassesClusteredOnCorkDisplay GlassesClusteredOnDecantingNotes def, saying which glasses go there;
• CorkDisplayMinWidth and CorkDisplayMinHeight, being minimum sizes.

Then the code works out how many can go on each sheet. Each is a rectangle, surrounded by the Circlearrays text, very small, and containing, larger but not very large, the various title-like texts. Sheets would be discretely titled ‟The Corks”.

Does that work?

[RAYC]

• RAYC requested a sheet on which corks and cork fragments could be put, both for photography and for observation by others. This has not yet been done, whilst I ponder the range of variations that might be wanted.

I think that parameters needed are as follows:

• /CorkDisplay true def, saying whether or not to bother.
• /GlassesClusteredOnCorkDisplay GlassesClusteredOnDecantingNotes def, saying which glasses go there;
• CorkDisplayMinWidth and CorkDisplayMinHeight, being minimum sizes.

Then the code works out how many can go on each sheet. Each is a rectangle, surrounded by the Circlearrays text, very small, and containing, larger but not very large, the various title-like texts. Sheets would be discretely titled ‟The Corks”.

Does that work?

Sounds great - if it's ready in time, i can try next month for the GC-SW-QH tasting. But i appreciate this is non-essential!

[jdaw1]

• RAYC requested a sheet on which corks and cork fragments could be put, both for photography and for observation by others. This has not yet been done, whilst I ponder the range of variations that might be wanted.

Work has started. This work has revealed that the same chunk of code, with very small changes, appears four times in the current version. It is being wrapped into a sub-routine, perhaps to be called CirclearrayInStraightLine, to do the same a little better. This will result in a minor improvement to the tasting-note pages, as well as being used in cork-display pages. Rejoice!

[PhilW]

The value "/NonDecanterLabelGlassesNumCopies 1 def" appears a few lines below the comment "% Non-Glasses Pages %". Changing this value to zero appears to stop the glasses pages from being printed. Is this as intended, or what is this variable intended to control?

Also, perhaps a trivial detail but - is there a setting to define the width of any exclusion area on the glasses sheets between the outer ring of text as defined by circlearrays and the inner text defined by titles, belowtitles? In a couple of cases experimenting I found that the inner text can (virtually) meet the outer, and therefore by allowing optionally configurable decrease of the effective inner circle size (in which the title/belowtitle are sized and placed) by a small degree (say <=5%, configurable, or a fixed amount e.g. 1mm) might help clarity?

On a PC the specification of NotePad++ looks encouraging user feedback welcomed

I use Notepad++ daily and find it is an excellent context-sensitive-highlighting text editor for use with many languages including postscript (though I hadn't used it for that particular language before today, I use it for several others regularly); highly recommended.

[jdaw1]

The value "/NonDecanterLabelGlassesNumCopies 1 def" appears a few lines below the comment "% Non-Glasses Pages %". Changing this value to zero appears to stop the glasses pages from being printed. Is this as intended, or what is this variable intended to control?

This might be slightly mis-placed, but does what it seems to do. Why, oh why? Because several page types, including decanter labels and pre-pour and sticky-labels, contain extracts from the glasses pages. If there are no glasses pages, there cannot be sticky labels. But what if!? Then have glasses pages, and show 0 copies of them.

Also, perhaps a trivial detail but - is there a setting to define the width of any exclusion area on the glasses sheets between the outer ring of text as defined by circlearrays and the inner text defined by titles, belowtitles? In a couple of cases experimenting I found that the inner text can (virtually) meet the outer, and therefore by allowing optionally configurable decrease of the effective inner circle size (in which the title/belowtitle are sized and placed) by a small degree (say <=5%, configurable, or a fixed amount e.g. 1mm) might help clarity?

They can indeed touch. Such a parameter could be added, though I think it should be expressed a proportion of one of the radii (Radii, RadiiCirclearrayBaseline, or RadiiCirclearrayInside). Suggest a name for the parameter. (Edit: though the boundaries of the Titles etc are separately constrained if there are decanter labels, and of course common sizing will also shrink some.)

On a PC the specification of NotePad++ looks encouraging user feedback welcomed

I use Notepad++ daily and find it is an excellent context-sensitive-highlighting text editor for use with many languages including postscript (though I hadn't used it for that particular language before today, I use it for several others regularly); highly recommended.

Thank you: manual updated.

[PhilW]

The value "/NonDecanterLabelGlassesNumCopies 1 def" appears a few lines below the comment "% Non-Glasses Pages %". Changing this value to zero appears to stop the glasses pages from being printed. Is this as intended, or what is this variable intended to control?

This might be slightly mis-placed, but does what it seems to do. Why, oh why? Because several page types, including decanter labels and pre-pour and sticky-labels, contain extracts from the glasses pages. If there are no glasses pages, there cannot be sticky labels. But what if!? Then have glasses pages, and show 0 copies of them.

In that case I wouldn't suggest it was mis-placed, but perhaps a change of name to something like "/InhibitGlassesPagePrinting" for clarity?

Also, perhaps a trivial detail but - is there a setting to define the width of any exclusion area on the glasses sheets between the outer ring of text as defined by circlearrays and the inner text defined by titles, belowtitles? In a couple of cases experimenting I found that the inner text can (virtually) meet the outer, and therefore by allowing optionally configurable decrease of the effective inner circle size (in which the title/belowtitle are sized and placed) by a small degree (say <=5%, configurable, or a fixed amount e.g. 1mm) might help clarity?

They can indeed touch. Such a parameter could be added, though I think it should be expressed a proportion of one of the radii (Radii, RadiiCirclearrayBaseline, or RadiiCirclearrayInside). Suggest a name for the parameter. (Edit: though the boundaries of the Titles etc are separately constrained if there are decanter labels, and of course common sizing will also shrink some.)

If I've understood the current variables correctly - Radii being the radius to the outside of the circlearray text, and RadiiCircleArrayInside to be the radius to the inside of the circlearray text - then I'd suggest RadiiCirclearrayInsideMargin with default either zero (to print as current) or 0.025 (to provide a 2.5% (radially) gap).

[jdaw1]

In that case I wouldn't suggest it was mis-placed, but perhaps a change of name to something like "/InhibitGlassesPagePrinting" for clarity?

Good clarity (though elsewhere I have used !Suppress!); but removes the ≥2 functionality. For what would one want the ≥2 functionality? Hmmm. Not sure. Perhaps for a tasting on a train, in which spillage is expected and substitutions desired? Hmmm.

If I've understood the current variables correctly - Radii being the radius to the outside of the circlearray text, and RadiiCircleArrayInside to be the radius to the inside of the circlearray text - then I'd suggest RadiiCirclearrayInsideMargin with default either zero (to print as current) or 0.025 (to provide a 2.5% (radially) gap).

You have understood, though the name might need to be nearer to the rather horrible TitlesEtcInsideMarginProportionRadiiCirclearrayInside.

[Alex Bridgeman]

Oh no! More of a thread that might as well be written in Greek for all my understanding.

Perhaps I should reactivate the thread on the technicalities of cricket...

[jdaw1]

You should delight that, at no effort to yourself, TPF’s finest minds are keeping me in check. Express joy.

[Alex Bridgeman]

You should delight that, at no effort to yourself, TPF’s finest minds are keeping me in check. Express joy.

This is true. I apologise for my earlier, churlish comment. My thanks and appreciation go to those able to contribute meaningfully to this thread and keep Julian challenged and in check.

[Alex Bridgeman]

You should delight that, at no effort to yourself, TPF’s finest minds are keeping me in check. Express joy.

This is true. I apologise for my earlier, churlish comment. My thanks and appreciation go to those able to contribute meaningfully to this thread and keep Julian challenged and in check.

I raise a glass of port to the good health of you all. Cheers!

[jdaw1]

In a sheet for displaying corks, what should be the default minimum space required per cork? Three inches across? And how much vertical space? (The algorithm will be efficient about space usage, but the minima are important.)

[jdaw1]

if it's ready in time, i can try next month for the GC-SW-QH tasting. But i appreciate this is non-essential!

Updated draft of the placemats.

• +Cork display sheets, as requested.

The manual has not yet been updated, but will be soon.

I hope that people appreciate that this functionality diminished my cellar by a very fine bottle of T77. The sacrifices one makes.

[jdaw1]

The manual has not yet been updated, but will be soon.

Some minor fixes to the new code, and manual updated. Please use the latest code.

[RAYC]

I hope that people appreciate that this functionality diminished my cellar by a very fine bottle of T77. The sacrifices one makes.

Probably not as much as you appreciated it!

[jdaw1]

I have an algorithm problem.

We need a known number of cork-display rectangles, this being computed using CorkDisplayNumCopies and CorkDisplaySpaceForNumExtras. We need to compute how many rows and columns go on each page, subject to CorkDisplayMinWidth and CorkDisplayMinHeight.

So the code loops over /Portrait and /Landscape, computing available space, and loop over numbers of rows and columns:
• Preferring possibilities that meet the CorkDisplayMinWidth and CorkDisplayMinHeight constraints.
• Within those, preferring those requiring as few pages as possible.
• Within those, preferring those for which each rectangle has maximal area.

It’s not bad, but the area preference is wrong, because it has no bias towards rectangles being of the ratio implied by the minima (tall and thin being unhelpful, for example). So, relabelling the minima as H and W, both positive, I want to maximise over positive h and w a function f[h,w,H,W] satisfying:
• f[h,w,H,W] = f[w,h,W,H];
• ∂f[h,w,H,W]/∂h > 0;
• ∂f[h,w,H,W]/∂w > 0;
• w/W > h/H ⇔ ∂f[h,w,H,W]/∂h > ∂f[h,w,H,W]/∂w, equality implying equality.
What should be f[!]? I’m stumped. Suggestions please.

[RAYC]

I have an algorithm problem.

We need a known number of cork-display rectangles, this being computed using CorkDisplayNumCopies and CorkDisplaySpaceForNumExtras. We need to compute how many rows and columns go on each page, subject to CorkDisplayMinWidth and CorkDisplayMinHeight.

So the code loops over /Portrait and /Landscape, computing available space, and loop over numbers of rows and columns:
• Preferring possibilities that meet the CorkDisplayMinWidth and CorkDisplayMinHeight constraints.
• Within those, preferring those requiring as few pages as possible.
• Within those, preferring those for which each rectangle has maximal area.

It’s not bad, but the area preference is wrong, because it has no bias towards rectangles being of the ratio implied by the minima (tall and thin being unhelpful, for example). So, relabelling the minima as H and W, both positive, I want to maximise over positive h and w a function f[h,w,H,W] satisfying:
• f[h,w,H,W] = f[w,h,W,H];
• ∂f[h,w,H,W]/∂h > 0;
• ∂f[h,w,H,W]/∂w > 0;
• w/W > h/H ⇔ ∂f[h,w,H,W]/∂h > ∂f[h,w,H,W]/∂w, equality implying equality.
What should be f[!]? I’m stumped. Suggestions please.

I suggest the formation of a working group chaired by AHB

[PhilW]

What should be f[!]? I’m stumped. Suggestions please.

Perhaps:
f(h,w)=wh/(ah+bw) for all h>=H,w>=W else 0 (invalid)
where a,b are positive constants essentially defining the ideal ratio; a>b, perhaps a=kb where k>1.0, likely ~2.

[Alex Bridgeman]

I suggest the formation of a working group chaired by AHB

I would be delighted to chair such a group, hereby known as the Taylor '77 Working Group.

[jdaw1]

An opening question for the Taylor 1977 Working Group (‘T77WG’?):

In a sheet for displaying corks, what should be the default minimum space required per cork? Three inches across? And how much vertical space? (The algorithm will be efficient about space usage, but the minima are important.)

We need the help of somebody who is expert in the handling of broken corks.

[Alex Bridgeman]

My suggestion would be to use a minimum length of 3 inches and a minimum width of 2 inches. These dimensions should allow all pieces of a fragmented cork to be reasonably contained in the rectangle.

[jdaw1]

So you prefer a portrait display to landscape? I am surprised.

[jdaw1]

f(h,w)=wh/(ah+bw)

An excellent form. It doesn’t quote solve the problem as asked, but if one is instead differentiating with respect to Ln[h] and Ln[w], so considering proportionate increases, it works well.

f[h,w,H,W] = h w /( W h + H w ), or ”“1 if the denominator is ≤0.

This is increasing in both h and w. It can be rearranged to be a constant times a function of (h/H) and (w/W), and is faster increasing in the smaller of these.

Thank you. To be implemented at the next opportunity.

[Alex Bridgeman]

So you prefer a portrait display to landscape? I am surprised.

I've mentally tried both layouts and while I don't feel very strongly one way or the other, I did find myself naturally holding a sheet of A4 in portrait form as the more natural form. However, i do accept that others may feel more strongly inclined to the landscape format.

[jdaw1]

Think not of the paper, but of the rectangle to hold the cork or cork pieces. That rectangle could be landscape, even on a portrait page (e.g., two columns and four rows). Should the rectangle be portrait or landscape?

[PhilW]

f(h,w)=wh/(ah+bw)

An excellent form. It doesn’t quote solve the problem as asked, but if one is instead differentiating with respect to Ln[h] and Ln[w], so considering proportionate increases, it works well.

f[h,w,H,W] = h w /( W h + H w ), or ”“1 if the denominator is ≤0.

This is increasing in both h and w. It can be rearranged to be a constant times a function of (h/H) and (w/W), and is faster increasing in the smaller of these.

Thank you. To be implemented at the next opportunity.

Minor note
f[h,w,H,W] = h w /( W h + aH w )
where a>0 (or scaled by rearrangement) would allow for the optimum proportion being potentially different from the ratio of the minimum values.

Think not of the paper, but of the rectangle to hold the cork or cork pieces. That rectangle could be landscape, even on a portrait page (e.g., two columns and four rows). Should the rectangle be portrait or landscape?

I'd suggest landscape rectangles for preference, whether page is landscape or portrait.