ThePortForum.com

flash_uk wrote:I agree - top row should say shipper in full, bottom row should say the name.

I agree, or +1, whichever is preferred.

jdaw1 wrote:

flash_uk wrote:I agree - top row should say shipper in full, bottom row should say the name. The only potential headache I can see would be with long names on the top row. How would Feuerheerd, Constantino or Gould Campbell get on?

I haven’t written the code to have the rows different, but using the usual 5×13 small stickies, with most setting at or near default, the code can already make the following.

Which hopefully reassures.

Punch it Chewie.

My personal preference would be as per existing detail example (shipper/year abbreviation as main item with person initials above and below), though I have no cogent objection to the planned approach.

Additional note: Although I am less keen, if providing shipper and year in above/below then shipper preceeding year would look better than year preceeding shipper as currently (i.e. "Feuerheed YYYY" rather than "YYYY Feuerheed").

PhilW wrote:My personal preference would be as per existing detail example (shipper/year abbreviation as main item with person initials above and below), though I have no cogent objection to the planned approach.

Big stickers are for bottles, so not personalised, and have contents of Circlearrays top and bottom. Little stickers are for glasses. Currently littles are double-personalised, Names top and bottom, which is about to drop to single-personalised, Circlearrays at top and Names at bottom. You are deemed not to have sufficiently objected to count as an objection.

PhilW wrote:Although I am less keen, if providing shipper and year in above/below then shipper preceeding year would look better than year preceeding shipper as currently (i.e. "Feuerheed YYYY" rather than "YYYY Feuerheed").

It follows the order in the Circlearrays; hence is and will remain under the user’s control. Typically I put first the thing that varies: in a horizontal, the shipper; in a vertical, the vintage.

Done (= ‘punched’).

Re the discussion a few dozen posts ago about InlineTitles, there’s also a problem with Chrome, the PDF viewer of which mangles InlineTitles. This is known, and on 21^st May a bug report was submitted.

Speaking of InlineTitles, is there a reasonably simple explanation of the fix? I am idly curious about it since Distiller and GhostScript had such different interpretations of the code, at least as far as execution time is concerned.

What InlineTitles/InlineAbovetitles/InlineBelowtitles/InlineOvertitles do is stroke a very thick black line, then a slightly thinner white, then a slightly thinner black, etc, until the last line is very thin and black. All of this whilst the painting region is clipped to the boundary of the relevant string.

But, alas, PDFs thus made would print very slowly on a printer used by AHB (example complaint). So, to lessen that problem, LineWidthThatCoversPath was written, which computes the maximum number of lines needed (so if maximum distance from an internal point to the boundary is 10pt, it starts strokeing with a setlinewidth of 10pt×2 rather than 50pt×2). That horrible computation (request for algorithmic help, not usefully answered) repeatedly calls a PostScript operator infill, which — then unknown to me — is very slow in Ghostscript (bug report). Lordy — just can’t win!

So, now the code doesn’t do the infill-requiring estimation if in GhostScript, nor if InlineTitlesMaxNumberContours ≤ 2.

Edit: so in the last few posts mention has been made of needless slowless in AHB’s printer, needless slowness in Ghostscript, and rendering issues in Chrome. And the code also circumvents a bug in Distiller 8. No trouble at all.

Interesting, thank you for both the fix and the explanation.

