Re: [Groff] Mission statement

[Ted Harding]

On 16-Mar-2014 18:42:43 Ralph Corderoy wrote:
> Hi Ted,
> 
>> What eqn does when reducing point sizes for these is, at each stage,
>> issue a troff request
>> 
>> .ps (u;\\n[.ps]*7+5/10>?5)
>> 
>> whose effect is that provided the result exceeds 5 [points] use
>> this as the point-size; otherwise use 5 points.
>> 
>> So, for instance, if initially in 10-point this sets the point-size to
>> 10*7[=70]+5[=75]/10 = 7, for a 1st-order superscript.
> 
> I'm not up on this area so this is more of a question than correction...
> Given it's .ps, which is scaled points, why isn't it 10,000, assuming a
> DESC with sizescale of 1,000, which would then make the +5 somewhat
> puny?
> 
>     $ printf '%s\n' '.nr x (u;\n[.ps]*7+5)' '.tm \nx' |
>     > troff
>     70005
>     $
> 
> Cheers, Ralph.

Ralph, your're absolutely correct on this, and it was my oversight,
for which I apologise! (I was getting muddled between points and
scaled points, probably wrong-footed by the ">?5" at the end).

I have run the following check (this shows the successive build-up
of the value of the expression, and prints out each stage):

.de show1
\s[\\$1]
.nr ps0 \\n[.ps]
.nr ps1 (u;\\n[.ps]*7>?5)
.nr ps2 (u;\\n[.ps]*7+5>?5)
.nr ps3 (u;\\n[.ps]*7+5/10>?5)
\\$1\0\0\\n[ps0]\0\0\\n[ps1]\0\0\\n[ps2]\0\0\\n[ps3]
..

.show1  6
.br
.show1  7
.br
.show1  8
.br
.show1  9
.br
.show1 10
.br
.show1 11
.br
.show1 12
.br

The results are:

6 6000 42000 42005 4200
7 7000 49000 49005 4900
8 8000 56000 56005 5600
9 9000 63000 63005 6300
10 10000 70000 70005 7000
11 11000 77000 77005 7700
12 12000 84000 84005 8400
13 13000 91000 91005 9100

So it all comes out exactly as you predicted! And note that for initial
point-size 6 or 7 the final result is less than 5000 scaled points,
therefore will be printed in smaller than 5-point. So the ">?5" does
indeed seem to be puny! (At 5/72000 = 1/14000 of an inch, that would
be invisible -- and well below the 1/1200 resolution of my laserjet
printer).

Perhaps what eqn really should emit is
.ps (u;\\n[.ps]*7+5/10>?5000)
if the intention is to limit the smallest printed size to 5 points
(at which point it starts to become illegible to the naked eye).

But that's what 'eqn' emits. The following command-line input:

eqn << EOT | less
.EQ
AAA sup BBB
.EN
EOT

produces a stream of output from which the following is excerpted:

.nr 0z8 \n[.ps]
.ps (u;\n[.ps]*7+5/10>?5)
.nr 0Z8 \n[.ps]
[...]
.as1 10
\&\E*[0sfont]\f[I]\s'\En[0ssize]u'\,A\&A\&A\/\Z\(EQ\v'-\n[0p8]u'
\s[\n[0Z8]u]\,B\&B\&B\/\s[n[0z8]u]\(EQ\h'\n[0w8]u-\n[0w3]u'\E*[0rfont]

"\n[0ssize]" is the ambient font-size, and "AAA" ia printed in that
(by "\s'\En[0ssize]u'\,A\&A\&A"); then there is "\s[\n[0Z8]u]\,B\&B\&B"
which prints "BBB" in the size set by "\s[\n[0Z8]u]" which in turn was
set by
  .ps (u;\n[.ps]*7+5/10>?5)
  .nr 0Z8 \n[.ps]

Interesting! And this all confirms the point you made in your follow-up
posting:

  "The +5 is fine, it's only there for the /10. What's puzzling me
   now is the >?5 since that's not "otherwise use 5 points" but
   5 scaled points?"

Thanks for the comments. It shows that I was over-reacting to the
absence of non-integer arthmetic when it comes to setting point sizes
(though the point I raised in my original mail about slowing down the
rate of reduction with successive super/subscripting is a fair one,
I think).

With best wishes,
Ted.

-------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Date: 16-Mar-2014  Time: 20:32:50
This message was sent by XFMail
-------------------------------------------------