This topic scratches an old itch: it's a shame that pic does not exploit \D for filling polygons. I have filled an axIs-oriented right triangle in pic by making a filled box and deleting one corner of the resulting \D. Other polygons can be filled by breaking them up into axis-oriented right triangles and boxes.
Unfortunately pic chops broken lines into separate segments, so it can't directly fill general polygons. To enable that, I have wished that pic could produce unbroken broken lines. I looked at it enough to discover that would be a nontrivial change. But then it would be trivial to add the keyword "polygon" with the same syntax as "line" except that it produces n segments connecting n points rather than n-1. Doug On Tue, Sep 3, 2024 at 12:02 PM <groff-requ...@gnu.org> wrote: > Send groff mailing list submissions to > groff@gnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gnu.org/mailman/listinfo/groff > or, via email, send a message with subject or body 'help' to > groff-requ...@gnu.org > > You can reach the person managing the list at > groff-ow...@gnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of groff digest..." > > > Today's Topics: > > 1. a boundary-pushing challenge for drawing commands > (G. Branden Robinson) > 2. Re: a boundary-pushing challenge for drawing commands > (Tadziu Hoffmann) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 3 Sep 2024 05:11:59 -0500 > From: "G. Branden Robinson" <g.branden.robin...@gmail.com> > To: groff@gnu.org > Subject: a boundary-pushing challenge for drawing commands > Message-ID: <20240903101159.2wry2ol6tbegkrmg@illithid> > Content-Type: text/plain; charset="utf-8" > > I was reading groff_diff(7)'s short and simple description of the GNU > troff drawing command extension, `\D'P'`. > > \D'P h1 v1 ... hn vn' > As \D'p', but the polygon is filled. > > Instantly (or not, given that I must have read this sentence dozens of > times before without finding it noteworthy), a problem occurred to me. > > How does the formatter know which parts to fill? > > I have a vague conception that finding determining whether a point is > interior to a polygon is something of an open question. Call it a rumor > one hears among mathematics undergraduates in the break room. This, I > gather, is why applied topologists go on about "convex hulls". (I don't > have a _proper_ understanding of these things.) > > If the question seems easy, it's probably because you're thinking of > conventional convex polygons, and maybe even regular ones, with all > sides the same length. > > But those are especially well-behaved specimens of polygon. > > Haughtily, I figured I could break GNU troff at once. > > $ cat EXPERIMENTS/concave-filled-polygon.groff > .sp > Try to make a filled bowtie. > .sp > Let's see what happens. > .sp > \D'P 0 1i 1i -1i 0 1i' > > ...but it worked! > > Clearly the formatter can figure out simple cases like this. > > But, if I'm right about polygon concavity being a killer, ultimately one > can get the formatter to go wrong, either by misrendering, failing an > assertion, or going computationally asymptotic as it struggles with > interiority like a character from a Bergman film. > > If someone would test GNU troff's boundaries so that I can document what > those boundaries are, I'd appreciate it. > > Same if you can disabuse me of my misguided mathematical notions. > > Regards, > Branden > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 833 bytes > Desc: not available > URL: < > https://lists.gnu.org/archive/html/groff/attachments/20240903/2e44aa62/attachment.sig > > > > ------------------------------ > > Message: 2 > Date: Tue, 3 Sep 2024 14:16:06 +0200 > From: Tadziu Hoffmann <hoffm...@usm.uni-muenchen.de> > To: groff@gnu.org > Subject: Re: a boundary-pushing challenge for drawing commands > Message-ID: <20240903121606.gf14...@usm.uni-muenchen.de> > Content-Type: text/plain; charset=us-ascii > > > > How does the formatter know which parts to fill? > > In the case of groff (I can't say anything about the original > troff), I don't think the formatter actually knows or cares, > but simply passes the path on to the device postprocessor, > which just incorporates it into the device-dependent output, > to be dealt with by the actual output device. > > For Postscript, the Postscript Language Reference Manual > has a short description of how filling conceptually works > (Section 4.5.2, "Filling"). There's actually two different > algorithms that can be selected, "non-zero winding rule" > or "even-odd rule", which can give different results under > certain circumstances, such as self-intersecting paths or > paths consisting of multiple sub-paths. However, in the > case of your bowtie, both render the same. > > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > groff mailing list > groff@gnu.org > https://lists.gnu.org/mailman/listinfo/groff > > > ------------------------------ > > End of groff Digest, Vol 239, Issue 2 > ************************************* >
