> > By the way, is it a goal of groff to support the Heirloom Troff extensions? > > Nope, more like the other way around. Groff is the dominant Troff > implementation these days, so it behoves Heirloom Troff to support the more > commonly-used extensions.
It's not a question of which implementation has the bigger market share, but which has the richer feature set. Currently each of them can do things the other can't. There's no general goal of implementing all Heirloom features that groff is missing, but I too would like to see this happen (and vice versa on the Heirloom side). It would greatly benefit portability and interoperability if we could regard useful extensions as part of the modern roff language, rather than as groff- or Heirloom-specific features. (There would still need to be a macro package to spackle over differences in features common to both packages but accessed with different syntax, e.g., .tkf vs .track.) Anyone interested in groff's long-term goals should check out its mission statement (http://www.gnu.org/software/groff/groff-mission-statement.html), crafted after much discussion on this list several years ago. Three core improvements it mentions for groff -- using a paragraph-at-once formatting algorithm, and natively understanding modern fonts and character encodings -- are already in Heirloom. That groff cannot do the first at all, and requires external helpers (one of them not even shipped with the package) for the latter two, ironically makes it look more outdated than its "heirloom" counterpart.
