Update of bug #67817 (group groff):
Severity: 3 - Normal => 1 - Wish
Status: None => Need Info
Assigned to: None => barx
Summary: restore defined-character detail to approximate (-a)
output => [troff] restore defined-character detail to approximate (-a) output
_______________________________________________________
Follow-up Comment #1:
[comment #0 original submission:]
> Sometime since groff 1.23, approximate (-a) output has become less
> forthcoming about document-defined characters.
I would emphasize the word **output** in the foregoing, and say instead that
the formatter has become more forthright about what GNU _troff_ asks of its
output drivers in terms of character repertoire, a property that is in turn
determined by the output device's font description files.
> Below, "groff" is groff 1.23 (groff 1.22.4 also produces the same output) and
> "groff-latest" is git HEAD.
> $ cat approximate.roff
> .fschar S \[trademarksans] \N'228'
> Enjoy a glass of Fluerma\fS\[trademarksans]\fP tonight.
> $ groff -a approximate.roff
> <beginning of page>
> Enjoy a glass of Fluerma<S trademarksans> tonight.
> $ groff-latest -a approximate.roff
> <beginning of page>
> Enjoy a glass of Fluerma<---> tonight.
> In particular, when there are multiple .char-defined characters, the old -a
> output distinguished them, while the new output collapses them all into the
> same fairly meaningless string.
I claim that the '---' notation is not a "meaningless string", but instead
indicates that no simplistic means of expressing the identity of the glyph
being written exists in the very loosely specified "approximate output"
format.
What does the corresponding non-approximate output look like?
$ groff -Z EXPERIMENTS/67817.groff | grep -C3 '^N'
tFluerma
x font 11 S
f11
N228
wf5
h10360
ttonight.
Now, fortunately, in the forthcoming _groff_ 1.24, if an "-a" user such as
yourself is troubled by (or merely curious about) this "<--->" glyph, you can
solicit more information about it.
$ diff -u EXPERIMENTS/67817.groff EXPERIMENTS/67817gbr.groff
--- EXPERIMENTS/67817.groff 2025-12-15 13:10:26.500854584 -0600
+++ EXPERIMENTS/67817gbr.groff 2025-12-15 13:18:37.935473916 -0600
@@ -1,2 +1,3 @@
.fschar S \[trademarksans] \N'228'
-Enjoy a glass of Fluerma\fS\[trademarksans]\fP tonight.
+Enjoy a glass of Fluerma\fS\[trademarksans]\fP tonight.\c
+.pline
$ groff -z EXPERIMENTS/67817gbr.groff 2>&1 | jq
[
{
"type": "output line start node",
"diversion level": 0,
"is_special_node": false
},
{
"type": "glyph node",
"diversion level": 0,
"is_special_node": false,
"character": "E"
},
[...snip...]
{
"type": "glyph node",
"diversion level": 0,
"is_special_node": false,
"character": "m"
},
{
"type": "glyph node",
"diversion level": 0,
"is_special_node": false,
"character": "a"
},
{
"type": "composite node",
"diversion level": 0,
"is_special_node": false,
"special character": "S trademarksans",
"contents": [
{
"type": "output line start node",
"diversion level": 0,
"is_special_node": false
},
{
"type": "glyph node",
"diversion level": 0,
"is_special_node": false,
"special character": "---"
}
]
},
{
"type": "word space node",
"diversion level": 0,
"is_special_node": false,
"hunits": 2500,
"undiscardable": false,
"is hyphenless breakpoint": false,
"terminal_color": "default",
"width_list": [
{
"width": 2500,
"sentence_width": 2500
}
],
"unformat": false
},
{
"type": "glyph node",
"diversion level": 0,
"is_special_node": false,
"character": "t"
},
[...snip...]
{
"type": "glyph node",
"diversion level": 0,
"is_special_node": false,
"character": "."
},
{
"type": "transparent dummy node",
"diversion level": 0,
"is_special_node": false
}
]
As you can see, the revised approximate output accurately reports the
inapplicable "name" of the special character being output, and more helpfully
gets across the fact of its existence than simply omitting it does.
Yes, the formatter does "know" the "name" of the special character, "S
trademarksans", but this is an internal representation form only--you'll note
that this is not a valid identifier, and should not be exposed to external
consumers. Moreover, to return to my earlier point, there **is** no means of
representing that name to an output driver. What the special character
"really is", as output, is a change of font selection combined with selection
of a font glyph by its index number.
I agree with you that "troff -a" is now communicating less information. My
point is that, given the way "-a" is implemented (as a set of member functions
of node classes that "print themselves approximately" as opposed to
"tprinting" themselves (in device-independent format) or "dumping" themselves
to the standard error stream, a new feature), I feel it makes more sense for
"-a" output to align itself closely with what gets written as
device-independent output than to capture details of input that have, at the
time output is written, are discarded.
See my recent heavy revision of the "GNU troff internals" node of our Texinfo
manual.
My first inclination was to close this ticket as rejected, but I think I need
some more information.
* Is this change significant enough to merit mention in the "NEWS" file? We
have already said the following in _troff_(1) and our Texinfo manual for at
least one release.
The above description should not be considered a
specification; the details of -a output are subject to
change.
If you'd like to propose an alternative syntax for "-a" to represent nameless
glyphs in the output, please pitch such an idea in another ticket or on the
_groff_ mailing list.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67817>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