[url=http://www.theportforum.com/viewtopic.php?p=90612#p90612]Here[/url] PhilW wrote:

jdaw1 wrote:The placemat code allows the adding of an annotation to glasses (GlassesAnnotations). After a blind tasting, should the placemat then be ‘changed’ to annotate what was what?

No. Final version of placemats is final version, including any errors. Scoresheet (including answers) is Scoresheet. Post-event update of placemats bad.

Having thought about this more, I disagree with Phil.

I’m about to make the decanter labels for the tasting of Sweet-Spot Vintages. When they’re made, I’ll change the placemats to /DecanterLabelsNumCopies 0 def. When Mike prints on the day, with whoever is and isn’t coming appropriately altered, he won’t be wasting the decanter-label pages. After the tasting /DecanterLabelsNumCopies 1 def will be reverted, and that will be the ‘final’ version.

This seems reasonable, at least to me. But it firmly clashes with Phil’s purism.

Further comment?

Well, the final version of the placemats will still be the final version. Really all you are doing is getting ahead of the curve with an interim print of the labels, and avoiding me wasting some paper when the placemats etc are printed. The content on the pages and labels will be exactly the same in the end, compared to what is in the final pdf.

flash_uk wrote:Well, the final version of the placemats will still be the final version. Really all you are doing is getting ahead of the curve with an interim print of the labels, and avoiding me wasting some paper when the placemats etc are printed. The content on the pages and labels will be exactly the same in the end, compared to what is in the final pdf.

We agree. Please allow me to probe your view a little further.

Imagine that a placemat has an error, that a Port is mis-labelled (e.g., D78 rather than DB78). Are you happy to add a non-printing annotation as an corrigendum? (Phil isn’t.) Non-printing, but added after the event.

jdaw1 wrote:

flash_uk wrote:Well, the final version of the placemats will still be the final version. Really all you are doing is getting ahead of the curve with an interim print of the labels, and avoiding me wasting some paper when the placemats etc are printed. The content on the pages and labels will be exactly the same in the end, compared to what is in the final pdf.

We agree. Please allow me to probe your view a little further.

Imagine that a placemat has an error, that a Port is mis-labelled (e.g., D78 rather than DB78). Are you happy to add a non-printing annotation as an corrigendum? (Phil isn’t.) Non-printing, but added after the event.

Assuming this would mean that if you printed said updated pdf, the error would still be shown, then I'd be OK with a non-printing annotation. One could argue that the final placemat pdf is the one stored after the tasting has finished, containing some info about the tasting (including errors discovered etc).

flash_uk wrote:Assuming this would mean that if you printed said updated pdf, the error would still be shown

Yes, that is what is meant.

flash_uk wrote:then I'd be OK with a non-printing annotation. One could argue that the final placemat pdf is the one stored after the tasting has finished, containing some info about the tasting (including errors discovered etc).

Splendid. We agree.

Would you go further? For a blind tasting, would you want the reveal to be added, again as a non-printing annotation? E.g., after the SSV should the Roman numbers (I, II, III, IV, …, XII) be non-printingly annotated with Port names?

jdaw1 wrote:

[url=http://www.theportforum.com/viewtopic.php?p=90612#p90612]Here[/url] PhilW wrote:

jdaw1 wrote:The placemat code allows the adding of an annotation to glasses (GlassesAnnotations). After a blind tasting, should the placemat then be ‘changed’ to annotate what was what?

No. Final version of placemats is final version, including any errors. Scoresheet (including answers) is Scoresheet. Post-event update of placemats bad.

Having thought about this more, I disagree with Phil.

I’m about to make the decanter labels for the tasting of Sweet-Spot Vintages. When they’re made, I’ll change the placemats to /DecanterLabelsNumCopies 0 def. When Mike prints on the day, with whoever is and isn’t coming appropriately altered, he won’t be wasting the decanter-label pages. After the tasting /DecanterLabelsNumCopies 1 def will be reverted, and that will be the ‘final’ version.

This seems reasonable, at least to me. But it firmly clashes with Phil’s purism.

Further comment?

As Ian has already pointed out, this isn't really an edit of the final placemats. It is simply turning a switch on/off to make printing more convenient. Therefore it is acceptable practice.

To me, though, your further questions are not acceptable edits. I do not see the placemats.ps file as a historical record of the entire tasting, but rather simply a data file that's being preserved. The non-printing edits that you suggest belong more appropriately in the review thread for the evening or the tasting notebooks of the participants.

Glenn E. wrote:simply a data file that's being preserved.

Would you be willing to see it as proto-paper? Qualities relating to its proto-paper are not to change, but other qualities might change.

(For me, marking errors as such is good. But I am ambivalent about de-blinding.)

jdaw1 wrote:Would you go further? For a blind tasting, would you want the reveal to be added, again as a non-printing annotation? E.g., after the SSV should the Roman numbers (I, II, III, IV, …, XII) be non-printingly annotated with Port names?

Yes seems fine. Although of course in the SSV case, there are currently only a couple of ports that need a reveal. All the others are known, as we have included sticky labels in the pdf.

flash_uk wrote:Although of course in the SSV case, there are currently only a couple of ports that need a reveal. All the others are known, as we have included sticky labels in the pdf.

In theory the VIII, say, could be non-printingly annotated with D70 (or whichever it is). So not “of course”.

jdaw1 wrote:

Glenn E. wrote:simply a data file that's being preserved.

Would you be willing to see it as proto-paper? Qualities relating to its proto-paper are not to change, but other qualities might change.

(For me, marking errors as such is good. But I am ambivalent about de-blinding.)

In my case the discussion is merely theoretical, so my comments should not override those of people who actually make use of the preserved placemats.ps files.

So, still speaking theoretically, I still feel as if the file should be preserved as it was used. I understand the desire to annotate errors, but in my head I cannot resolve actually altering the file to do so. That "destroys" the historical record. In the perfect world of my imagination, the errors would be annotated in the file storage system so that the Port tasting placemat archaeologists of the future would be able to understand what went wrong while still having a perfect record of that wrongness.

Glenn E. wrote:while still having a perfect record of that wrongness.

At the tasting is paper, not an electronic file. And there is a perfect record of the paper.

I observe that the computer-professional people, Phil and Glenn, are anti, whilst Mike and Julian seem more relaxed about it.

Glenn E. wrote:...I still feel as if the file should be preserved as it was used. I understand the desire to annotate errors, but in my head I cannot resolve actually altering the file to do so. That "destroys" the historical record. In the perfect world of my imagination, the errors would be annotated in the file storage system so that the Port tasting placemat archaeologists of the future would be able to understand what went wrong while still having a perfect record of that wrongness.

The electronic file could be defined as record of everything that happened, not just of the papers that appeared at the event. By adding the non-printing annotations, are you not giving the Port tasting placemat archaeologists of the future a wonderful audit trail?

flash_uk wrote:

Glenn E. wrote:...I still feel as if the file should be preserved as it was used. I understand the desire to annotate errors, but in my head I cannot resolve actually altering the file to do so. That "destroys" the historical record. In the perfect world of my imagination, the errors would be annotated in the file storage system so that the Port tasting placemat archaeologists of the future would be able to understand what went wrong while still having a perfect record of that wrongness.

The electronic file could be defined as record of everything that happened, not just of the papers that appeared at the event. By adding the non-printing annotations, are you not giving the Port tasting placemat archaeologists of the future a wonderful audit trail?

Danger! Danger, Will Robinson!

Why not include everyone's tasting notes in the file too, then?

Glenn E. wrote:Danger! Danger, Will Robinson!

Why not include everyone's tasting notes in the file too, then?

Well, technically we do include Derek's notes when he attends

Glenn E. wrote:Danger! Danger, Will Robinson!

Why not include everyone's tasting notes in the file too, then?

PDF shows what the Ports are, not of what they taste. Your straw man seems to be a substantial step beyond the proposal.

jdaw1 wrote:

[url=http://www.theportforum.com/viewtopic.php?p=90612#p90612]Here[/url] PhilW wrote:

jdaw1 wrote:The placemat code allows the adding of an annotation to glasses (GlassesAnnotations). After a blind tasting, should the placemat then be ‘changed’ to annotate what was what?

No. Final version of placemats is final version, including any errors. Scoresheet (including answers) is Scoresheet. Post-event update of placemats bad.

Having thought about this more, I disagree with Phil.

I’m about to make the decanter labels for the tasting of Sweet-Spot Vintages. When they’re made, I’ll change the placemats to /DecanterLabelsNumCopies 0 def. When Mike prints on the day, with whoever is and isn’t coming appropriately altered, he won’t be wasting the decanter-label pages. After the tasting /DecanterLabelsNumCopies 1 def will be reverted, and that will be the ‘final’ version.

This seems reasonable, at least to me. But it firmly clashes with Phil’s purism.

Further comment?

I would create one version of the placemats, with decanter-labels set to be included.
When printing, I would print the pages I want. Job done, no faffing, one version.

PhilW wrote:I would create one version of the placemats, with decanter-labels set to be included.
When printing, I would print the pages I want. Job done, no faffing, one version.

But what if responsibility for printing is likely to be split amongst people? I printing a few (decanter labels) on my home printer; Mike doing the bulk. Would the remaking of the file be easier for Mike, or for whomsoever is sub-delegated the task?

Are the computer-competent people having a trust issue? When writing robust software, sub-routines are not trusted to “alter an array, but not in any way that will hurt”. Instead the whole thing would be const, and then the sub-routine just can’t damage it at all. Much more robust.

I’m saying that I want to be able to change, but not in a way that would affect printing. Are the programmers not confident of the robustness?

jdaw1 wrote:Are the computer-competent people having a trust issue?

jdaw1 wrote:Are the programmers not confident of the robustness?

Yes it is a trust issue, though of the users/usage rather than the code. That said, it does depend on the purpose of archiving the placemats electronically.

From a software-centric perspective, best practise is for every software executable version released to have the source from which it has been created marked/identifiable within revision control, ideally along with meta-data identifying all tools and their versions used to create the executable from the source. Allowing release of the binary, and then release of the source "tweaked slightly but in a way that shouldn't affect anything" is a total no-no (since for any debug or modification your starting point is not what you think it is).

In placemat land, the placemats produced (by printing) have a file from which the printing was performed, which have a source .ps from which they were created. While it is possible for the meta-data to change (I only printed pages 10-15, or I scaled them etc), if the source changes, then both sources should be saved. In the specific example above, the .ps source is being changed; your argument is that the simple source/parameter change you are making between your two versions of source/pdf probably doesn't/shouldn't affect the page content, only which pages are produced; I don't like "probably" and prefer rigour.

If the goal of placemat archive is to provide a guide/impression, rather than the precise placemats and source used, then rigour could be compromised, though I am not persuaded to do so.

PhilW wrote:If the goal of placemat archive is to provide a guide/impression, rather than the precise placemats and source used, then rigour could be compromised, though I am not persuaded to do so.

The paper should be precisely correct, as it is the paper that is at the tasting. The source (of paper which is PDF, or of PDF which is PostScript) does not appear at the tasting.

jdaw1 wrote:

PhilW wrote:If the goal of placemat archive is to provide a guide/impression, rather than the precise placemats and source used, then rigour could be compromised, though I am not persuaded to do so.

The paper should be precisely correct, as it is the paper that is at the tasting. The source (of paper which is PDF, or of PDF which is PostScript) does not appear at the tasting.

Agreed; however the link to the placemats (in pdf format) is maintained, and should (imo) be the source used to generate (print) the paper placemats used at the tasting. Your suggestion is that the linked pdf could be based on postscript generated after the event; it would then be representative, but not guaranteed to generate identical results (in the sense that any change in source has the potential the change the output, though it may not if well-managed).

PhilW wrote:Agreed; however the link to the placemats (in pdf format) is maintained, and should (imo) be the source used to generate (print) the paper placemats used at the tasting. Your suggestion is that the linked pdf could be based on postscript generated after the event; it would then be representative, but not guaranteed to generate identical results (in the sense that any change in source has the potential the change the output, though it may not if well-managed).

We are edging closer to agreement.

What if my policy were that, post-pasting, the only parameters that may be changed are those that cannot affect the printout (except the log page)? These are the following (list might be extended later — but subject to same cannot-affect criterion).
• ExternalLinks (perhaps to add a link to the review thread);
• GlassesAnnotations (errata and corrigenda, perhaps re mis-descriptions);
• LogThisExtra (adds text to the log page — sundry message can go here);
• LicensingAgreementTextPlacemats (only for more generous licensing); and
• LicensingAgreementLinkPlacemats (ditto).

By design of the code, none of these can have any affect on the printout of any page except the log page (which I’m deeming not to be part of the placemats for these purposes).

Does that policy-and-code provide enough reassurance?

jdaw1 wrote:What if my policy were that, post-pasting, the only parameters that may be changed are those that cannot affect the printout (except the log page)? ... Does that policy-and-code provide enough reassurance?

From a formal perspective it's still definitely wrong (no change to .ps/.pdf for archived copy should be allowed once printout is produced from .pdf produced from .ps) and I would much favour the alternative of "just print the pages you want" rather than "have two different source files and hope/intend there is no error such that they would not both produce the same visual output". However, It would represent a pragmatic nominally least-risk method to allow post-tasting modification of .ps/.pdf with least change of unintentional visual change consequence, if one is prepared to breach the primary principle that the archived copy should be precisely what was used to generate the paper copy.

Glenn? Are you as persuaded as Phil?

jdaw1 wrote:Glenn? Are you as persuaded as Phil?

Given your phrasing, I should re-iterate that I am still not persuaded that we should breach the primary principle that the archived copy should be precisely what was used to generate the paper copy (I think we should not). However were you to decide to do so, the approach is subsequently sensible.

PhilW wrote:

jdaw1 wrote:Glenn? Are you as persuaded as Phil?

Given your phrasing, I should re-iterate that I am still not persuaded that we should breach the primary principle that the archived copy should be precisely what was used to generate the paper copy (I think we should not). However were you to decide to do so, the approach is subsequently sensible.

My phrasing was consistent with you being not more than slightly persuaded.

PhilW wrote:

jdaw1 wrote:Glenn? Are you as persuaded as Phil?

Given your phrasing, I should re-iterate that I am still not persuaded that we should breach the primary principle that the archived copy should be precisely what was used to generate the paper copy (I think we should not). However were you to decide to do so, the approach is subsequently sensible.

Given this answer, yes. I'm a as (not) persuaded as Phil.

But as previously stated, I'm a theoretical participant since I do not use the archived files. So if those who use them wish to alter the files prior to preservation, more power to them.

Perhaps a more formal source code management system is in order?

Glenn E. wrote:Perhaps a more formal source code management system is in order?

There are two levels of “source code”.

1. You might mean the program itself, as I and only I maintain. This question was asked, and you concurred with the negative.

   [url=http://www.theportforum.com/viewtopic.php?t=175&p=80804#p80804]Here[/url], on Monday 11th August 2014, Glenn E. wrote:

   PhilW wrote:

   jdaw1 wrote:Do any programmers know whether there would be sufficient advantages in moving my code to SourceForge.net? My prior is ‘no’, but I’m willing to be persuaded otherwise.

   I can't see a significant advantage. The primary benefits of using Sourceforge are to be able to share your code in an online public repository, facilitating multi-user development and version control. Given that your code is a single file, you already have a web server where you make the file public, and you probably want to maintain control of changes, this would seem to offer minimal benefit at this time.

   +1

2. So perhaps you mean the particular parameters for each set of placemats. You appear to be proposing using an administrative system to keep every draft .ps/.pdf. But, re the ‘final’ PDF, you said that you “do not use the archived files”. So why save every draft? I think far too much hassle for about zero gain.

Summary: no.

Post-Event Placemat Changes: The Policy

Before a tasting placemats change: people are in then out, bottles are promised and the substituted. There can be many drafts.

Then the paper print of the placemats is used at the event. So after the event there should be no change in that which would print from the PDF (excepting the log page, deemed not to be part of the placemats for these purposes). But there may be changes in the digital information that doesn’t print. To ensure that there aren’t accidental changes in that-which-would-print, after the event the only parameters that may change are those that don’t affect the printable parts of the PDF.

These parameters are the following (with parenthetical example reasons for a change).
• ExternalLinks (perhaps to add a link to the review thread, or to a website relevant to a revealed theme).
• GlassesAnnotations (corrigenda and errata, perhaps re mis-descriptions, and de-blinding).
• LogThisExtra (to add a message to the log page).
• LicensingAgreementTextPlacemats (only for more generous licensing).
• LicensingAgreementLinkPlacemats (ditto).

Discussion summary: this not the purist policy, because it relies on the operator not changing things that should not be changed. But within the limits of the formality and informality of the placemat making process, it is a practical compromise, and a practical compromise that is unlikely to do any harm.

jdaw1 wrote:Summary: no.

I believe that is the correct conclusion. I was but suggesting that it might be appropriate to consider the question again.

Considered and rejected.

There is a page type we almost never use: Decanting Notes.


Is this because it is useless and should be removed from the code? Or because everybody had forgotten, and, now reminded, will be clamouring for it? Or something else?

The most recent placemats with DN pages were AHB’s 1963 Quinquagenary in October 2013 (pdf), the Taylor vertical in March 2013 (pdf), and several the previous year including the Graham vertical in November 2012 (pdf). The only record of their use is at the matrix tasting in October 2011 (thread).

(The question is asked because a small improvement was recently made to the vote-recorder pages — small, trust me — which should be echoed to the decanting-note pages. Which raised the question of whether the DN pages have any purpose.)

I think we should keep these. They are useful for very large tastings, particularly when we remember to print them.

We never use them, but it's easy to not print them so I don't really care whether or not they remain in the code.

Basically What Derek and Glenn said. I rarely use them but when I need to its nice to have them.


Sent from my iPhone using Tapatalk

I'd like to keep them in the deck. We did use them at the Quinquagenary to make a record of the bottler and time of decanting. One or two more detailed notes were also taken.

DRT wrote:I think we should keep these. They are useful for very large tastings, …

AHB wrote:I'd like to keep them in the deck.

Consensus: they will be kept in the deck.

DRT wrote:… particularly when we remember to print them.

Note to self: remember. Or automate. Would it be sensible for them appear by default iff there are ≥15 wines (/DecantingNotesNumCopies Circlearrays length 15 ge {1} {0} ifelse def)?

Edit: the default is now /DecantingNotesNumCopies Circlearrays length 15 ge {1} {0} ifelse def.

I've never used them; Cork details is probably not really needed any longer, since we have the cork display. The only part which seems potentially useful is to have a sheet for recording decant times when decanting centrally (I have made notes of times on a scrap of paper when decanting like this previously). For anything other than vertical, unlikely to be useful since people will all decant at home and usually are asked decant time at the tasting which would be noted on normal sheets (possibly an argument for a handy space for it on the normal tasting notes, so we can use/ignore it as per the eye/nose/taste sections).

PhilW wrote:(possibly an argument for a handy space for it on the normal tasting notes, so we can use/ignore it as per the eye/nose/taste sections).

You have been ignoring it: since mid-February 2008 the code has contained /TastingNotesColumnHeadings [ (Times) (Eye) (Nose) (Mouth) (Score) ] def.

I have sympathy with your opinion that DNs aren’t needed, but consensus was the other way.

The 2015 Royal Academy Summer Exhibition:


And an extract from the placemats for the Flight of 1966 on 22^nd April 2014.