Software that makes placemats

[Glenn E.]

Does anyone know, without resorting to significant effort, how many glasses the software can reasonably place on a 11" x 17" placemat?

I have done 11 glasses on standard US Letter (8.5" x 11") and that was fine. That leads me to believe that it might be possible to squeeze 4 rows of 6 glasses each onto an 11" x 17" placemat. Has anyone done that before?

[jdaw1]

There are separate pages describing: the choosing of the page size

• North American paper sizes:
  • !
  • 12→16: either split over multiple sheets of /USL, or /USL2 = US Ledger = 11″×17″

I have done 11 glasses on standard US Letter (8.5" x 11") and that was fine.

Eleven?! That's way too tight for glasses that aren't thimbles. You sure that wasn’t US Legal? For the Crusting Pipe glasses I now have a maximum of six on A4. Anyway, many such questions are answered by the following diagram.

[Glenn E.]

Eleven?! That's way too tight for glasses that aren't thimbles. You sure that wasn’t US Legal? For the Crusting Pipe glasses I now have a maximum of six on A4.

Hmm. That's possible, I guess. I'd have to pull it up (at home) to be sure. As I recall it was tight, but not so tight that the glasses were touching or even too close to pick up.

Thanks for the chart - that answers all of my questions nicely.

[jdaw1]

We tried the opacity test, from two different laser printers. The printers were too different, but both useless. Good experiment; bad result. Scrapped.

Opacity conversation continued in thread entitled Quantifying opacity in TNs.

[jdaw1]

For blind-tasting ‟What is it?” voting, typically the person who brought a bottle should not guess. Rectangles can be crossed out by setting VoteRecorderCrossedBox to code evaluating to a boolean, that code typically referring to WithinTitles and NameNum.

[RAYC]

Does this easily allow for occasions where one person brings blind bottles for him/herself but also for adoption by others (where that person obviously knows the identity of all bottles he/she is providing but the adopters know only the price they are paying and not the wine itself)?

[jdaw1]

VoteRecorderCrossedBox is code returning a boolean. Code can return true for any desired combination values of WithinTitles and NameNum. So it allows for any such occasion. Whether or not easily, hmmm, you tell me what form of parameters would be both flexible and easy?

[RAYC]

The fact that it allows is sufficient.

If it is not "easy" (by the standards of a non-programmer following your instructions), i would suggest that the default should be that crosses are not included (which is indeed already the case if i understand your post correctly).

[jdaw1]

Correct. Default is as-was.

[jdaw1]

Default slightly changed. Now true if the title = the name (e.g., bottle called ‟JDAW”, person called ‟JDAW”).

First draft of the placemats.

• Observe use of the VoteRecorderCrossedBox feature.

[jdaw1]

Readers might wish to comment on a putative new policy. I intend to post, near the end of each tasting’s arrangement thread, the changed parameters. So this might be fifty lines of code, thus formatted.

The thinking is that somebody who liked some feature could more easily see how it was done.

The code will be marked with the version of the placemat software, as things might not work exactly the same in later versions.

Comments? Objections? Improvements?

[DRT]

I think it would be better to post the code in this thread and link it to the appropriate tasting review.

[jdaw1]

I thought it better to post it near the placemats.

[DRT]

I thought it better to post it near the placemats.

Posting code in a post that is intended for organising a Port tasting might make people think we are geeks.

[jdaw1]

This thread is for discussion about the software. Perhaps this collection of code should go in a new thread in the Reference section?

[DRT]

This thread is for discussion about the software. Perhaps this collection of code should go in a new thread in the Reference section?

Or you could output the interesting code to the last page of the placemats file and it could be accessed by downloading the placemats?

[jdaw1]

This thread is for discussion about the software. Perhaps this collection of code should go in a new thread in the Reference section?

Or you could output the interesting code to the last page of the placemats file and it could be accessed by downloading the placemats?

That is fundamentally difficult. Sorry, no.

[jdaw1]

This thread is for discussion about the software. Perhaps this collection of code should go in a new thread in the Reference section?

∃ Parameters for the placemat software.

[jdaw1]

Note to self: a glass-by-glass version of FontSizesSetsGlassesPages is needed.

If there are bottles with labels like ‟Mz”, ‟SW”, ‟QH”, ‟QC”, and other bottles with labels like ‟JDAW”, ‟AHB”, ‟DRT”, the sizing of the two sets should be independent. Easiest would be to add flexiblity to FontSizesSetsGlassesPages, so that each element can be an array (in which case its glass-by-glass elements are used) or a non-array.

[jdaw1]

+CircletextsTryToResonateWithRays

The code as originally written was meant to produce one page of glasses, perhaps A4, perhaps A3. Modern usage is typically A4, with ≤6 glasses per page, and multiple pages. The default value of GlassesOnSheets has, rather belatedly, been adjusted to match this modern default behaviour. 

[jdaw1]

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?

Done in the code, even though not in the manual: ExclusionAnnulusProportionInnerRadiusTitlesAboveBelow and ExclusionAnnulusProportionInnerRadiusOvertitles.

[JacobH]

Should the font selected for the place-mat have, in effect, built in negative kerning, in that some of the glyphs go over the y-axis, then there may be a clash between some letters and the lines on the question and other pages.

For example, the J in Jannon T Moderne Pro Italic overlaps the y-axis (in red) quite considerably:

kern2.png (5.05 KiB) Viewed 13697 times

This results in a clash when a placemat is generated using the font and my initials:

kern.png (2.33 KiB) Viewed 13697 times

I imagine the problem is only regularly encountered with Italic fonts but could be quite severe if one used a swashed one.

Ideally, I suppose, one would like the software to detect this negative spacing and compensate, but I am not sure if this is feasible or practical. I therefore flag it up for comments rather than as a bug.

[jdaw1]

Should the font selected for the place-mat have, in effect, built in negative kerning, in that some of the glyphs go over the y-axis, then there may be a clash between some letters and the lines on the question and other pages.

In some places the software establishes widths with PathBBox, a more accurate version of the built-in pathbbox. In other places it uses something like stringwidth pop, as called by StringWidthRecursive. The former is slower but correctly copes with the observed problem, and can become more widespread.

So the excellent observation is noted and will be acted upon, even if not for several weeks.

Your image suggests that the grey line is drawn after the names. That shouldn’t be happening: presumably your example is from a voting sheet, which therefore needs an extra fix.

[jdaw1]

Done in the code, even though not in the manual: ExclusionAnnulusProportionInnerRadiusTitlesAboveBelow and ExclusionAnnulusProportionInnerRadiusOvertitles.

Forgot to say: now mentioned in the manual.

[jdaw1]

In some places the software establishes widths with PathBBox, a more accurate version of the built-in pathbbox. In other places it uses something like stringwidth pop, as called by StringWidthRecursive. The former is slower but correctly copes with the observed problem, and can become more widespread.

Thinking further, which should be used? Let’s consider a swashed font, in which some letters have a tail that is meant to go under the previous letter. So for the text in a circle, that going under should be retained.

But for text-in-a-box (and, Titles-style, text-within-a-circle), it shouldn’t.

This is awkward for the circle-text in a straight line. The start and finish should be PathBBox-style, but the interior should be stringwidth-style. This will be fiddly.