ThePortForum.com

In the latest placemats, why are the "1963" over the shipper different sizes?

jdaw1 wrote: ↑18:44 Sat 17 Feb 2018Draft of the placemats.

In the above, the 1963 over Ck and Mz are clearly smaller than those over G and D; perhaps some form of proportion since the Mz and Ck are in a smaller font than G and D (being maximised to fit within circles), but it would look better if all the 1963s were the same size font. I don't know how the font size decision for the over-print of the year was determined (I haven't looked, to be fair); perhaps some additional form of control might already provide the capability to enforce a common font size for the 1963s since they are all the same and in the same size area, but if not then perhaps it might be a worthwhile addition.

PhilW wrote:In the above, the 1963 over Ck and Mz are clearly smaller than those over G and D; perhaps some form of proportion since the Mz and Ck are in a smaller font than G and D (being maximised to fit within circles), but it would look better if all the 1963s were the same size font. I don't know how the font size decision for the over-print of the year was determined (I haven't looked, to be fair); perhaps some additional form of control might already provide the capability to enforce a common font size for the 1963s since they are all the same and in the same size area, but if not then perhaps it might be a worthwhile addition.

It was wrong. I will investigate whether it was a user error or a programmer failure (same person; different roles) and suggest a plan, or just effect it.

Instead ofit would have been better to do So it could be a user error.

But I think a change of default for FontSizesRatioAboveBelowOverMin would be advisable, from toSo it could be a programmer error.

