[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