Hi Branden,
On 30/04/2023 15:35, G. Branden Robinson wrote:
At 2023-04-29T21:38:53-0500, Dave Kemper wrote:
On 4/29/23, Oliver Corff wrote:
Would it be a feasible option to use UTF-8 throughout the inner
workings of a future groff,
I'm going to phrase this more confrontationally than it
At 2023-04-29T21:38:53-0500, Dave Kemper wrote:
> On 4/29/23, Oliver Corff wrote:
> > Would it be a feasible option to use UTF-8 throughout the inner
> > workings of a future groff,
I'm going to phrase this more confrontationally than it needs to be just
to make a point about software design:
On 4/26/23, G. Branden Robinson wrote:
> It would probably be a good idea to represent Unicode strings internally
> using char32_t as a base type anyway, but groff's design under the Unix
> filter model described above makes the choice less dramatic in terms of
> increased space consumption than
On 4/29/23, Oliver Corff wrote:
> Would it be a feasible option to use UTF-8 throughout the inner workings
> of a future groff,
This is the topic of http://savannah.gnu.org/bugs/?40720 (though most
of the interesting discussion has taken place in
http://savannah.gnu.org/bugs/?58796). But in my
Hi Branden,
On 27/04/2023 05:07, G. Branden Robinson wrote:
At 2023-04-26T19:33:48+0200, Oliver Corff wrote:
I am not familiar with modern incarnations of C/C++. Is there really
no char data type that is Unicode-compliant?
There is. But "Unicode" is a _family_ of standards. There are
Hi Branden,
On 4/27/23 05:07, G. Branden Robinson wrote:
> [0] If you're like me, the idea of a "20.1-bit" quantity sounds weird.
> You can't encode a tenth of a bit in a single logic gate, or one
> position in a machine register. The key is to think in terms of
> information theory,
At 2023-04-26T19:33:48+0200, Oliver Corff wrote:
> On 26/04/2023 15:16, G. Branden Robinson wrote:
> > Be sure you review my earlier messages to Oliver in detail. The
> > hyphenation code isn't "broken", it's simply limited to the C/C++
> > char type for character code points and hyphenation
Hi Robin and Branden,
On 26/04/2023 15:16, G. Branden Robinson wrote:
At 2023-04-26T15:16:55+0300, Robin Haberkorn wrote:
For future texts I therefore wanted to return to Groff (where we also
have the excellent MOM macros). Not being able to hyphenate UTF-8
Cyrillic text is a major limitation
At 2023-04-26T15:16:55+0300, Robin Haberkorn wrote:
> For future texts I therefore wanted to return to Groff (where we also
> have the excellent MOM macros). Not being able to hyphenate UTF-8
> Cyrillic text is a major limitation for me. I might get away with
> converting it to KOI8 first, but
Hello!
I can confirm that Neatroff (and Heirloom Troff) works well for typesetting
Russian texts including hyphenation.
BUT, I found them unsuitable for complex scientific texts as their ms macros are
buggy and tbl is somewhat limited. Regarding Neatroff, I found that its
hyperlinking
Hi Ralph,
I could not resist the temptation to procrastinate from my current work
and had a look at neatroff.
Really neat!
Out-of-the-box, my test file russ.ms and TeX utf8 hyphenation patterns
taken straight from my TeX installation produced the attached very
satisfying result.
Best regards,
Hi Ralph,
thank you very much for mentioning neatroff. In principle, I am aware
that there are other implementations, all with their particular unique
features, but I never dived into anything other than groff so far (also
due to the fruitful and friendly exchange on this mailing list), and
Hi Oliver,
Are you aware there are other troff implementations than GNU's groff?
Neatroff is one. Ali Gholami Rudi wrote it because he wanted better
Unicode support for foreign languages, including right-to-left text.
He seems very much of your mould in needs.
A good summary of its features is
13 matches
Mail list logo
