Follow-up Comment #2, bug #67817 (group groff): [comment #1 comment #1:] > 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.
This is a long-winded way of saying that reverting this behavior would be a
layering violation.
I see no point in telling users "you need to do more work to get the same info
-a used to give you, just so groff can maintain conceptual purity." But as
you say, this is a question better raised on the list. I'll start a thread.
> more helpfully gets across the fact of its existence than
> simply omitting it does.
This is a straw man argument: no one is advocating for simple omission. The
question is _how_ to represent it: with a string indistinguishable from all
other special characters, or with one unique to each character.
> 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.
This is unconvincing. -a output, being "approximate," has never made
guarantees that what appears between angle brackets is a valid identifier.
That name is an obvious combination of two things the document author (the one
most likely to be using -a) does know: the font name and the character name as
defined by the document.
And in the case where someone unfamiliar with a document source uses -a on it,
arguing that "<S trademarksans>" is not meaningful to that person glosses over
the fact that "<--->" certainly isn't either.
> [quoting the Texinfo manual:]
> The above description should not be considered a
> specification; the details of -a output are subject to
> change.
I don't take issue with that precept. I take issue that the change in
question results in less informative output without any measurable trade-off.
(I presume that if the change made the code more maintainable, for instance,
you'd have mentioned this, but I'm open to correction.)
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67817>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
