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)