A reminder: if font sizes are closer in ratio than FontSizesRatioAboveBelowOverMin (or, mutatis mutandis, FontSizesRatioTitlesMin, then they are set to be the same. It is, in ratio terms, the minimum difference in font size. These two parameters prevent there being many font sizes that differ only slightly.

Objections?

jdaw1 wrote: ↑22:00 Thu 12 Apr 2018

Code: Select all

/FontSizesRatioAboveBelowOverMin 999 def

Done.

Advice wanted on a technical problem, relating to the seed for PostScript’s random numbers, the seed being set with srand.

To fix some bugs and refactor code, each circle’s painting is surrounded by a rrand … srand pair, to put in the stack the current seed, and then to reset the random-number seed to that.

Discussion is happening about a forthcoming Cockburn vertical. The current draft of the placemats has the 1947 and 1967 as:


Observe that the layout of the stars look very similar, with a slight offset. (The eye might start at the top-right of the ‘7’s.) Indeed, relative to the centre of the circle, the stars are identically positioned. Is this:
• Perfection?
• Tolerable?
• Erroneous?

(I admit to dislike—hence this question.)

(Typo fixed.)

jdaw1 wrote: ↑22:57 Fri 20 Jul 2018Observe that the layout of the stars look very similar, with a slight offset. (The eye might start at the top-right of the ‘7’s.) Indeed, relative to the centre of the circle, the stars are identically positioned. Is this:
• Perfection?
• Tolerable?
• Erroneous?

Tolerable, though less than ideal. Why do you keep get/setting the seed, rather than simply setting it at the start of the script (presumably to a fixed value for determinism) and then just using rand throughout thereafter?

PhilW wrote: ↑08:17 Sat 21 Jul 2018Why do you keep get/setting the seed, rather than simply setting it at the start of the script (presumably to a fixed value for determinism) and then just using rand throughout thereafter?

Because sometimes multiple passes of randomness need to be aligned. E.g., in Titles and Overtitles:

jdaw1 wrote: ↑12:26 Sat 21 Jul 2018

PhilW wrote: ↑08:17 Sat 21 Jul 2018Why do you keep get/setting the seed, rather than simply setting it at the start of the script (presumably to a fixed value for determinism) and then just using rand throughout thereafter?

Because sometimes multiple passes of randomness need to be aligned.

"need"? no. "want"? perhaps - I would likely have compromised this one, and not chosen alignment for this, unless it turned out to look poor. With your chosen method you still should only need to cache and reseed while drawing the multiple aspects of a single circle, then continue (though this would place restrictions on the order in which you need to draw elements, or increase the seed cache-ing to one per circle, and then restore to subsequent afterwards, which might be the better route, depending on the currently implemented order of drawing of elements.

PhilW wrote: ↑14:34 Sat 21 Jul 2018"need"? no. "want"? perhaps - I would likely have compromised this one, and not chosen alignment for this, unless it turned out to look poor.

Disagree: this is a need.

PhilW wrote: ↑14:34 Sat 21 Jul 2018With your chosen method you still should only need to cache and reseed while drawing the multiple aspects of a single circle, then continue (though this would place restrictions on the order in which you need to draw elements, or increase the seed cache-ing to one per circle, and then restore to subsequent afterwards, which might be the better route, depending on the currently implemented order of drawing of elements.

Yes. And my question was whether I should. And the answers seems to be ‘yes’.

I actually noticed the non-randomness of the 47 and 67 with merely a glance before reading the rest of the original post.

That said, I don't see it as a problem.

(The overtitles example looks bad to me, and not due to alignment. I would not put the pattern in the overtitle as it makes that word too difficult to read. Especially in the busy parts in 'pe' and 'ia'.)

Decision made: fixed.

That the fix has shortened the code by ten lines increases the likelihood that it was the right thing to do.

Julian - Thomas V over on FTLOP has posted that the ps to pdf converter seems to no longer function with a placemat .ps file. Any ideas what's happened? I suspect the converter is doing something different and doesn't like something in the .ps file. The converter at www.ps2pdf.com also seems to have stopped giving a log which is a bit unhelpful for figuring out the issue.

Link to Thomas V’s comment. I’ve asked the PS➝PDF folks for help.

Mike Hugo wrote:I've sold the ps2pdf.com domain and it is now being run by someone else.

I continue to keep the old service as ps2pdf.org.

I'm not even sure how your email made it to me as the new owner should be receiving email for the dot com domain but perhaps has not updated something.

When I take the document and convert it at ps2pdf.org it does produce a document.
This document also causes my security wrapper to generate a pile of output as this file includes a bunch of code in it that causes the converter to block certain transactions that the file is trying to do. It still creates a final pdf .

Feel free to link to the ps2pdf.org site.

Posted with permission.

Many thanks Julian.

Glenn E. wrote: ↑21:46 Sat 21 Jul 2018
(The overtitles example looks bad to me, and not due to alignment. I would not put the pattern in the overtitle as it makes that word too difficult to read. Especially in the busy parts in 'pe' and 'ia'.)

I agree with this, the pattern in the over label is completely distracting when placed over the vintage stars.

The vintage stars themselves I find a little too cluttered for the overall appearance that I'm distracted with the fill and not the vintage date itself.

g-man wrote: ↑01:13 Tue 28 Aug 2018The vintage stars themselves I find a little too cluttered for the overall appearance that I'm distracted with the fill and not the vintage date itself.

I suggest /ShapesInTitles false def as the perfect solution.

jdaw1 wrote: ↑23:14 Tue 28 Aug 2018

g-man wrote: ↑01:13 Tue 28 Aug 2018The vintage stars themselves I find a little too cluttered for the overall appearance that I'm distracted with the fill and not the vintage date itself.

I suggest /ShapesInTitles false def as the perfect solution.

Or just using a different shape from the options available; I think gman was saying he didn't like that particular fill, and I'm sure we all have our preferences and dislikes in that regard (and false is already the default for /ShapesInTitles in the current placemat.ps anyway, for anyone wondering).

g-man wrote: ↑01:13 Tue 28 Aug 2018

Glenn E. wrote: ↑21:46 Sat 21 Jul 2018 (The overtitles example looks bad to me, and not due to alignment. I would not put the pattern in the overtitle as it makes that word too difficult to read. Especially in the busy parts in 'pe' and 'ia'.)

I agree with this, the pattern in the over label is completely distracting when placed over the vintage stars.

In agreement with the above view, though I realise this is in disagreement with author preference.
Note that there is an equivalent /ShapesInOvertitles parameter, and indeed equivalents for /ShapesInAbovetitles, /ShapesInBelowtitles and /ShapesInPlacenames (noting the latter has missing { } brackets in the definition compared with the peer definitions). These currently all default to be the same as /ShapesInOvertitles but can be changed by the user, so those of us who prefer not to have the pattern in the overtitles can easily change this.

PhilW wrote: ↑09:11 Wed 29 Aug 2018Note that there is an equivalent /ShapesInOvertitles parameter, and indeed equivalents for /ShapesInAbovetitles, /ShapesInBelowtitles and /ShapesInPlacenames (noting the latter has missing { } brackets in the definition compared with the peer definitions).

Note ‘latter’ of two; ‘last’ of three or more.

Geek note: /ShapesInPlaceNames ShapesInTitles def works naturally if ShapesInTitles is a Boolean constant. But if ShapesInTitles is code referencing the likes of WithinTitles, that would fail if referenced in ShapesInPlaceNames. The absence of brackets causes it to fail earlier, and more traceably. So the absence of {} was deliberate.

As requested:

Fabulous. Thank you.

Anybody else?

Please specify pattern, the number of columns (so far everybody has five), and the number of rows (so far everybody has one).

From the Manual:

/Alternating


/Sideways


/Upright

Yes please, alternating.

From the current code:

Geeks might be interested in the comp.lang.postscript thread Mathematical functions as a single Bézier cubic, as used in the Spirals feature (which, note to self, I need to document).