Please convert the information in your email into a patch for
grops.man, together with the example.
Done (more or less). I've also taken the liberty to restructure the
grops manpage somewhat, i.e., begin the Usage section with the
discussion of the general workings of grops instead of
Please convert the information in your email into a patch for
grops.man, together with the example.
Done (more or less). I've also taken the liberty to restructure
the grops manpage somewhat, i.e., begin the Usage section with
the discussion of the general workings of grops instead of how
/level0 save def
1 setlinecap
1 setlinejoin
+ DEFS /BPhook known { DEFS begin BPhook end } if
72 RES div dup scale
LS{
90 rotate
Fine!
No, seriously, I have no idea how to document this since
it's essentially trivial: [...]
Please convert the information in your email into
Well, it is justifiable, but it isn't documented correctly.
The only justification I can think of is that this way it is
not apparent when a closed curve isn't closed properly (in the
Postscript sense). This shouldn't happen in a Postscript-aware
application, however.
I don't
On Mon, Jul 17, 2006, Tadziu Hoffmann wrote:
(By the way, I've also added a line DEFS /BPhook known { DEFS
begin BPhook end } if to BP, which lets me define a custom
Postscript beginning-of-page function BPhook in the document
(with ps: def) that gets executed before groff prints anything
on
On Sun, Jul 16, 2006, jon arbuckle wrote:
On 9th July 2006, Peter Schaffter wrote:
I've been contemplating adding some macros to the mom set to
ease the creation of simple graphical objects: rules, boxes and
elipses/circles (ease meaning make easier for newcomers to
groff).
Not to
Well, it is justifiable, but it isn't documented correctly.
The only justification I can think of is that this way it is
not apparent when a closed curve isn't closed properly (in the
Postscript sense). This shouldn't happen in a Postscript-aware
application, however.
I don't think so.
Well, it is justifiable, but it isn't documented correctly.
The only justification I can think of is that this way it is
not apparent when a closed curve isn't closed properly (in the
Postscript sense). This shouldn't happen in a Postscript-aware
application, however.
What exactly do you
On 13th July 2006, Ted Harding wrote:
Yes, I'll do that with precautions! Not sure how to write a
patch, though, since I've never quite grasped how that should
be done. Maybe if I describe how it should come out (with the
words, of course) someone could guide me?
Ted.
For making a ``patch'',
On 9th July 2006, Peter Schaffter wrote:
I've been contemplating adding some macros to the mom set to
ease the creation of simple graphical objects: rules, boxes and
elipses/circles (ease meaning make easier for newcomers to
groff).
Not to distract from the main topic, but aren't such
Equally, unfilled polygons drawn with
\D'p co-ordinates
all have rounded corners, whereas filled polygons drawn with
\D'P co-ordinates'
produces the expected sharp corners.
Typographically speaking, this is not an expected, or--in my
experience--justifiable default behaviour
On 09-Jul-06 Peter Schaffter wrote:
I've been contemplating adding some macros to the mom set to
ease the creation of simple graphical objects: rules, boxes and
elipses/circles (ease meaning make easier for newcomers to
groff).
However, I've discovered something troubling: rules drawn with
On Mon, Jul 10, 2006, Ted Harding wrote:
On 09-Jul-06 Peter Schaffter wrote:
1. What is the rational behind groff's drawing rounded caps on
rules, and rounded corners on unfilled polygons?
I don't know but I set out some considerations below.
Very useful. Thanks.
2. Can this
13 matches
Mail list logo
