Software that makes placemats

[Glenn E.]

I seem to have lost track of the alternate online PS to PDF converter that we (or at least I) have been using since ps2pdf.com starting having problems. Does anyone have a recommendation?

[Glenn E.]

I found online2pdf.com and believe that is the one that I used in January. Unfortunately, it is not able to process my most recent placemats either. (I also tried ps2pdf.com and received the 500 Internal Server Error that we've been seeing for some time now.)

My guess is that the placemats are growing too large. Online2pdf.com will still convert the placemats that I created in January, but those placemats were for 18 glasses on USL2 with simple Circlearrays, minimal Titles (the numbers 1-18), and no Belowtitles. The current placemats are for 20 glasses and have relatively lengthy Circlearrays, still fairly minimal Titles (years), and producers as Belowtitles.

I even went so far as to make a copy of the January placemats and simply replace Circlearrays, Titles, and Belowtitles with the new information. Online2pdf.com failed to convert it.

I've since tried trimming that test file down to 16 glasses (failed) and 12 glasses (failed). The original 18-glass January placemat still converts.

I am at a loss.

[jdaw1]

Email it to me?

Email it to somebody with a, ahem, Mac, who could then open it in Preview and save as PDF?

Most, perhaps all, online PS→PDF converters use Ghostscript. Install Ghostscript?

[jdaw1]

A few minutes ago online2pdf.com/convert-ps-to-pdf was tested to reproduce the placemats used on 2nd March. It worked well, quickly producing a 114-page PDF (in which Harrington and LucidaSans were replaced with Courier). So WFM.

My guess is that the placemats are growing too large.

Unlikely to be the problem. Consider …EBKAC.

[Glenn E.]

I sent the .ps file to a friend who has GhostScript installed locally, and he was able to generate the .pdf for me. It took 17 minutes, which explains why an online service would abort. The online service probably thinks that the conversion is caught in an infinite loop or something.

I'll email you the .ps so that you can take a look if you so choose. I'll also be downloading and installing GhostScript myself, which I did briefly this weekend but couldn't quickly figure out how to use it so resorted to asking a friend for help.

[jdaw1]

I sent the .ps file to a friend who has GhostScript installed locally, and he was able to generate the .pdf for me. It took 17 minutes, which explains why an online service would abort. The online service probably thinks that the conversion is caught in an infinite loop or something.

That might be the answer. Using Distiller 8 the two .ps files you sent me took 12 seconds and 8 seconds.

Perhaps the recent change of default value of InlineTitles is the problem. That’s a shame. Try /InlineTitles false def.

[PhilW]

I tried ghostscript under windows a few years ago, mostly just because I needed to view some .ps files rather than convert them, but found it fairly unfriendly, so decided to try again and see where things are at now.

- Ghostscript installed no problem
- To use ps2pdf, you have to run their batch file (from a Windows Command Prompt) referencing the full path, i.e. in my case "C:\Program Files\gs\gs9.16\lib\ps2pdf" with input and output files as parameters.
- This also requires the gs\gs9.16\bin directory to be added to your path, manually (not done by installer), to access the underlying gswin64.exe core binary executable called by the scripts
- This worked for processing a relatively simple tasting notes .ps (the Martinez vertical) but failed catastrophically with no error message on a more complex one (the Warre/Fonseca tasting)

Overall, non-trivial for users (since have to set paths manually, and run long directory-linked paths on the command line; both of these could be addressed simply with another script); clearly works to some extent; whether the failure to parse more complex postscript could be addressed by some control parameters modifications or other means is TBD.

[jdaw1]

I sent the .ps file to a friend who has GhostScript installed locally, and he was able to generate the .pdf for me. It took 17 minutes, which explains why an online service would abort. The online service probably thinks that the conversion is caught in an infinite loop or something.

That might be the answer. Using Distiller 8 the two .ps files you sent me took 12 seconds and 8 seconds.

Thank you Glenn: you have found the problem. Changing one line to /InlineTitles false def makes it work in both PS2PDF.com and online2pdf.com.

Default parameters will be reverted this evening, and cautionary words added to the manual.

Edit: I’ve had other troubles with /Helvetica-Bold. Maybe the font is somehow misformed? Perhaps the default value of TitlesFont should be one of the CMU fonts. Suggestions? Ideally widely available and included with Ghostscript as standard, bold or demi-bold, not italic, not oblique, condensed or demi-condensed, lining figures, and with all of CkDFGKNOSTVW0123456789 resting on the baseline and having the same height.

Edit edit: /TimesNewRomanPS-BoldMT worked on online2pdf.com but not on PS2PDF.com. Sigh. Two different problems.

[jdaw1]

Default parameters will be reverted this evening, and cautionary words added to the manual.

This evening has been postponed. Investigations underway. But, pro tem, /InlineTitles false def seems to work.

[Glenn E.]

It does indeed. My friend performed the test on his system and the conversion time dropped from 1017 seconds to 1.053 seconds. ~1000x improvement.

I plan to start using GhostScript locally, but agree that InlineTitles should be false by default.

[Glenn E.]

Also, my friend said he was able to pinpoint the slowness to the generation of the circle arrays. He said that once the circles were done that everything else completed very quickly. I think he was using a built in GhostScript previewer of some sort.

[jdaw1]

Default parameters will be reverted this evening, and cautionary words added to the manual.

Done.

[Glenn E.]

I now have GhostScript installed and so tried it myself using the first file that I generated for this set of placemats. (I sent a different file to my friend based off a known-to-be-good version from the FTLOP 1985 Horizontal in January.)

With /InlineTitles true def, 1283.8 seconds.

With /InlineTitles false def, 0.8 seconds.

GhostScript really really really does not like InlineTitles. And it's clearly a GhostScript issue because Julian's copy of Distiller can do these files in ~20 seconds.

Sadly, I like the look better with InlineTitles true. So in the future I will likely do my placemat creating with it false, then once I have everything settled the way I like it I'll switch it to true and run the final placemats locally.

Thank you, Julian, for your help. Hopefully GhostScript will be able to figure out what's going on and issue a patch.

[jdaw1]

A solution is underway. Problem understood and can (perhaps sufficiently) be remedied.

[jdaw1]

InlineTitles now back to previous true. Instead three different parameters have new starting values:

Code: Select all

/InlineTitlesAttemptMinimiseNumContours {InlineTitlesMaxNumberContours 2 gt  IsDistiller and} def
/InlineAboveBelowOverAttemptMinimiseNumContours {InlineAbovetitlesMaxNumberContours 2 gt  InlineBelowtitlesMaxNumberContours 2 gt  InlineOvertitlesMaxNumberContours 2 gt  or or  IsDistiller and} def
/InlinePlaceNamesAttemptMinimiseNumContours {InlineTitlesMaxNumberContours 2 gt  IsDistiller and} def

[/small]All now working well and quickly.

Please verify same.

Edited Sunday 12th April 2015 with latest version of parameter defaults.

[jdaw1]

Hopefully GhostScript will be able to figure out what's going on and issue a patch.

Bug submitted, but even if a patch were issued tomorrow (unlikely), it might take years for ps2pdf.com and the like to update. So my fix probably more useful.

[Alex Bridgeman]

Moved by jdaw1 from the thread entitled Thursday 17th December - The Christmas Offline.

Edit by jdaw1, by permission of AHB: current draft of the stickies and TN pages.

Please post-script expert sir, please could we have some water boxes to colour in while waiting for our next glass of port? There could be space on the tasting sheets sir.

[jdaw1]

Please post-script expert sir, please could we have some water boxes to colour in while waiting for our next glass of port? There could be space on the tasting sheets sir.

AHB might be very correct.

The tasting-note sheets are for writing on. That is their purpose. The glasses sheets are to be seen. Currently the only writing on the glasses sheets is in the water boxes. That feels like a type error: writing should not be on pages upon which one is mostly not writing.

So I’m in favour of moving the water counts to the TN sheets.

They could appear in a horizontal line, bottom-left, the same size as and just after the icon. Objections? Or, easier for the programmer, the icon could move or disappear.


This would have an extra advantage: in usual circumstances^†, being left-handed would make no difference. That’s a mistake that a placemat maker can no longer make.


† Being left-handed would still matter when there are so few ports, and so little space, that both glasses and TNs are on the same page. That is, when SideBySideGlassesTastingNotes is true.

[flash_uk]

For me, no. Firmly not. The glasses sheets end up firmly established in place and are ever accessible, and so I can always record water consumption. Tasting note pages get rotated around, moved about etc.

Your proposition that glasses sheets are to be seen is false. They are free to be annotated and written on.

[Alex Bridgeman]

I too have a preference that when glasses sheets are produced that it is the glasses sheet which carries the water boxes. For me the glasses sheets are where I will write everything I wish to leave behind and the tasting sheets is where I will record all I wish to retain. I do not wish to retain water.

So my preference - and which must be seen as that expressed by someone who has no idea of how difficult this might be to code - would be for the water glass marks to be on the glasses page when these are produced and the tasting notes sheets otherwise.

[jdaw1]

If the water boxes can go on either, then there will be two sets of parameters, only one of which will be active. I’m trying to lean against the extra complexity for the user (two sets of parameters) and for the programmer (two sets of code). So I would much rather that we choose one of glasses sheets and TN sheets, and live with the consequences of that choice.

My preference has become TN sheets, but I observe that choice has firm opponents.

[Glenn E.]

Glasses sheets. We do not use the TN sheets for our tastings, so if the water boxes are moved we will no longer have use of them.

Most people here have tasting notebooks that we keep all of our notes in, that's why we have no need for tasting note sheets.

[PhilW]

I would prefer glasses sheets over tasting sheets if there will only be a single location, for the reasons expressed by Flash - usually fixed position on table, water boxes clearly visible, which is often not true of the tasting notes, especially when multi-page.

Alex's suggestion of boxes on glasses sheet if available versus on tasting notes if not seems reasonable, though I don't feel overly strongly on the issue.

[jdaw1]

Something has to give, and the weakest argument was mine.

The parameter WaterCounts will be replaced by WaterBoxesGlasses and WaterBoxesTastingNotes (as, separate to the main question, I think ‘Boxes’ better than ‘Counts’). There is currently a parameter WaterCountNumSideTriangle: on TN pages, the number of boxes will be WaterBoxesNumSideTriangle × (1+WaterBoxesNumSideTriangle) ÷ 2.

There are two array parameters WaterCountShowLeft and WaterCountShowRight which I never change from their default values. I’m going to move then in to the code, so that equivalent parameters for TN sheets don’t have to be documented. If WaterBoxesOverrideShowEverySheet is false then the water boxes will be on each session’s first TN sheet.

Objections?

[PhilW]

The parameter WaterCounts will be replaced by WaterBoxesGlasses and WaterBoxesTastingNotes (as, separate to the main question, I think ‘Boxes’ better than ‘Counts’). There is currently a parameter WaterCountNumSideTriangle: on TN pages, the number of boxes will be WaterBoxesNumSideTriangle × (1+WaterBoxesNumSideTriangle) ÷ 2.
...
Objections?

Suggestion rather than objection:
- Unless you wish to allow for the possibility of both, then a single parameter WaterBoxes could be used, set to None, Glasses or TastingNotes.
- A single parameter WaterBoxesNumCols or WaterBoxesRowLenMax (or similar) could be commonly used which would suffice for both, while still clearly defining the length of triangle side for use on glass pages, or single row on tasting notes, OR
- Define a single parameter WaterBoxCount; For tasting note pages, this is a single line; For glasses pages, use rndup(sqrt(2*WaterBoxCount)) to define the long triangle side length (and optionally drop boxes from the top of the triangle if wanted for precise count)

[jdaw1]

- Unless you wish to allow for the possibility of both, then a single parameter WaterBoxes could be used, set to None, Glasses or TastingNotes.

And it could have a value /Both. Consider the case in which the parameter’s value is some code, probably depending on Names NameNum get: which would be easier? •••This is the only outstanding WaterBoxes question: two boolean parameters (WaterBoxesGlasses and WaterBoxesTastingNotes), or one four-valued parameters (WaterBoxes)? My slight preference is for former.•••

- A single parameter WaterBoxesNumCols or WaterBoxesRowLenMax (or similar) could be commonly used which would suffice for both, while still clearly defining the length of triangle side for use on glass pages, or single row on tasting notes,

This suggests a rectangular layout, which isn’t the plan for the glasses page.

- Define a single parameter WaterBoxCount; For tasting note pages, this is a single line; For glasses pages, use rndup(sqrt(2*WaterBoxCount)) to define the long triangle side length (and optionally drop boxes from the top of the triangle if wanted for precise count)

I agree with WaterBoxesNum. But your formula is wrong (test 1, 3, 5, 6, 9, 10). I’ll use ( √(1+8n) - 1 )÷2, rounded up, which, without testing, is WaterBoxesNum 8 mul 1 add sqrt 1.00001 sub 2 div ceiling cvi. (The extra .00001 is meant to fix PostScript’s single precision. In theory it should not introduce an error of its own until the number of water boxes is infeasibly large. Anyway the code fails for other reasons above 65535 boxes.)

[PhilW]

- Unless you wish to allow for the possibility of both, then a single parameter WaterBoxes could be used, set to None, Glasses or TastingNotes.

And it could have a value /Both. Consider the case in which the parameter’s value is some code, probably depending on Names NameNum get: which would be easier? •••This is the only outstanding WaterBoxes question: two boolean parameters (WaterBoxesGlasses and WaterBoxesTastingNotes), or one four-valued parameters (WaterBoxes)? My slight preference is for former.

Minor preference for latter from a nominal best-design perspective, since you could (though I'm not suggesting you should) define it on a per-person basis, and then for each person's sheets set the working values for the each page type. However, global use of the two Boolean values would not worry me either.

- Define a single parameter WaterBoxCount; For tasting note pages, this is a single line; For glasses pages, use rndup(sqrt(2*WaterBoxCount)) to define the long triangle side length (and optionally drop boxes from the top of the triangle if wanted for precise count)

I agree with WaterBoxesNum. But your formula is wrong (test 1, 3, 5, 6, 9, 10). I’ll use ( √(1+8n) - 1 )÷2, rounded up, which, without testing, is WaterBoxesNum 8 mul 1 add sqrt 1.00001 sub 2 div ceiling cvi. (The extra .00001 is meant to fix PostScript’s single precision. In theory it should not introduce an error of its own until the number of water boxes is infeasibly large. Anyway the code fails for other reasons above 65535 boxes.)

My formula was wrong (off the top of my head I had only considered even cases) but the correction is simpler: rounddown(0.5+sqrt(2n)) works for all cases for 1-60 boxes, at least.

[jdaw1]

Your formula works. Why? Is it obvious?

( √(1+8n) - 1 )÷2 works because:

[PhilW]

Your formula works. Why? Is it obvious?

( √(1+8n) - 1 )÷2 works because:

Nice geometric explanation; I reached the same equation by consideration of the triangle of n blocks with side y, so n=y*(y+1)/2; the only positive quadratic root of y²+y=2n is y=(-1+root(1+8n))/2 which is the same as your equation, also then rewritable as: y = sqrt(0.25 + 2n) - 0.5
This is precise, so the exact formula would be y = roundup(sqrt(0.25 + 2n) - 0.5) while y = rounddown(sqrt(2n) + 0.5) is a simplification thereof which while not exact, minimises computation.

[jdaw1]

If there are no glasses sheets, by default the WaterBoxes appear on the TN pages. Should there be WaterBoxes on every TN page, on the first TN page from each session, or some other rule? My preference is the first TN page from each session.

[jdaw1]

Done.

Comment welcomed.

[Alex Bridgeman]

Thank you for doing this, it will help to prevent a future hangover.

And for what it is worth, I also agree that we only need water boxes on the first tasting note sheet.

[PhilW]

Looks good. Just first TN page seems to make sense, though not strongly felt.
Can no fruit-branded device users make complex placemats again yet?

[jdaw1]

Can no fruit-branded device users make complex placemats again yet?

There was a problem with ps2pdf.com, believed circumvented as of the version of a few days ago (Ghostscript bug report). If you suspect that it hasn’t been circumvented then please submit or email details.

[jdaw1]

The placemats for the tasting of Sweet-spot Vintages include small sticky labels:


Detail:


As happens at the Bell Unknown-Shipper tastings, the Circlearrays have been replaced by Names (pedantically, with elements of NamesStickyLabels).

Both the top and bottom rows have been replaced. Should it just be one? Should the top row say “Dow 1966”, and only the bottom row say “MPM”?

I say yes: it will be done unless there is cogent objection.

[flash_uk]

Both the top and bottom rows have been replaced. Should it just be one? Should the top row say “Dow 1966”, and only the bottom row say “MPM”?

I say yes: it will be done unless there is cogent objection.

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?

[jdaw1]

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.

[DRT]

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

I agree, or +1, whichever is preferred.

[flash_uk]

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.

[jdaw1]

Five posts moved to a new thread entitled Punch it Chewie.

[PhilW]

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").

[jdaw1]

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.

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.

[jdaw1]

Done (= ‘punched’).

[jdaw1]

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.

[Glenn E.]

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.

[jdaw1]

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.

[Glenn E.]

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

[jdaw1]

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?

[flash_uk]

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.

[jdaw1]

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.