Re: [Groff] fractional point sizes with -ms

[Ted Harding]

On 06-Jan-04 Jon Snader wrote:
> On Tue, Jan 06, 2004 at 03:36:40PM +0100, Werner LEMBERG wrote:
>> 
>> I've investigated how to extend the -ms macro package to support
>> fractional point sizes in a backwards compatible way.  Until now I've
>> only found one solution which is rather ugly but should work with
>> virtually all older documents also.
>> 
>> The idea is to specify `point size * 100':
>> 
>>   .nr PS 1225   \" 12.25pt
>> 
>> Since probably no document will ever ask for a document size of 300pt
>> or larger, it is straightforward to add code like this:
>> 
>>   .ie \n[PS] >= 300 \
>>   .  ps (\n[PS]z / 100u)
>>   .el \
>>   .  ps \n[PS]
>> 
>> Similar code could be added for \n[VS], \n[FPS], and \n[FVS] also.
>> 
>> What do you think?
>> 
> 
> Sounds OK to me.  The only other way I see is to add a register
> to condition the division on:
> 
>       .ie \n[FRAC-PS] > 0 \
>       .    ps (\n[PS]z / 100u)
>       .el \
>       .    ps \n[PS]
> 
> but your method is more transparent and certainly no more objectionable
> than the above.

Sorry not to have been able to come in earlier on this thread!
I have a number of comments.

1. I agree that PS<3 is an unlikely need under most circumstances:
   Indeed the only sort of application I can imagine is creating
   "microfiche" copy from scratch! (I.e. something which by design
   is too small to read with the naked eye, since it is intended to
   be magnified)

2. I'm less happy about PS>300 being unlikely. I agree that, for
   instance, a ".LP" paragraph on A4 paper in PS>300 is not a
   feasible idea (you would only get 3-4 letters per line, and
   only 2 lines per page) -- but what about, for instance, someone
   who is preparing a PostScript/PDF file to be printed on say
   A1-size for a conference Poster Session? A1 has 2.828 times the
   linear dimensions of A4, so a 300-point font on A1 is equivalent to
   106-point on A4, i.e. a 1.47-inch "em" -- not at all unreasonable
   if you want something to really shout at people.

   Nevertheless, it's a somewhat extreme combination of circumstances,
   and many users will probably never encounter it.

   So Werner's suggestion would undoubtedly work for most users
   without causing problems. Only the user who was aware of the
   work-round and needed the fractions would need to use the
   non-compatible invocation ".nr PS 1050", for instance. No-one
   else would notice that the provision was there.

3. However, I'm somewhat unhappy in principle about a solution which
   depends on assumptions about what user's will not want.

   It's somewhat reminiscent of the old limitation on "\smn" which
   was parsed as "\s[m]n" if m>3, on the grounds that the CAT
   phototypesetter didn't go up to 40-point so no user would need it.

4. I have on occasion implemented a work-round of the "\n[PS]"
   problem in -ms (for purposes like tweaking the line-spacing when
   there are difficult tables so as to make text+tables fit cleanly onto
   a page or, sometimes, of text so as to get the bottom lines of
   multicolumn output to line up exactly).

   This was based on the fact that

   .ps mn.pqr

   works as one would hope and expect, and involved using a temporary
   modified copy of s.tmac (or tmac.s in former days) where occurrences
   of

   .ps \\n[PS]

   and the like were replaced by

   .ps \\*[PS]

   where PS is now a string variable. So in using this work-round
   the user has to say

   .ds PS 10.5

   for instance. This is even more "incompatible" than .ns PS 10500!

   It also involves picking through s.tmac for every instance of
   anything that might be affected by this way of doing it, which
   is not trivial!

   Nevertheless, it's a very clean way of doing it and keeps the
   "user interface" in points (which may be fractional). It has no
   limitations (other than arithmetical ones), so the user can
   specify any achievable point size whatever (from microfiche to
   jumbo poster).

5. In many ways, the true underlying issue is that PS is a number
   register which can only hold integers. This means that there is
   the following taxonomy of possible solutions:

   i) The user-interface number registers PS etc should hold
      points*1000 (or similar, as in Werner's solution)

   ii) PS etc should be string registers

   iii) Groff should not be so dependent on integer arithmetic!

Regarding (iii), the integer limitation is directly traceable to
programming issues linked to hardware resources of the time (and the
document CSTR 97 "A Typsetter-independent TROFF" gives interesting
insights). Undoubtedly, one of these days, troff will use floating
point almost everywhere (as I believe TeX does) [though I believe
there has not yet been a call for fractional page numbers]. But
this would mean a complete re-coding of practically everything,
and the result would be a quite different program in which the
"compatibility" issue would have become a fossil.

Anyway, just some thoughts to add fuel to the discussion. I could
certainly work, in practice, with Werner's suggestion.

Best wishes to all,
Ted.


--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 167 1972
Date: 07-Jan-04                                       Time: 15:58:06
------------------------------ XFMail ------------------------------