[Groff] Piic behaviour

[Udo Krebelder]

Hi,

I have a strange problem with pic.  Here is the code:

********************************
.de PS
..
.de PE
..
.PS
scale = 25.4

# draw right dimension arrow
define LinR {[
        X: line from $1 right 10
        Y: line from $2 right 10
        line <--> from X.center to Y.center sprintf("%g", $3) ljust
]}

# draw upper dimension arrow
define LinU {[
        X: line from $1 up 10
        Y: line from $2 up 10
        line <--> from X.center to Y.center sprintf("%g", $3) above
]}

A: box wid 80 ht 100

LinR(A.ne, A.se, A.ht)
LinU(A.nw, A.ne, A.wid)

.PE
**********************************

I am not shure if i do something wrong, but the result are not two
dimension arrows on the right and upper side of the rectangle
(groff version 1.19.2).

Any ideas?

Udo


address@hidden wrote:
> Send Groff mailing list submissions to
>       address@hidden
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>       http://lists.gnu.org/mailman/listinfo/groff
> or, via email, send a message with subject or body 'help' to
>       address@hidden
> 
> You can reach the person managing the list at
>       address@hidden
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Groff digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: digits in eqn ( (Ted Harding))
>    2. Re: Bulleted number - How to do??? (andlabs)
>    3. Number registers (andlabs)
>    4. Re: Number registers (Nick Stoughton)
>    5. Re: Number registers (andlabs)
>    6. Re: Number registers (andlabs)
>    7. Re: Number registers (andlabs)
>    8. Re: Number registers (Werner LEMBERG)
>    9. Re: digits in eqn (Werner LEMBERG)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 02 Aug 2007 23:34:47 +0100 (BST)
> From: (Ted Harding) <address@hidden>
> Subject: Re: [Groff] digits in eqn
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=iso-8859-1
> 
> 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 ------------------------------
> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Thu, 2 Aug 2007 16:41:24 -0700 (PDT)
> From: andlabs <address@hidden>
> Subject: Re: [Groff] Bulleted number - How to do???
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=UTF-8
> 
> 
> Why do you need it in a circle when you can just use the ms .IP or mm's
> built-in numbering along with a normal number?
> 
> If you can't work with the above, then get ready, because either you need
> graphics commands and absolute placement - which are both HARD (especially
> absolute placement).
> 
> 
> Ruediger Haertel wrote:
>> Hello,
>>
>> I am in the need of bulleted numbers, ie. a filled circle with a number in
>> it. 
>> Imortant to me is, that I can use such a bulleted numer every where in 
>> floating text. But it is not necessary to have it in a table for now.
>>
>> Three possible solutions came to mind:
>> a) a font with special glyphs of this kind
>> b) pic
>> c) postscript
>>
>> a) I only know of fonts that have the numbers 1..10. I need also highr 
>> numbers. So, this is not usable in my case.
>>
>> b) Pic would work, but always places the figure in the middle. I couldn't 
>> workaround this 
>>
>> c) Postscript would work, but I cannot figure out how to do the placement 
>> right.
>>
>>
>> Here is my approach with pic and postscript. Maybe someone knows a way how
>> to 
>> do it.
>>
>> -------8<---------8<----------------
>>
>> .NH
>> Point in Postscript
>> .LP
>> blah blah blah
>> .de ci
>> \X'ps: exec \\$1 \\$2 translate gsave  1 0 0 setrgbcolor 0 0 8 0 360 arc
>> fill 
>> 1 1 1 setrgbcolor -2 2 moveto (\\$3) show grestore 0 0 translate
>> ..
>> .ci 50 50 2
>> blubb blubb blubb
>> .NH
>> Point in pic
>> .LP
>> blah blah blah
>> .PS
>> .sp -2.4
>> move left 4.0
>> circle radius 0.1 "\s-2\fB\m[white]2\m[black]\f[]\s+2" shaded "red" 
>> outline "red"
>> .PE
>> blubb blubb blubb
>> -------8<---------8<----------------
>>
>>
>>
>> Rüdiger
>>
>>
>>
>>
>>
>>
>>
> 

-- 
Dipl.-Ing. Udo Krebelder                Email:   address@hidden
                                        Tel: +43 (0) 699 19201733