[bug #55278] src/devices/grotty/grotty.1.man, doc/groff.texi updates

[Dave]

Follow-up Comment #1, bug #55278 (project groff):

Side note on point 1: There is also the question of what "supporting" this
actually means. One Android terminal app, for instance (specifically,
JuiceSSH), renders text delineated with these escape sequences in reverse
video. This is arguably uglier than underlining, but the app does recognize
the escape sequences and gamely tries to distinguish affected text. So this
app arguably supports it, even if the results aren't attractive.

_______________________________________________________

Reply to this item at:

<https://savannah.gnu.org/bugs/?55278>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[Dave]

Follow-up Comment #2, bug #55278 (project groff):

Point 1 fixed in commit c105b1725cc928e225d23237f3cf1a7a5239d5bavax.

Side note on point 3: According to
http://en.wikipedia.org/wiki/Caret_navigation, "caret" can be a synonym for
"cursor" in the context of a text editor or similar UI, but that's not what
this sentence is referring to.

_______________________________________________________

Reply to this item at:

<https://savannah.gnu.org/bugs/?55278>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[Dave]

Follow-up Comment #3, bug #55278 (project groff):

[comment #2 comment #2:]

Post by Dave
Point 1 fixed in commit c105b1725cc928e225d23237f3cf1a7a5239d5bavax.

Not sure where the extra characters on the end came from. The correct commit
is commit c105b1725cc928e225d23237f3cf1a7a5239d5ba
<http://git.savannah.gnu.org/cgit/groff.git/commit/?id=c105b1725cc928e225d23237f3cf1a7a5239d5ba>.

_______________________________________________________

Reply to this item at:

<https://savannah.gnu.org/bugs/?55278>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[G. Branden Robinson]

Update of bug #55278 (project groff):

Status: None => Fixed
Assigned to: None => gbranden
Open/Closed: Open => Closed
Planned Release: None => 1.22.5

_______________________________________________________

Follow-up Comment #4:

Fixed in 69c400e082f2b11c8b79a4a6224f174ee8a28d53.

A separate bug could/should be filed for describing how the troff -a output
should actually be read. Now that I've seen inside src/roff/troff/*.cpp I
have a notion, but the subject sure could use some explanation for a general
audience.

_______________________________________________________

Reply to this item at:

<https://savannah.gnu.org/bugs/?55278>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[Dave]

Follow-up Comment #5, bug #55278 (project groff):

[comment #4 comment #4:]

Post by G. Branden Robinson
A separate bug could/should be filed for describing how the troff -a output

should actually be read.

I'll leave that in your capable hands, since I'm not quite sure what you mean.
I look at -a output as a low-res human-readable preview of typeset output, so
how it "should" be read depends on the reader's needs. But you seem to have
something specific in mind.

_______________________________________________________

Reply to this item at:

<https://savannah.gnu.org/bugs/?55278>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[G. Branden Robinson]

Follow-up Comment #6, bug #55278 (project groff):

[comment #5 comment #5:]

Post by Dave
[comment #4 comment #4:]
I'll leave that in your capable hands, since I'm not quite sure what you

mean. I look at -a output as a low-res human-readable preview of typeset
output, so how it "should" be read depends on the reader's needs. But you
seem to have something specific in mind.

Okay, some disorganized observations.

* Horizontal motions seem to be reduced to just one space (a space node
internally, I think).
* Multiple adjacent space nodes, however, are not coalesced.
* Vertical motions seem to be ignored.
* Hyphens inserted by groff are rendered as "<hy>".
* Other special characters are rendered as their names in
less-than/greater-than signs.
* Less-than and greater-than signs in the input are not escaped or quoted.
* To finish with the most obvious item, "<beginning of page>" is emitted at
each page transition, including what I have seen called the
"pseudo-page-transition" at the beginning of input.


$ cat EXPERIMENTS/groff-a-example.roff
mother-in-law
pneumonoultramicroscopicsilicovolcanoconiosis
pneumonoultramicroscopicsilicovolcanoconiosis
<foo><bar>
foo\h'16n'bar
baz\h'8n'\h'8n'qux
.br
\[sc] section sign
.br
em\[em]dash
.br
en\[en]dash
.br
P. J. Soles was in the movie \fIAnimal House\fP.
Now let's have some vertical space.
.sp 3v
clich\[e aa]
page break
.bp
Here's a new page.
$ groff -Tutf8 -a <EXPERIMENTS/groff-a-example.roff
<beginning of page>
mother-in-law pneumonoultramicroscopicsilicovolcanoconiosis pneu<hy>
monoultramicroscopicsilicovolcanoconiosis <foo><bar>
foo bar baz qux
<sc> section sign
em<em>dash
en<en>dash
P. J. Soles was in the movie Animal House. Now let's have some
vertical space.
clich<'e> page break
<beginning of page>
Here's a new page.


Also, there is a factual error in the above. I confused _Animal House_ with
_Stripes_.

_______________________________________________________

Reply to this item at:

<https://savannah.gnu.org/bugs/?55278>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[Dave]

Follow-up Comment #7, bug #55278 (project groff):

I see your point on some of those. The stuff about how spacing isn't preserved
might be worth a mention.

But I think there's value in not overdocumenting what can be easily gleaned by
looking at the output; e.g., the line "<beginning of page>" is essentially
self-documenting.

The output is called an "ASCII approximation," which already communicates that
it won't reflect its input exactly. And documenting exactly how special
characters are output today means locking in that output forevermore; leaving
them unspecified gives the groff maintainers of 2040 flexibility to change
them if the need arises. (Hopefully no one is using -a output in production,
minimizing back-compatibility concerns if it changes. But it strengthens that
position if the only documented result is that that output is an
approximation, with no promises about just how things are approximated.)

_______________________________________________________

Reply to this item at:

<https://savannah.gnu.org/bugs/?55278>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/