[bug #62923] [gropdf] glyph aliases in in font description files not parsed correctly

Follow-up Comment #5, bug #62923 (project groff): I've just created an account. The output is really easy to understand (thanks to groff_out(5))! [comment #4 comment #4:] > Would the submitter care to identify themselves? I like to credit helpful reporters in the ChangeLog, and it's not every da

[bug #62934] gropdf: sometimes \(em becomes a different char when rendered with gropdf

: None ___ Follow-up Comments: --- Date: Sun 21 Aug 2022 08:42:49 PM UTC By: Nikita Ivanov GROFF VERSION: 1.23.0.rc1.2845-342a1-dirty OS: GNU/Linux COMPILER: clang COMMAND LINE: groff works.troff -k

[bug #62934] gropdf: sometimes \(em becomes a different char when rendered with gropdf

Follow-up Comment #2, bug #62934 (project groff): The patch you provided works, thank you! ___ Reply to this item at: ___ Message sent via Savannah http

[bug #62955] \(va is still constructed out of \(ua and \(da despite the glyph is defined in a special font

elease: None ___ Follow-up Comments: --- Date: Wed 24 Aug 2022 08:14:58 PM UTC By: Nikita Ivanov I've noticed that even though _\(va_ char (up-down arrow) is defined in a special

[bug #62955] [grops] \(va fallback character overrides glyph available in S font

Follow-up Comment #3, bug #62955 (project groff): I've changed some of the request (see _schar.patch_). Does it look right? (file #53666) ___ Additional Item Attachment: File name: schar.patchSize:1 KB

[bug #63067] [PATCH] document title that contains symbols that are not available in the standard fonts are not rendered correctly

k: Any Planned Release: None ___ Follow-up Comments: --- Date: Fri 16 Sep 2022 01:57:21 PM UTC By: Nikita Ivanov I write in Russian and, since standard groff fonts do not s

[bug #63074] [PATCH] [mom] warning messages when using special characters in TITLE or AUTHOR

: None ___ Follow-up Comments: --- Date: Sat 17 Sep 2022 05:01:15 PM UTC By: Nikita Ivanov I get warnings that "special characters are not defined" when using characters that ar

[bug #63075] [PATCH] [mm] minor improvement: remove implicit newline after if-block opening

: None ___ Follow-up Comments: --- Date: Sat 17 Sep 2022 05:10:04 PM UTC By: Nikita Ivanov _\{_ that is not followed by a baskslash implicitly adds a newline to troff input, which sometimes can cause pr

[bug #63076] Adding Russian language to groff

Follow-up Comments: --- Date: Sat 17 Sep 2022 05:41:41 PM UTC By: Nikita Ivanov I would love to help the project by adding support for Russian language (in a similar manner to Italian, German and so on, by providing hyphenation rules and stri

[bug #63076] Adding Russian language to groff

Follow-up Comment #1, bug #63076 (project groff): When I wrote it, I forgot that the built-in fonts do not support Cyrillic symbols and you always has to use a 3rd-party font to write in Russian. So now I'm not sure if adding strings and hyphenation rules makes sense... Unless I also add Cyrillic

[bug #63074] [PATCH] [mom] warning messages when using special characters in TITLE or AUTHOR

Follow-up Comment #3, bug #63074 (project groff): [comment #2 comment #2:] > It's not entirely clear what you mean by "characters that are not defined in default fonts." Oh, I mistyped there. I meant that I get warnings when using Cyrillic characters (that are not defined in default fonts). I've

[bug #63076] [tmac] add Russian language support

Follow-up Comment #4, bug #63076 (project groff): Thank you for so much helpful info! I've noticed that if I enable hyphenation rules for Russian language with _.hpf_ request, hyphenation for text written in English seems to stop working. However, it's not the case for French or German languages.

[bug #63076] [tmac] add Russian language support

Follow-up Comment #5, bug #63076 (project groff): Another question: Why do nearly all language macro packages set additional inter-sentence space to 0? Should the same be done in the Russian one? ___ Reply to this item at:

[bug #63074] [PATCH] [mom] warning messages when using special characters in TITLE or AUTHOR

Follow-up Comment #5, bug #63074 (project groff): I've tested my patch again and now it doesn't work to some reason (the warnings are still printed). I don't understand the internals of MOM well enough to figure out what's wrong, so I think it would be better if you come up with your solution. I

[bug #63074] [troff] need a way to embed non-Basic Latin glyphs in device control commands

Follow-up Comment #15, bug #63074 (project groff): [comment #8 comment #8:] > Nikita, > > If you've done any switching between groff 1.22.4 and a recent git build (specifically, any since commit 557bc055 six months ago), the newer

[bug #63076] [tmac] add Russian language support

Follow-up Comment #6, bug #63076 (project groff): Please review my patch _groff-ru-1.patch_. It includes translated strings for macro packages and hyphenation rules. The Cyrillic symbols are encoded in KOI8-R (_koi8-ru.tmac_ adds support for the encoding). (file #53764) _

[bug #63076] [tmac] add Russian language support

Follow-up Comment #9, bug #63076 (project groff): I've done my research and it turns out that usually no additional spacing is added after a sentence ending. This means that the patch I sent previously does not require any modifications. I've attached an example _ms_ document that makes use of th

[bug #63076] [tmac] add Russian language support

Follow-up Comment #11, bug #63076 (project groff): > There, I have bad news--I'm afraid not. I probably should have replied way earlier. But anyway, I'm looking forward to see it being added in 1.23.1! > It might become the basis of a unit test so we can be sure we keep Russian language support w

[bug #63076] [tmac] add Russian language support

Follow-up Comment #13, bug #63076 (project groff): > I guess the main things I'm curious about are how you solved the problem of KOI8-R having code points in the same space as C1 controls (which groff uses for internal purposes). I did not handle that case in any special way. The resulting documen

[bug #63076] [tmac] add Russian language support

Follow-up Comment #16, bug #63076 (project groff): [comment #15 comment #15:] > Apparently it can. In your example document, your use of the character ≈ (in KOI8, this is hex 0x97 or decimal 151) is rejected by GNU troff upon input. By mistake I included a literal em dash character (_—_) in the d

[bug #63076] [tmac] add Russian language support

Follow-up Comment #19, bug #63076 (project groff): [comment #17 comment #17:] > Yes, although in English, style authorities conflict over whether em-dashes should get space around them, so groff does not mandate a policy. Deciding this question may require consultation of multiple style authoriti

[bug #64399] [chem] A troff comment causes chem to hang

: None ___ Follow-up Comments: --- Date: Sun 09 Jul 2023 02:01:57 PM UTC By: Nikita Ivanov These input lines cause chem to hang: echo '.\" "' | chem echo '." "' | chem echo ' word .\" "'