groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Inputfile_caseencapsulation --with-unpack (and --with-zlib)


From: Steffen Nurpmeso
Subject: Re: [Groff] Inputfile_caseencapsulation --with-unpack (and --with-zlib) support
Date: Tue, 29 Jul 2014 15:38:15 +0200
User-agent: s-nail v14.7.4-3-g32d76ea

Hallo Werner,

Werner LEMBERG <address@hidden> wrote:
 |I don't have time to review this.  I suggest that you open an
 |bugtracker issue and post a cleaned-up mbox file for further
 |inspection.

You don't need to review but could just commit it, it is ok by
itself.  I.e., i would commit it.

 |It's really time that we find a new groff maintainer...

I'm not the right person to be the "technical leader" of GNU troff
since i don't know enough, but a Public Domain based commit
ticket for such general technical cleanups and, as time goes by,
probably more would be doable.  E.g., having a stable and fully
UTF-8 aware troff all through the way would be a fantastic
improvement, but for one i'm sure you have had reasons to go the
preconv(1) and \[u ] way and then i want to actually understand
Unicode by creating a text library which does support it.  The
standard(s) doesn't do so, and will fail to do so for a long time.
And anyway i am definitely not capable to replace you in such
a way that you could disappear from the scene, like your
predecessor did, like you said.  E.g., i've already looked into
troff because of the hyphenation issue, but of course i cannot
tell how hacky it would be to implement it now and above all
wether it would be at all desirable to support \[u ] stuff there,
or wether a clean UTF-8 (or whatever) rewrite of the processing
pipeline would be more promising..  Just like i said..

 |Sorry.

Oh no, please, why this?

--steffen



reply via email to

[Prev in Thread] Current Thread [Next in Thread]