Software that makes placemats

[DRT]

In the discussion thread Quantifying opacity

To assess, look at the circle text through about 1cm of port in a titled glass.

Perhaps we could devise a standard way of doing this by using a feature on the placemats?

Imagine a horizontal bar about 5mm wide running across the bottom of a Placemat or TN sheet. The bar is white at one end and black at the other, with all of the shades of grey in between. Written inside the bar, in a black font, are the gradients 0%, 10%, 20% ! 100%, the latter of which would be invisible.

Now place a tilted glass above one end of the bar and move it along until you cannot read the number below it. That is the opacity of the wine.

Would that work?

[jdaw1]

A good idea.

➊ I’d like the test to be based on something standard, recommended by those expert in this field.

âž‹ Different printer resolutions can make different greys appear quite different. Might that confound the attempt at standardisation? (Also, but I think less, different toners might be a problem.)

[RAYC]

Or invest in one of these...

[DRT]

A good idea.

➊ I’d like the test to be based on something standard, recommended by those expert in this field.

âž‹ Different printer resolutions can make different greys appear quite different. Might that confound the attempt at standardisation? (Also, but I think less, different toners might be a problem.)

On 2, provided the 100% was invisible or as good as, and the graduation of grey looked consistent, I don't think the variation of printer/toner would have much effect.

Perhaps if someone very clever could produce a test sheet we could each print a copy of it and bring them to the Bunghole to test whether or not the printer variation is significant. The test sheet does not have to part of the placemets.

[DRT]

Or invest in one of these...

I'm no expert, but I suspect it would be extremely difficult to embed one of those into Postscript.

[Alex Bridgeman]

A good idea.

➊ I’d like the test to be based on something standard, recommended by those expert in this field.

âž‹ Different printer resolutions can make different greys appear quite different. Might that confound the attempt at standardisation? (Also, but I think less, different toners might be a problem.)

On 2, provided the 100% was invisible or as good as, and the graduation of grey looked consistent, I don't think the variation of printer/toner would have much effect.

Perhaps if someone very clever could produce a test sheet we could each print a copy of it and bring them to the Bunghole to test whether or not the printer variation is significant. The test sheet does not have to part of the placemets.

I agree with DRT - if the 100% is invisible then this should be a self-balancing test.

An alternative approach might be to print a small ruler along one edge of the test; then to tip the glass and measure the distance from the rim at which the ruler becomes invisible. We could conduct some tests to develop an agreed standard.

[Glenn E.]

An alternative approach might be to print a small ruler along one edge of the test; then to tip the glass and measure the distance from the rim at which the ruler becomes invisible. We could conduct some tests to develop an agreed standard.

This is similar to (better than, really) the method I use to judge very young Ports. I judge pencil-widths visible at the rim, but a ruler would be more precise and allow for rating older Ports as well.

The key to this system is a consistent fill level in a standard shape glass. This might be difficult at a larger tasting where pour sizes are smaller, but I think it's a relatively easy system to use.

[SushiNorth]

In the sake world, clarity is measured by putting the sake into a white ceramic glass with two blue circles in the bottom (bullseye-like). At equal pour for each sake, the judge can differentiate clarity and color.

[jdaw1]

People might want to do the opacity test in different light, so will want to be able to hold it. Hence it must be on the TN sheets rather than the glasses sheets.

Is what is wanted anything like this?

[DRT]

Is what is wanted anything like this?

That is what I had in mind, although the version I had in my head had white on the left and black on the right.

I think the bar needs to be quite wide so that the precision with which you have to hit the right spot becomes easier.

[jdaw1]

That is what I had in mind, although the version I had in my head had white on the left and black on the right.

With numbers descending, 9 to 1? Ascending numbers seemed more natural to me, though it is easy to change.

[DRT]

That is what I had in mind, although the version I had in my head had white on the left and black on the right.

With numbers descending, 9 to 1? Ascending numbers seemed more natural to me, though it is easy to change.

No. White on the left = 0% (as in fully transparent) and black on the right being 100% (as in 100% opaque).

[jdaw1]

Are you sure? I think the ‟9” of ‟90%” needs to be against very pale grey. If you can’t see black on 10% grey, then the port is ≥90% opaque.

[jdaw1]

Updated test page.

[DRT]

That is what I meant when I asked...

Would that work?

You are, of course, correct. My idea was in the early stages of development when I wrote the first post. Thankfully there are people here who can take semi-flawed ideas and make them work

[jdaw1]

Updated test page.

[Glenn E.]

Is what is wanted anything like this?

That is what I had in mind, although the version I had in my head had white on the left and black on the right.

That's because you're Scottish.

Are you sure? I think the ‟9” of ‟90%” needs to be against very pale grey. If you can’t see black on 10% grey, then the port is ≈90% opaque.

The numbers are reversed to me. We're judging opacity, not the printed greyscale, so to me the numbers should indicate the opacity of the Port. I cannot be expected to do math while consuming alcohol. 

[jdaw1]

Printing on two laserprinters gives different apparent greys. As a form of standardisation, this is miserable. (Though within each printer, the four lines are very similar.)

[jdaw1]

To help those unwilling to open a PDF:

[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 19917 times

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

kern.png (2.33 KiB) Viewed 19917 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.

[JacobH]

I notice Almibar Pro is currently available for $7.99 which might be helpful for testing swash handling:

B.gif (5.27 KiB) Viewed 27083 times

...

[jdaw1]

Almibar Pro

I have FreebooterScript on my computer, which is sufficiently silly for this purpose.

[jdaw1]

Bonus question. The voting sheets and decanting-note sheets have grey straight lines on them. Currently the text is imperfectly fitted to the centre of these lines. So the text, deliberately, might overlap the near half of a line.

Should the fitting be to the centre, or to the edges of the lines?

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

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

Fixed.

Except the distance of items of Names from the waterboxes.

[jdaw1]

Except the distance of items of Names from the waterboxes.

Fixed. Also a workaround added to circumvent a bug in Adobe Distiller.

As ever, please use the latest version.

[DRT]

This looks like an elegant solution. Collecting most of the relevant data first into two arrays to then be used by the more complicated stuff is just one step closer to a Placemat Wizard.

Edit by JDAW:

• Data is mostly in two arrays, PeopleData and PortData, and is decanted from there into the parameter arrays. For large tastings this can be easier, as it keeps together the relevant items of Titles, Overtitles, FillTexts, etc.