Re: groff Digest, Vol 239, Issue 2

[Douglas McIlroy]

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-request@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-request@gnu.org
>
> You can reach the person managing the list at
>         groff-owner@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.robinson@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 <hoffmann@usm.uni-muenchen.de>
> To: groff@gnu.org
> Subject: Re: a boundary-pushing challenge for drawing commands
> Message-ID: <20240903121606.GF14560@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
> *************************************
>