xfig + shading | f2p | pic => shaded objs
Brian Field
I've recently installed the xfig package. Besides the xfig drawing
package, there are two filters, f2p (fig to pic) and f2ps (fig to
postscript). The f2p filter works fine, except that shaded objects
lose their shading. The doc for f2p says:
BUGS
Filling of closed objects is ignored. It would be possible to
generate pic instructions to produce some form of filling in f2p,
but the filling feature really needs to be added to pic.
Has anyone hacked f2p or pic to produce shaded objects?
Thanks
Brian
fi...@cs.pitt.edu
nils-peter.nelson
THe DWB 3.1 and 3.2 versions work correctly.
pic relies on the \X feature of troff to smuggle
raw PostScript through to the device. pic alone
may not solve the problem; troff and the postprocessor
for PostScript (dpost in DWB) must cooperate.
Jonathan Knight
> Has anyone hacked f2p or pic to produce shaded objects?
gpic (the GNU version of pic bundled within groff) has a 'fill'
verb for various shapes.
--
______ JANET :jona...@uk.ac.keele.cs Jonathan Knight,
/ BITNET:jonathan%cs.kl.ac.uk@ukacrl Department of Computer Science
/ _ __ other :jona...@cs.keele.ac.uk University of Keele, Keele,
(_/ (_) / / UUCP :...!ukc!kl-cs!jonathan Staffordshire. ST5 5BG. U.K.
Chris Lewis
|In article <11...@pitt.UUCP>, fi...@cs.pitt.edu (Brian Field) writes:
|> I've recently installed the xfig package. Besides the xfig drawing
|> package, there are two filters, f2p (fig to pic) and f2ps (fig to
|> postscript). The f2p filter works fine, except that shaded objects
|> lose their shading. The doc for f2p says:
|> BUGS
|> Filling of closed objects is ignored. It would be possible to
|> generate pic instructions to produce some form of filling in f2p,
|> but the filling feature really needs to be added to pic.
|THe DWB 3.1 and 3.2 versions work correctly.
|pic relies on the \X feature of troff to smuggle
|raw PostScript through to the device. pic alone
|may not solve the problem; troff and the postprocessor
|for PostScript (dpost in DWB) must cooperate.
Groff and the RS/6000 ditroff (which is, I believe, BSD ditroff) and my
psroff all support the following extended \D draw commands over DWB 2.x
troff:
\D'f nnn' specify a fill (shading) level
\D'p x1 y1 x2 y2 x3 y3 ...' polygon
\D'[C|E|P] ...' filled circle/ellipse/polygon
\D't nnn' set line thickness
I don't know how groff's or BSD's pic have been extended to support these.
[Liam? How about SQTroff?]
These troffs actually understand the contents of the \D, for they
have to figger out the current point after they've been executed.
Is this what you mean by DWB 3.[12] "work[ing] correctly"? Or is pic
using \X to pass raw postscript *past* troff and directly into dpost?
[Ugh. Device dependent!]
--
Chris Lewis; UUCP: ...!{cunews,uunet,latour}!ecicrl!clewis;
DOMAIN: cle...@ferret.ocunix.on.ca; Phone: Canada 613 832-0541
Psroff info: psroff-...@ferret.ocunix.on.ca
Ferret mailing list: ferret-...@ferret.ocunix.on.ca
nils-peter.nelson
Chris Lewis asked:
Is this what you mean by DWB 3.[12] "work[ing] correctly"? Or is pic
using \X to pass raw postscript *past* troff and directly into dpost?
[Ugh. Device dependent!]
===
Indeed, raw PostScript is sneaked under troff's insentient nose.
The orginal ditroff model presume a variety of reasonably
equivalent output devices, each with a postprocessor/filter:
APS, C/A/T, Mergenthaler, Xerox, Imagen, etc. Filling was not
a common property of these, so the capability was not put into
the \D function. The current DWB has several features which
*only* work with PostScript, and these tend to be implemented
by \X, since they won't work with other devices anyway.
These features include: PostScript pictures (from Picasso,
troff | dpost, Harvard Graphics, Macintosh, scanned images),
color, page-at-a-time rotation, Latin 1 (ISO 8859-1) character
set. If I had it to do over again (not to be ruled out!) I
might argue for troff to emit PostScript directly, then have
filters for PostScript-to-PCL, -to-X, -to-Impress, etc.
Unless you have implemented filling for all those ugly old
non-PostScript filters, \D is only cleaner, not better.
Yuan Liu
#
#Groff and the RS/6000 ditroff (which is, I believe, BSD ditroff) and my
#psroff all support the following extended \D draw commands over DWB 2.x
#troff:
#
# \D'f nnn' specify a fill (shading) level
# \D'p x1 y1 x2 y2 x3 y3 ...' polygon
# \D'[C|E|P] ...' filled circle/ellipse/polygon
# \D't nnn' set line thickness
#
#I don't know how groff's or BSD's pic have been extended to support these.
#[Liam? How about SQTroff?]
#
I don't know what version our ditroff is, but it seems to be modified with
the goal of supporting gremlin (anyone out there still using this thing?).
Anyway, in gremlin, you can fill polygons with 8 different stipple patterns.
This is translated into ditroff code of the following form:
\D'p n dx1 dy1 dx2 dy2 ...' fill polygon with pattern "n".
\D'P n dx1 dy1 dx2 dy2 ...' fill polygon with pattern "n" and draw border
of polygon with the current line thickness.
Yuan Liu
l...@cs.umd.edu
Greg A. Woods
> |THe DWB 3.1 and 3.2 versions work correctly.
> |pic relies on the \X feature of troff to smuggle
> |raw PostScript through to the device. pic alone
> |may not solve the problem; troff and the postprocessor
> |for PostScript (dpost in DWB) must cooperate.
This is a gross and un-acceptable hack! I could understand one making
troff emit PS directly, but forcing a pre-processor to depend upon a
particular post-processor in this way is pure ugly! (Though I suppose
if one could back-track to determine what pic was trying to accomplish
by interpreting the PS, then translating it as appropriate, it could
be worked around.) Yuck!
> Groff and the RS/6000 ditroff (which is, I believe, BSD ditroff) and my
> psroff all support the following extended \D draw commands over DWB 2.x
> troff:
>
> \D'f nnn' specify a fill (shading) level
> \D'p x1 y1 x2 y2 x3 y3 ...' polygon
> \D'[C|E|P] ...' filled circle/ellipse/polygon
> \D't nnn' set line thickness
>
> I don't know how groff's or BSD's pic have been extended to support these.
> [Liam? How about SQTroff?]
>
> These troffs actually understand the contents of the \D, for they
> have to figger out the current point after they've been executed.
No, sorry Chris, neither DWB 2.0 troff, nor BSD ditroff (as
implemented in SysVr4.0) understand the contents of "\D". For example
"\D'c 1i'" and "\D'C 1i'" produce exactly the same output, except, of
course, for the case of the "c". There's no position adjustment
afterwards. It is pic that understands the commands it is giving, and
thus how much room it must tell troff to leave (check the output of
pic to see how).
Both DWB troff and BSD ditroff (as implemented in SysVr4.0), will pass
the given "\D" commands through with the appropriate device resolution
translations for all arguments (which must be numeric).
As such, it is possible to implement any of these commands in the
post-processor (and any pre-processor), without doing anything to troff.
I assume the documented commands for "\D" should be implemented for each
post-processor, and will be those used by "classic" pic in most cases.
(I think the DWB 2.0 pic still uses "\l" and "\L" in preference to
"\D'l dh dv'".)
However, SQtroff does indeed recognize and interpret the contents of
drawing commands, can recognize an invalid number of arguments for
drawing commands, and appears to be adjusting for the size of the
object drawn by producing appropriate movement commands afterwards.
However, SQtroff doesn't appear to support all of the above
extensions. It does seem to have "\D'f n'" and "\D't n'", though I'm
not sure if it uses them for the same features.
(Corrections will only be accepted if accompanied by very strong
evidence. The above conclusions are based on direct observation of
the tools in question.)
--
Greg A. Woods
woods@{eci386,gate,robohack}.UUCP VE3TCP Elegant Comm. & UniForum Canada
+1-416-443-1734 [h] +1-416-595-5425 [w] Toronto, Ontario; CANADA
Political speech and writing are largely the defense of the indefensible-ORWELL
Chris Lewis
>In article <25...@ecicrl.ocunix.on.ca> cle...@ferret.ocunix.on.ca (Chris Lewis) writes:
>> In article <1991Sep17.1...@cbnewsl.cb.att.com> n...@cbnewsl.cb.att.com (nils-peter.nelson) writes:
>> |THe DWB 3.1 and 3.2 versions work correctly.
>> |pic relies on the \X feature of troff to smuggle
>> |raw PostScript through to the device. pic alone
>> |may not solve the problem; troff and the postprocessor
>> |for PostScript (dpost in DWB) must cooperate.
>This is a gross and un-acceptable hack! I could understand one making
>troff emit PS directly, but forcing a pre-processor to depend upon a
>particular post-processor in this way is pure ugly!
Agreed. Fill is obviously associated with the already existing \D
commands, and is something that *can* be implemented on printers other
than Postscript. The fact that is hasn't is due to laziness more than
anything else ;-) It seems rather bizarre to me that such a trivial
printer-independent extension to \D would be ignored in favour of making
pic heavily printer dependent. I mean, if you weren't going to build
it into pic, I could see doing it this way. But by doing this junk in
pic, you've blown your processing model apart. Everybody else did it
right.
>> Groff and the RS/6000 ditroff (which is, I believe, BSD ditroff) and my
>> psroff all support the following extended \D draw commands over DWB 2.x
>> troff:
>> \D'f nnn' specify a fill (shading) level
>> \D'p x1 y1 x2 y2 x3 y3 ...' polygon
>> \D'[C|E|P] ...' filled circle/ellipse/polygon
>> \D't nnn' set line thickness
>> These troffs actually understand the contents of the \D, for they
>> have to figger out the current point after they've been executed.
>No, sorry Chris, neither DWB 2.0 troff, nor BSD ditroff (as
>implemented in SysVr4.0) understand the contents of "\D". For example
>"\D'c 1i'" and "\D'C 1i'" produce exactly the same output, except, of
>course, for the case of the "c". There's no position adjustment
>afterwards. It is pic that understands the commands it is giving, and
>thus how much room it must tell troff to leave (check the output of
>pic to see how).
Have you ever tried issuing \D commands directly without intervening
positioning? Obviously not. For my testing has shown that *clearly*
troff does do stuff with the contents of the \D aside from scaling.
At least some versions of ditroff will emit two numbers in the ditroff
format output from a "\D'c", where the second number should be ignored
(as noted in the groff Postscript driver). And finally, the test file
below behaves just as if troff itself calculates the new x:y position:
|.sp |1i
|hello, this is a line:\D'l 1i 1i'\D'l 1i -1i'\D'C 1i'
|.sp |2.5i
|An Elipse!\D'e 2i 1i'\D'l 1i 0'\D'c 1i'\D'E .5i 1i'\D't 40'\D'e.5i 1i'
|.sp |4i
|An arc:\D'a 1i 0 1i 0'
|.sp |5i
|Squiggly: \D'~50p -50p 50p +100p 50p -100p'
|.sp |6i
|hello\D'c 1c'there\D'e .5i 1.5i'
|.sp |7.i
|hello
|\h'|3.5i'\v'|1i'hello
|.sp |8i
|Something: \D'p 0i .5i .5i 0i 0i -.5i'\h'.25i'\D'P 0i .5i .5i 0i 0i -.5i'
|.sp |8.6i
|Something: \D'f 500u'\D'P 0i .5i .5i 0i 0i -.5i'\h'.25i'\D'f 950u'\D'P 0i .5i .5i 0i 0i -.5i'
Ie: the lines drawn in the second line connect together. Try it Greg.
[I don't expect the p/P/f/t directives to work in your jury-rigged troff ;-)]
>(Corrections will only be accepted if accompanied by very strong
>evidence. The above conclusions are based on direct observation of
>the tools in question.)
Ditto, Greg. Try the above.
The behaviour I observed in AIX 3 ditroff (BSD ditroff I believe) is
identical to that called out for the drawing commands as specified in the
ditroff output format document. And appears to be done in groff (I have
the source but no C++ compiler to try it out) Ie: the current position after
a line, arc or squiggle it is the end of the line. For an ellipse or circle,
it's the opposite side of the object. Never did figger out what it is with
polygons.
This is the behaviour that psroff supports with C/A/T troff. Yes, C/A/T
troff! And ditroff too of course.
James Clark
Groff and the RS/6000 ditroff (which is, I believe, BSD ditroff) and my
psroff all support the following extended \D draw commands over DWB 2.x
troff:
\D'f nnn' specify a fill (shading) level
\D'p x1 y1 x2 y2 x3 y3 ...' polygon
\D'[C|E|P] ...' filled circle/ellipse/polygon
\D't nnn' set line thickness
I don't know how groff's or BSD's pic have been extended to support these.
[Liam? How about SQTroff?]
These troffs actually understand the contents of the \D, for they
have to figger out the current point after they've been executed.
GNU troff and the other troff's I've experimented with don't really
understand the contents of \D, although they do adjust the current
point after a \D. Given a \D escape sequence of the form
\D'c x1 y1 x2 y2 ...'
(where c is any character) the current horizontal position will be
increased by x1+x2+... and the current vertical position by y1+y2+...
The only exception to this is \D'e ...'; in this case the current
vertical position is not changed.
The extended \D commands supported by groff were designed so that they
required extensions only to the postprocessors rather than to troff
itself. GNU pic uses these extended \D commands to provide a `fill'
attribute, optional filled arrowheads, and control over line thickness
using a `thickness' attribute instead of the .ps hack (although the
.ps hack can still be used.) The idea is that you can, if you want,
use GNU pic with Unix troff. The groff \D commands are fully
documented in groff_out(5) in the groff distribution.
BSD ditroff supports a rather different set of extended \D commands,
designed mainly to support gremlin. These do not fit into the pattern
described above, and they require that troff understand the contents
of the \D. In particular the polygon drawing commands have a first
argument which indicates the stipple font to be used to fill the
polygon, and there's also a new `st' request to set the stipple font.
I didn't much care for this, so I designed my own extended \D commands
for groff, instead of implementing the BSD extensions.
The disadvantage of the groff approach is that it is rather
unintuitive for the \D't n' and \D'f n' commands to change the current
position. If I were designing them again, I think I would use \X'...'
commands to control the current line thickness and fill level.
James Clark
j...@jclark.uucp
Greg A. Woods
> Have you ever tried issuing \D commands directly without intervening
> positioning? Obviously not. For my testing has shown that *clearly*
> troff does do stuff with the contents of the \D aside from scaling.
Hmm... I sure have, and I've just finished many more tests and a fair
bit more reading.
Yes, troff does to some minimal extent "understand" the arguments to
drawing commands. As documented, the "current" position after each
function is supposed to be the "end" of the line drawn, which for
circles and ellipses is at the right side (i.e. Hpos += diam), but
with the same baseline, thus while the horizontal delta of the circle
will be "clear", the vertical delta must be compensated for by manual
.sp's.
The spline, and the arc, and it appears any "un-defined" drawing
function, will try to move the current position to the "end" of the
line by summing the horizontal and vertical deltas given.
Note the troff(5) man page suggests that the spline curve is between
the x,y pairs given, starting at the current location and ending at the
final x,y pair. However the DWB-2.0 troff Technical Discussion (sec.
12.4) claims the pairs are deltas, as in the arc. Given the apparent
"current position" behavior, I think troff(5) must be wrong. This
also appears to be backed up by the tpscript implementation of
draw_spline(), which works fine together with pic.
As you can see, because of the default behavior of "un-defined"
functions, it appears that the polygon function can be implemented
in such a way that the "current position" after the polygon will be as
it would for a spline.
However, a '.br' will simply advance one line forward, as can be
observed by using the following test sequence:
Hello \D'l 1i 1i' world!
.br
GOOD DAY, EH!
The "world!" should appear at the "end" of the diagonal line which
starts at the end of "Hello", however the second line will appear
directly (i.e. at the left margin) 1v below the "Hello", and will run
over top of the line, thus at least the horizonatal part of the
"current position" is *NOT* globally updated by some drawing functions.
In fact, even without the .br, the second line of a filled paragraph
will also appear directly 1v below "Hello".
This is contrary to what I would have expected if troff were properly
interpreting the arguments of the drawing functions.
This is the behavior my earlier claims were based on.
It is also interesting to note that the spline function (\D'~'), and
thus any "un-defined" functions, default to being given at least two
parameters if given up to two arguments, or else are always given an
even number of parameters, and if given an odd number of arguments,
the extra parameter will have an un-defined value. All parameters are
scaled, which makes some extended functions difficult to implement.
BTW, I observe identical behavior from the troff in SysVr4.0 in all
cases.
I also note that \D'l x y' always seems to produce:
Dl x y .
and nothing I do seems to change the last parameter from being a '.'.
I presume the '.' is meant to be the "character" to be used for line
drawing as in the \l and \L commands, though it is not documented as
even being present in output by troff(5).
Unfortunately the troff(5) man page appears to be missing from the
Amiga version of SysVr4.
> [I don't expect the p/P/f/t directives to work in your jury-rigged troff ;-)]
My troff is "stock" DWB-2.0! :-)
My version of tpscript does seem to botch the "current position"
rules, though that is part of what my on-going work is trying to fix.
This "botch" does not seem to affect pic's output, and Chris' "\D'l 1i
1i'\D'l 1i -1i'" did work correctly.
There was some code in there for some "BERK" drawing extensions, as if
the original author intended to support them, but it is not complete.
Chris Lewis
>In article <26...@ecicrl.ocunix.on.ca> cle...@ferret.ocunix.on.ca (Chris Lewis) writes:
>> Have you ever tried issuing \D commands directly without intervening
>> positioning? Obviously not. For my testing has shown that *clearly*
>> troff does do stuff with the contents of the \D aside from scaling.
>Hmm... I sure have, and I've just finished many more tests and a fair
>bit more reading.
Thanks for confirming what I was saying...
>Yes, troff does to some minimal extent "understand" the arguments to
>drawing commands. As documented, the "current" position after each
>function is supposed to be the "end" of the line drawn, which for
>circles and ellipses is at the right side (i.e. Hpos += diam), but
>with the same baseline, thus while the horizontal delta of the circle
>will be "clear", the vertical delta must be compensated for by manual
>.sp's.
But there isn't a vertical delta with a circle or ellipse.
The difficulty in trusting troff's idea of current position
is why, for example, that PIC seems to mark a position in the upper
left corner of a display, and then issue dX/dY's from there for each
"clause" of its drawing. Ie: PIC isn't relying on being able to
incrementally space around a diagram. Sort of like vi "going home"
and moving the cursor from there for each word it outputs.
>The spline, and the arc, and it appears any "un-defined" drawing
>function, will try to move the current position to the "end" of the
>line by summing the horizontal and vertical deltas given.
All this behaviour is what I've observed and implemented in psroff's
emulation of ditroff drawing commands whilst using C/A/T troff.
>Note the troff(5) man page suggests that the spline curve is between
>the x,y pairs given, starting at the current location and ending at the
>final x,y pair. However the DWB-2.0 troff Technical Discussion (sec.
>12.4) claims the pairs are deltas, as in the arc. Given the apparent
>"current position" behavior, I think troff(5) must be wrong. This
It is wrong. Depends on which troff(5) you read. All implementations
I've seen have the spline curve numbers as x:y incremental deltas.
>also appears to be backed up by the tpscript implementation of
>draw_spline(), which works fine together with pic.
And groff source and psroff....
>As you can see, because of the default behavior of "un-defined"
>functions, it appears that the polygon function can be implemented
>in such a way that the "current position" after the polygon will be as
>it would for a spline.
Got kinda confused by circles, I'll have to get polygons working
this way.
>However, a '.br' will simply advance one line forward, as can be
>observed by using the following test sequence:
> Hello \D'l 1i 1i' world!
> .br
> GOOD DAY, EH!
>The "world!" should appear at the "end" of the diagonal line which
>starts at the end of "Hello", however the second line will appear
>directly (i.e. at the left margin) 1v below the "Hello", and will run
>over top of the line, thus at least the horizonatal part of the
>"current position" is *NOT* globally updated by some drawing functions.
I think logical newlines probably are what's screwing up the positioning.
Again, perhaps, the reason for PIC's behaviour. Ie: there's some sort
of global and local h & v.
>It is also interesting to note that the spline function (\D'~'), and
>thus any "un-defined" functions, default to being given at least two
>parameters if given up to two arguments, or else are always given an
>even number of parameters, and if given an odd number of arguments,
>the extra parameter will have an un-defined value. All parameters are
>scaled, which makes some extended functions difficult to implement.
I've seen this before. It happens even with the "defined" functions -
this behaviour is noted in the groff source (eg: \D'c' always
emits two numbers).
>I also note that \D'l x y' always seems to produce:
> Dl x y .
>and nothing I do seems to change the last parameter from being a '.'.
>I presume the '.' is meant to be the "character" to be used for line
>drawing as in the \l and \L commands, though it is not documented as
>even being present in output by troff(5).
Don't remember if I've seen that before, but both groff and psroff
allow for it.
>> [I don't expect the p/P/f/t directives to work in your jury-rigged troff ;-)]
>My troff is "stock" DWB-2.0! :-)
I was actually referring to your tpscript...
>My version of tpscript does seem to botch the "current position"
>rules, though that is part of what my on-going work is trying to fix.
I believe that this depends on the version of ditroff - I suspect
some always resync the H & V before each drawing command. Further,
PIC, from my recollection, appears to manually force positioning
before each \D. I'm not really convinced at the present time whether
psroff will work consistently without the repositioning when running
from ditroff output. But, given the way \D is emulated for C/A/T troff,
it should always be correct.
>This "botch" does not seem to affect pic's output, and Chris' "\D'l 1i
>1i'\D'l 1i -1i'" did work correctly.
>There was some code in there for some "BERK" drawing extensions, as if
>the original author intended to support them, but it is not complete.
Never did find out what they were supposed to look like.
--
Chris Lewis; cle...@ferret.ocunix.on.ca; Phone: Canada 613 832-0541
Psroff 3.0 is in comp.sources.unix NOW! YAHOO!!!!!!!
Ferret mailing list: ferret-...@ferret.ocunix.on.ca
Chris Lewis
>In article <25...@ecicrl.ocunix.on.ca> cle...@ferret.ocunix.on.ca (Chris Lewis) writes:
> Groff and the RS/6000 ditroff (which is, I believe, BSD ditroff) and my
> psroff all support the following extended \D draw commands over DWB 2.x
> troff:
> \D'f nnn' specify a fill (shading) level
> \D'p x1 y1 x2 y2 x3 y3 ...' polygon
> \D'[C|E|P] ...' filled circle/ellipse/polygon
> \D't nnn' set line thickness
> These troffs actually understand the contents of the \D, for they
> have to figger out the current point after they've been executed.
>GNU troff and the other troff's I've experimented with don't really
>understand the contents of \D, although they do adjust the current
>point after a \D.
That's what I meant by "understand the contents".
>the current horizontal position will be
>increased by x1+x2+... and the current vertical position by y1+y2+...
>The only exception to this is \D'e ...'; in this case the current
>vertical position is not changed.
Right. That's what psroff does.
>The groff \D commands are fully
>documented in groff_out(5) in the groff distribution.
And where did you think I found out about them? ;-) Didn't borrow
any code, just implemented the functionality.
>BSD ditroff supports a rather different set of extended \D commands,
>designed mainly to support gremlin. These do not fit into the pattern
>described above, and they require that troff understand the contents
>of the \D. In particular the polygon drawing commands have a first
>argument which indicates the stipple font to be used to fill the
>polygon, and there's also a new `st' request to set the stipple font.
>I didn't much care for this, so I designed my own extended \D commands
>for groff, instead of implementing the BSD extensions.
Psroff follows you more than Berkeley, for I don't have sufficient
info about the BSD stuff.
>The disadvantage of the groff approach is that it is rather
>unintuitive for the \D't n' and \D'f n' commands to change the current
>position. If I were designing them again, I think I would use \X'...'
>commands to control the current line thickness and fill level.
Or, orthogonalize a bit, and have some sort of indicator in the \D
to indicate no motion. The problem with \X'...' is that it is
passthru (like \!), and the contents of the \X'...' depends on what
you're driving. Fill and line thickness, since they're obvious
extensions to \D, are something you should be able to define in a
printer-independent fashion. Having f and t move the current
position isn't a big problem because pic resyncs the x and y position
before drawing commands anyways.
If I had my druthers, I wish that AT&T had defined \! and \X
a bit more in DWB 2, and specified conventions for passthru and file
inclusion (and a few others possibly), thought a bit more about \D,
and we'd not be in this stupid mess of different conventions for
these things. And you'd not have had to invent your own.
(nor me for that matter)