On 03.10.24 21:58, Deri wrote:
On Wednesday, 2 October 2024 19:29:26 BST G. Branden Robinson wrote:
To accept such a restriction is to surrender groff to stagnation. While
I am aware of at least one person for whom that situation is a
preference, I claim that the same can be achieved by never upgrading
groff from the version one finds satisfactory. In the meantime, those
who _don't_ want groff to stagnate can benefit from its development.
I agree stagnation is not good, but it is undesirable if changes break
existing documents. An example is the utp document which a lot of people on
thanks for chiming in. this indeed is my major concern: legacy documents (including my own ;))
starting to break. the IX issue is simple enough to resolve but it still requires to augment the
document on a per case basis or one's own macro collection.
today I've noted another glitch: serious misalignment of page numbers in table of content when using
ms macros (wide entries failing to line break and "pushing" the page number out of line to the right
instead). I cannot say, however, whether this is a 1.23-related issue or whether it just has escaped
my attention previously (would have to revert to 1.22 to check, no time right now etc.).
br/joerg
this list put together. Neither the original 1.0, producing postscript, nor
1.1, producing a pdf, now build properly, from https://github.com/larrykollar/
Unix-Text-Processing.
Various problems occur using current git groff, from extra blank pages, text
which was set as mono spaced appearing as Times-Roman, pdf bookmarks jumping
to the wrong page, input line numbers appearing in the output (1.0 postscript
only - also affects 1.23.0 - Ok in 1.22.4).
Are all of these changes in behaviour really fixes to bugs in groff?
Cheers
Deri
