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
[EMAIL PROTECTED] wrote:
> Send Groff mailing list submissions to
> groff@gnu.org
>
> 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
> [EMAIL PROTECTED]
>
> You can reach the person managing the list at
> [EMAIL PROTECTED]
>
> 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) <[EMAIL PROTECTED]>
> Subject: Re: [Groff] digits in eqn
> To: groff@gnu.org
> Message-ID: <[EMAIL PROTECTED]>
> 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) <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> Subject: Re: [Groff] Bulleted number - How to do???
> To: Groff@gnu.org
> Message-ID: <[EMAIL PROTECTED]>
> 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: [EMAIL PROTECTED]
Tel: +43 (0) 699 19201733
