groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] digits in eqn


From: Ted Harding
Subject: Re: [Groff] digits in eqn
Date: Thu, 02 Aug 2007 23:34:47 +0100 (BST)

On 02-Aug-07 08:26:39, Ted Harding wrote:
> On 01-Aug-07 22:35:29, Ralph Corderoy wrote:
>> [...]
>> Hmm, don't know about that.  I did however have a look at eqn's
>> output and I think it's the \, that's causing the effect.
>> 
>>     $ cat ted.tr
>>     .nr DD 0
>>     .EQ I
>>     21 ~~=~~ 3 times 7
>>     .EN
>>     .br
>>     .EQ I
>>     22 ~~=~~ 2 times 11
>>     .EN
>>     $ groff -e -ms ted.tr >ted.ps     # Has fault.
>>     $ eqn ted.tr | sed 's/\\,//g' | groff -ms >ted2.ps
>> 
>> ted2.ps looks OK.  It may be that the \/ that's also in eqn's output
>> can cause problems too sometimes, I don't know and haven't the time
>> to investigate further.
>> 
>> groff_diff(7) describes these escapes;  hopefully this email gives a
>> clue.
> 
> Thanks, Ralph. It is indeed the \. (and not the \/) which is doing it.
> 
> In the sort of eqn context where italic sharacters (used in symbols)
> switches automatically to roman (for digits), this is certainly a
> feature at the point of the switch, since it makes for nice spacing
> at that point.
> 
> However, eqn uses "\,\/" between digits in a multi-digit numbers, and
> this has to be a bug. To get an extreme impression:
> 
> .EQ L
> 121131114111151111161111117111111181111111191111111110
> .EN
> 121131114111151111161111117111111181111111191111111110
> 
> In other words, a long multi-digit number in an equation will
> be much shorter than the same number in surrounding non-equation
> text. That can only be bad style!
> 
> What eqn does is to separate each digit from its successor with
> a "\,\/" ; it is the "\," which has this effect, not the "\/2.
> 
> At most, this only needs to be done at the very beginning of
> the number, and possibly at its end. Doing it between all the
> digits is simply wrong!
> 
> This does not happen if an alphabetical string is enclosed
> in a single "roman":
> 
> .EQ L
> roman {ABCDEFGHIJKLMNOPQRSTUVWXYZ}
> .EN
> ABCDEFGHIJKLMNOPQRSTUVWXYZ
> 
> so apparently arises because eqn sees each single digit as an
> object where there is a transition *to* roman when the digit
> is encountered, followed by a transition *from* roman back
> to the "italic" font as soon as the digit has been emitted,
> even in an unbroken string of digits (thus each digit is
> separated from its successor by "\,\/").
> 
> This has to be wrong: a multi-digit number which occurrs in
> an equation should look exactly the same as the same number
> in non-eqn text. (Of course, for that precise usage, it is
> straightforward to use roman{"12345..."}, as I usually do
> anyway is there's a "." in the number; but the underlying
> behaviour is inappropriate).
> 
> I'll try to look into this, to see if it's possible to stop
> it from happening.

I've now had a look at it. What happens when eqn sets
.EQ
123
.EN
for instance, is that it outputs

\f[R]\,1\/\fP\f[R]\,2\/\fP\f[R]\,3\/\fP

Each "\/" would cause extra space (can be negative) equal to
the "italic-correction", in the "charset" section of the font
file, to be added after the preceding character, before the
following character is printed. However, in the case of the
digitss (in Times-Roman) this is 0 for all integers. So "\/"
has no effect in this case.

Each "\," causes extra space (usually negative) equal to the
"left-italic-correction" to be added before the following character
before the following character is printed. In the case of the
digits, this is always negative:

digit it-corr left-it-corr
0     0        -24
1     0       -111
2     0        -30
3     0        -43
4     0        -12
5     0        -32
6     0        -34
7     0        -20
8     0        -56
9     0        -30

The net effect is that a digit is shifted left, and "1" is shifted
left most (approx em/9).

I have now thought of a work-round:

.EQ
define 1 %{roman "1"}%
define 2 %{roman "2"}%
define 3 %{roman "3"}%
define 4 %{roman "4"}%
define 5 %{roman "5"}%
define 6 %{roman "6"}%
define 7 %{roman "7"}%
define 8 %{roman "8"}%
define 9 %{roman "9"}%
define 0 %{roman "0"}%
.EN

Then, for instance
.EQ L
2 1 ~~=~~ 3 times 7
.EN
.EQ L
2 2 ~~=~~ 2 times 1 1
.EN
comes out as it should. For long numbers, one can "spell them out":
$ 3 . 1 4 1 5 9 2 6 $ (provided one also has $define . roman{"."}$);
but in fact I can't think of many comtexts where one would not use
$roman{"3.1415926"}$ instead!

Certainly this seems to work OK for supescripts and subscripts;
usually it even results in an improvement in the layout, though
occasionally it may cause a slightly poorer layout.

Compare (with and without the above definitions):

.EQ L
theta sub 1 sup 2 theta sub 2
.EN

and similarly compare

.EQ L
{partial b sub 1} over {partial theta sub 1}
.EN

and

.EQ L
{partial b sub 1} over {partial theta sub 2}
.EN


Given that the problem arises when eqn outputs

\f[R]\,1\/\fP\f[R]\,2\/\fP\f[R]\,3\/\fP

(i.e. puts "\," in front of evey digit, thereby shifting it left),
I have tried to locate where in the eqn source code this is done.
However, I have failed to find it! Hence the above work-around.

Any further thoughts or coments by anyone would be welcome.

Best wishes to all,
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 094 0861
Date: 02-Aug-07                                       Time: 23:09:52
------------------------------ XFMail ------------------------------




reply via email to

[Prev in Thread] Current Thread [Next in Thread]