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) <ted.hard...@wlandres.net> Date: 16-Mar-2014 Time: 20:32:50 This message was sent by XFMail -------------------------------------------------
