[bug #65865] [mm] `AF` macro has no effect

Follow-up Comment #1, bug #65865 (group groff): [comment #0 original submission:] > Problem affects groff 1.22.3, 1.22.4, and 1.23.0. In fact, goes back to at least 1.19.2, and I'd bet much further than that. ___ Reply to this item at:

[bug #65861] add macro set to support German national standard DIN 5008

: None ___ Follow-up Comments: --- Date: Sun 09 Jun 2024 04:06:06 PM CDT By: Dave A proposal for a macro set to support German national standard DIN 5008 was put forth on the email list a few months ago

Re: How to configure how groff hyphenates man pages (was: tctest.1 man page hyphenation comments)

On Mon, Jun 3, 2024 at 9:06 PM G. Branden Robinson wrote: > [1] https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS#n50 > > The foregoing line number will get stale with time. Look for the > text "hydefault". You can stale-proof git URLs that point to line numbers by specifying a

[bug #55154] .tr has undocumented and inconsistent space-character restrictions

Follow-up Comment #12, bug #55154 (group groff): [comment #11 comment #11:] > While everything here appears to be working as designed, I'm > tempted to open a new bug report anyway, Succumbed to temptation: bug #65829 ___ Reply to this

[bug #65829] Want way to translate a character to \~

: None ___ Follow-up Comments: --- Date: Mon 03 Jun 2024 12:06:58 AM CDT By: Dave Comments 10 and 11 of bug #55154 point out that due to the way .tr and .char and their ilk handle translations, there is no way to translate an input character to a stret

[bug #65800] bootstrap oddity: .gitignore discrepancy

Follow-up Comment #1, bug #65800 (group groff): The groff version reported by this build is 1.23.0.1262-4c62e-dirty. ___ Reply to this item at: ___

[bug #65809] extend 'soelim' to deal with compressed files like 'zsoelim' does

Update of bug #65809 (group groff): Severity: 3 - Normal => 1 - Wish ___ Reply to this item at: ___ Message

[bug #65800] bootstrap oddity: .gitignore discrepancy

: None ___ Follow-up Comments: --- Date: Mon 27 May 2024 07:54:09 PM CDT By: Dave I haven't built a groff since 1.23. When I did so recently (http://lists.gnu.org/r/groff/2024-05/msg00042.html), the first step produced a query I hadn't seen in a

[bug #65654] [preconv] want a warning if code '0xA0' is used in the input

Follow-up Comment #5, bug #65654 (group groff): Correcting my earlier statement: [comment #2 comment #2:] > 0xA0 appears to refer to the Latin-1 character NO-BREAK SPACE > (Unicode U+00A0)--but there is no reason to run preconv if the > file is in Latin-1 encoding, My Latin-1 (ISO 8859-1)

[bug #65654] [preconv] want a warning if code '0xA0' is used in the input

Follow-up Comment #4, bug #65654 (group groff): This proposal (with the warning upgraded to a fatal error) has been offered as one of the solutions to bug #65710. ___ Reply to this item at:

[bug #65710] [preconv] require disambiguation of U+00A0 on input

Follow-up Comment #2, bug #65710 (group groff): [comment #0 original submission:] > In my opinion preconv should either: > > 1. Fail and force the user to edit the input to make a real > choice, eliminating U+00A0 in the input. This option seems materially the same as the rejected bug #65654,

[bug #65788] gropdf: warning: PDF Dict Key 'User' does not start with '/'

Update of bug #65788 (group groff): Open/Closed:Open => Closed ___ Reply to this item at: ___ Message

[bug #65762] configure check has erroneous code

Update of bug #65762 (group groff): Category:None => Core Item Group:None => Build/Installation ___ Reply to this item at:

[bug #64155] Specifying -fZD on command line generates warnings

Update of bug #64155 (group groff): Category:Core => Macro package - others/general Summary: [troff] specifying -fZD on command line generates warnings => Specifying -fZD on command line generates warnings

[bug #65763] Do actual string comparisons in macro packages

: None ___ Follow-up Comments: --- Date: Sun 19 May 2024 11:27:44 PM CDT By: Dave Bug #64155 fixed fallbacks.tmac and troffrc-end to make tests that were intended only to compare strings do so without form

[bug #64155] [troff] specifying -fZD on command line generates warnings

Follow-up Comment #45, bug #64155 (group groff): [comment #44 comment #44:] > I suspect you're not using _echo_(1) the way you think you are. I admit I didn't consider its portability, but on my system it output what I intended. > Because the default style is 'R', and the font 'ZDR' exists (on

[bug #64155] [troff] specifying -fZD on command line generates warnings

Follow-up Comment #43, bug #64155 (group groff): [comment #41 comment #41:] > Now: > > $ echo | ./build/test-groff -fZD -a > A vast improvement! But maybe a little _too_ quiet: groff disregards the -fZD flag without telling the user it's doing so. echo "\N'110'" | groff -ww

bootstrap oddity: .gitignore discrepancy

I haven't built a groff since 1.23. When I did so today, the first step produced a query I hadn't seen in a groff build before. $ ./bootstrap /bin/mv: overwrite '.gitignore'? I said "y" to this, and the result was that the top-level .gitignore file gained a "/build-aux" line at the top, before

[bug #55154] .tr has undocumented and inconsistent space-character restrictions

Follow-up Comment #11, bug #55154 (group groff): [comment #10 comment #10:] > Bizarrely, while it accepts the second translation, it doesn't > actually honor it. It gets worse: even .char fails at this. $ cat char-test .char b \~ abc cba\p $ nroff char-test | cat -s a c

Multiline @cindex entries misrender in groff Texinfo manual

In a few places, the groff Texinfo manual uses a line-ending @ to continue a @cindex entry. An example is: @DefreqList {tm, message} @DefreqItemx {tm1, [@code{"}]message} @DefreqListEndx {tmc, [@code{"}]message} @cindex print to the standard error stream (@code{tm}, @code{tm1},@

[bug #55154] .tr has undocumented and inconsistent space-character restrictions

Follow-up Comment #10, bug #55154 (group groff): [comment #0 original submission:] > .tr a > .tr b\~ > .tr c\ > .tr d\| > .tr e\^ > .tr f\0 > > This attempts to translate six alphabetic characters to six > different types of space characters. What it does instead is > accept the first two

[bug #62916] list things to deprecate

Follow-up Comment #8, bug #62916 (group groff): Related: bug #65724 seeks to deprecate EBCDIC. However, if it goes through as contemplated, it won't make it onto the list proposed by this ticket, because there won't be a release where it's deprecated but still functional.

Re: ripping out EBCDIC (cp1047)/preparing for UTF-8 input

On Tue, May 14, 2024 at 8:53 AM G. Branden Robinson wrote: > I aim to drop EBCDIC a.k.a. > code page (CCSID) 1047 support from groff 1.24. No objection to this. > The idea is, for 1.24, to get everybody migrating to pure ASCII input > documents (as might be generated by preconv(1)) by the time

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

Follow-up Comment #30, bug #63018 (group groff): [comment #29 comment #29:] > When it is a separate make target (bug #65698), if we wish to > retain the epsilon kerns the make target must either re-apply > the shell script after the font generation, or these "gold" AFMs > should have the extra

[bug #65702] tmac/doc.tmac: compatibility mode not restored at end

Update of bug #65702 (group groff): Status: Need Info => None ___ Reply to this item at: ___ Message

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

Follow-up Comment #28, bug #63018 (group groff): [comment #27 comment #27:] > And Dave just happens to be right here, ready for the spotlight. ;-) Oh, heavens no, I still need at least 15 more minutes in makeup. Have the emcee stall! [If there's a question for me here, I'm not sure w

[bug #65724] drop support for CCSID (code page) 1047 (EBCDIC)

Follow-up Comment #1, bug #65724 (group groff): [comment #0 original submission:] > See discussion with Mike Fulton of IBM on the _groff_ list a year ago. > > https://lists.gnu.org/archive/html/groff/2023-03/msg00113.html Discussion continues at

Re: Hungarumlauts in built-in fonts

On Fri, May 10, 2024 at 1:50 AM Gáspár Gergő wrote: > I realized, however, that the "hungarumlauts" on the ő Ő ű and Ű glyphs are > placed incorrectly in the built-in fonts of groff used for the pdf device. Does this mean the problem doesn't happen for the ps device? Or have you not tried

[bug #65693] exceptions to NBSP statement in groff_char(7) should be documented

Follow-up Comment #2, bug #65693 (group groff): Given the arguments in favor of the U+00A0 to \~ mapping presented in bug #58962 and bug #65710, I now wonder if groff might be better off doing something heretical like ignoring the u00A0 glyph in a font and applying its own mapping to that

[bug #64155] [troff] specifying -fZD on command line generates warnings

Follow-up Comment #39, bug #64155 (group groff): Self-followup: [comment #37 comment #37:] > in a way back compatible to almost any older troff. Obviously, this specific example is not AT due to the long names, but the logic can be written portably.

[bug #65710] [preconv] require disambiguation of U+00A0 on input

Follow-up Comment #1, bug #65710 (group groff): [comment #0 original submission:] > an input U+00A0...: is it a fixed-width non-breakable space, or a > variable-width non-breakable space? Unicode does not distinguish. Unicode intentionally provides some latitude to rendering engines to make the

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

Follow-up Comment #23, bug #63018 (group groff): Don't read too much into my opening multiple tickets: they're not saying "THESE THINGS MUST BE DONE" but giving venues to consider and discuss separate issues without cluttering this bug. At least that was the theory. ;-} Any ticket can be closed

[bug #65702] tmac/doc.tmac: previous state of compatibility (register '.cp') is not restored at end

Update of bug #65702 (group groff): Status:None => Need Info ___ Follow-up Comment #1: This situation dates back to primordial groff. The current .cp line was introduced in the 2001

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

Follow-up Comment #21, bug #63018 (group groff): True for the third ticket of that trio, but the first two can be implemented regardless of the fate of the old AFM files. As for the third, it documents a different issue from this ticket and should have its own venue, so that when this ticket is

[bug #57506] Suspicious "slant" values in devps/TI, devlbp/HI, devlbp/HBI

Follow-up Comment #15, bug #57506 (group groff): [comment #2 comment #2:] > It seems to me that these files should be regenerated, if not > on every build, then at least for every release. Now bug #65699. ___ Reply to this item at:

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

Follow-up Comment #19, bug #63018 (group groff): [comment #13 comment #13:] > In fact I see two issues springing thence. So, to summarize. > > 1. Make comment headers of font description files we generate > with tools more informative. Now bug #65697. > 2. Add "maintainer-font-descriptions"

[bug #65699] Update the procedure documented in "FOR-RELEASE"

Update of bug #65699 (group groff): Depends on: => bugs #65698 ___ Reply to this item at: ___ Message

[bug #65699] Update the procedure documented in "FOR-RELEASE"

ed Release: None ___ Follow-up Comments: --- Date: Mon 06 May 2024 11:18:05 AM CDT By: Dave Branden wrote in bug #63018: Update the procedure documented in "FOR-RELEASE" to include the effects of [bug #65698, which proposes

[bug #65698] Add "maintainer-font-descriptions" make(1) targets for *todit utilities

ed Release: None ___ Follow-up Comments: --- Date: Mon 06 May 2024 11:12:29 AM CDT By: Dave Branden wrote in bug #63018: Add "maintainer-font-descriptions" _make_(1) targets for _afmtodit_ and maybe

[bug #65697] Add info to comment headers of font description files groff tools generate

: None ___ Follow-up Comments: --- Date: Mon 06 May 2024 11:03:53 AM CDT By: Dave As mentioned in bug #63018, afmtodit's generated headers could additionally include the names of the source files that generat

[bug #62300] [preconv] does not handle U+00A0 (NBSP) as it should

Follow-up Comment #9, bug #62300 (group groff): [comment #7 comment #7:] > if the above is in fact the case, one of us should open a new bug report. Bug #65693 ___ Reply to this item at:

[bug #65693] exceptions to NBSP statement in groff_char(7) should be documented

: None ___ Follow-up Comments: --- Date: Mon 06 May 2024 02:06:11 AM CDT By: Dave groff_char(7) states, "a no-break space... is mapped to \~, the adjustable non-breaking space escape sequence." But as Deri and

[bug #59442] [PATCH] groff.cpp: move soelim before preconv in constructed pipeline

Follow-up Comment #11, bug #59442 (group groff): It sounds like a decision is needed on which is the cart and which the horse. Should this bug take priority -- as comment #1 points out, "The whole point of soelim is to get preprocessors to run on `.so`ed files" -- and then bug #65108 has to

[bug #64155] [troff] specifying -fZD on command line generates warnings

Follow-up Comment #37, bug #64155 (group groff): [comment #34 comment #34:] > Maybe it is time for a proper string equality operator in our > conditional expressions. While that would be a useful addition to the language, equivalent functionality can be achieved in user space, in a way back

[bug #44714] compatibility mode: .do request and macro expansion via \* collide

Follow-up Comment #4, bug #44714 (group groff): [comment #3 comment #3:] > Probably until this is fixed (which may be a while if it proves as > intractable as Werner predicts), the andoc.tmac comment should cite > this ticket rather than vaguely referring to "a bug in GNU troff." This is now

[bug #62826] [tmac] clearly comment bug #44714 workaround in andoc.tmac

Update of bug #62826 (group groff): Severity: 3 - Normal => 2 - Minor Status: Need Info => None Summary: [PATCH] [tmac] options "-mandoc" and '-C' are not compatible => [tmac] clearly

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

Follow-up Comment #16, bug #63018 (group groff): [comment #14 comment #14:] > I'm quite happy to put something in the header like "unicode > names added by Deri 2024", but I certainly would not suggest > removing the afmtodit header which documents the version used, I agree, all metadata

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

Follow-up Comment #12, bug #63018 (group groff): [comment #11 comment #11:] > It might help if we said so in the comment. We could > furthermore include in that comment the presence/values of > command-line options that affect the generated contents. If you're talking about modifying afmtodit

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

Follow-up Comment #10, bug #63018 (group groff): [comment #9 comment #9:] > I understood Deri as proposing to update "dingbats.map" _and_ > regenerating the ZD file using _afmtodit_ with it... Ah. I did not grasp that the latter was generated from the former. But that makes a lot more sense

[bug #64155] specifying -fZD on command line generates warnings

Follow-up Comment #31, bug #64155 (group groff): [comment #27 comment #27:] > it would be good to know if/how Dave's original report in > comment #0 was invalid. I'm fine with -fZD failing on the grounds that groff doesn't consider ZD a family, but the failure mechanism should be cleaner.

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

Follow-up Comment #8, bug #63018 (group groff): To clarify: my objection isn't the stale afmtodit version (I doubt refreshing the file will change the data), but that the line claims afmtodit generated it at all: once Deri's ZD is committed, precious little of its content will be from afmtodit.

[bug #65619] [afmtodit] want a default value for space width if unspecified

Update of bug #65619 (group groff): Status: Invalid => Need Info Open/Closed: Closed => Open ___ Follow-up Comment #4: Reopening since

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

Update of bug #63018 (group groff): Summary: font/devps/ZD: make glyphs accessible via their Unicode spellings => [PATCH] make glyphs in ZD font accessible via their Unicode spellings ___ Follow-up Comment #6: Thanks,

[bug #62826] [PATCH] [tmac] options "-mandoc" and '-C' are not compatible

Update of bug #62826 (group groff): Item Group:None => Documentation Status:None => Need Info ___ Follow-up Comment #4: Classifying this as a

[bug #62826] [PATCH] [tmac] options "-mandoc" and '-C' are not compatible

Follow-up Comment #3, bug #62826 (group groff): In the cited email thread, a bug occurs only when the deleted sed script [http://git.savannah.gnu.org/cgit/groff.git/tree/tmac/strip.sed?id=8fc53e4fd397f210a210fa006eaa5bc8e8012044 tmac/strip.sed] is applied to

[bug #65077] [ms] unexpected suppression of `sp` effect after `DE` call

Update of bug #65077 (group groff): Status: Need Info => Rejected Assigned to:None => barx Open/Closed:Open => Closed

[bug #62826] [PATCH] [tmac] options "-mandoc" and '-C' are not compatible

Follow-up Comment #2, bug #62826 (group groff): [comment #1 comment #1:] > .\" Due to a bug in GNU troff it necessary to have a no-op line between > .\" '.do' and '\*'. This is bug #44714. > +. do ie \\n[.cp] \{\ > +.do als TH reload-man > +.hw\"DO NOT REMOVE the line, see an earlier

[bug #44714] compatibility mode: .do request and macro expansion via \* collide

Follow-up Comment #3, bug #44714 (group groff): [comment #1 comment #1:] > I don't understand why '.do tm' is going to the next input line > to collect arguments. 'tm' is not documented in CSTR #54 as > behaving this way. It's not the behavior of .tm that's at issue, but of .do. This is the

[bug #65654] preconv.cpp: Issue a warning if code '0xA0' is used in the input and thus changed to '\~'

Follow-up Comment #2, bug #65654 (group groff): Bjarni is talking about input, not output. But the example is still slightly confusing, because 0xA0 appears to refer to the Latin-1 character NO-BREAK SPACE (Unicode U+00A0)--but there is no reason to run preconv if the file is in Latin-1

[bug #62300] [preconv] does not handle U+00A0 (NBSP) as it should

Follow-up Comment #7, bug #62300 (group groff): [comment #6 comment #6:] > the font defines operators for the glyph, which results in a > space of a certain width. This is a fixed width? If so, such fonts provide an undocumented exception to this statement in groff_char(7): "a no-break space...

[bug #63018] font/devps/ZD: make glyphs accessible via their Unicode spellings

Follow-up Comment #3, bug #63018 (group groff): [comment #0 original submission:] > defining aliases (probably in tmac/ps.tmac) for \[OK] and \[rh] so > that they can also be represented respectively by \[u2713] \[u261E] On further thought, because these aliases should apply to both the ps and

[bug #62300] [preconv] does not handle U+00A0 (NBSP) as it should

Follow-up Comment #5, bug #62300 (group groff): [comment #2 comment #2:] > The input sequence '\[u00A0]' is _syntactically_ valid...but > like '\[u]' and '\[u]', it's not _meaningful_ Dear future me: next time you run across this comment and think "I responded to this somewhere" but

[bug #59442] [PATCH] groff.cpp: move soelim before preconv in constructed pipeline

Follow-up Comment #10, bug #59442 (group groff): Sorry, I did read comment #5 before posting but missed the implication of its effect on the soelim proposal. ___ Reply to this item at:

[bug #59442] [PATCH] groff.cpp: move soelim before preconv in constructed pipeline

Update of bug #59442 (group groff): Status: Need Info => None ___ Follow-up Comment #7: This was made "Need Info" when Branden asked "Can anyone else think of any objections?" As none

Re: Problems building the unifont PFA and DIT files for the PDF book

On Sat, Apr 20, 2024 at 5:21 PM Alejandro Colomar wrote: > > It does occur > > to me that we might enhance afmtodit make of use of it as the > > default "spacewidth". > > That sounds like a great idea. Would you be willing to open a savannah request for this feature?

[bug #63028] document nroff \o limitations in modern terminal emulators

Follow-up Comment #5, bug #63028 (group groff): [comment #0 original submission:] > they should think about the order in which they specify the > characters, as only the last one is likely to end up visible. An exception is (at least some) space-like characters. $ echo "\o'abcd'efg" | nroff |

[bug #63354] Refine fallbacks.tmac

Follow-up Comment #38, bug #63354 (group groff): [comment #36 comment #36:] > I still see no way around the first, Ha, because I'm _still_ overthinking it. Groff offers a shorthand for \h^\w'0'u^ -- and that is \0. Thus the comment #36 suggestion reduces to: .fchar \[u2012] \o'-\0' This also

[bug #65099] 1.24.0 release goals

Follow-up Comment #4, bug #65099 (group groff): I submit bug #63827 as something that should be addressed in some manner before release, even if only in the form of a stopgap like resyncing groff's pdfmark subtree with the substantially updated code upstream.

[bug #65198] mom/examples/*.txt: change '-k' to '-K utf8'

Follow-up Comment #5, bug #65198 (group groff): [comment #0 original submission:] > See "https://lists/gnu.org/archive/html/groff/2024-01/msg00106.html; This URL is malformed and should be https://lists.gnu.org/archive/html/groff/2024-01/msg00106.html (A followup, not linked from that URL, is

[bug #65198] mom/examples/*.txt: change '-k' to '-K utf8'

Update of bug #65198 (group groff): Status: Invalid => None Assigned to:gbranden => PTPi Open/Closed: Closed => Open Summary:

[bug #63354] Refine fallbacks.tmac

Follow-up Comment #37, bug #63354 (group groff): (Of course, for fallback usage the .char in comment #35 and comment #36 should be .fchar.) ___ Reply to this item at:

[bug #63354] Refine fallbacks.tmac

Follow-up Comment #36, bug #63354 (group groff): Maybe comment #34 and comment #35 are overthinking this. The requirement for U+2012 is that it occupy the same horizontal space as a figure. There is no requirement on the width of the mark itself. So what if the fallback simply uses the font's

[bug #62833] [PATCH] tty.cpp: prefer showing data over opinion

Update of bug #62833 (group groff): Item Group:None => Warning/Suspicious behaviour ___ Reply to this item at: ___

[bug #64582] [troff] idea: require end-of-input traps to explicitly exit

Follow-up Comment #2, bug #64582 (group groff): Branden opined in that bug: > I think few people apart from macro package authors ever use > the `em` request. While it's impossible to quantify who uses what, it's notable that the Texinfo manual gives three different examples of uses of this

[bug #65117] [pdfmark] premature page break in "pdfmark.ms" output with page size A4

Update of bug #65117 (group groff): Depends on: => bugs #63827 ___ Follow-up Comment #3: The only value to keeping this open is that it's not yet known how bug #63827 will be resolved. I

[bug #42675] [troff] \} treated as macro argument

Follow-up Comment #12, bug #42675 (group groff): [comment #5 comment #5:] > This is not a bug, as the results of the test cases are > according to the description of how macros work, CSTR #54, > chapter 7.3. Arguments. That claim is undermined by the subsequent comment #10 demonstration that

[bug #42675] [troff] \} treated as macro argument

Follow-up Comment #11, bug #42675 (group groff): The output of Carsten's example in http://lists.gnu.org/r/groff/2014-07/msg00024.html tells us is that sections 1 and 3 call .A with no parameters; section 2 effectively calls it with one parameter, which is "\}". Thus, the "\}" in section 2 of

[bug #42675] [troff] \} treated as macro argument

Follow-up Comment #9, bug #42675 (group groff): [comment #8 comment #8:] > .if n \{.CA \} > .if n \{.CA \} Are those two lines intended to be identical? In Ingo's original, the first one has no space between the macro call and the following backslash.

[bug #59434] doc/groff.texi: document .if / .ie interaction more clearly

Follow-up Comment #4, bug #59434 (group groff): I guess we should get our terminology straight. For the infamous [comment #0 original submission] sample code, if COND1 is false, groff emits the .el warning. Do you consider this warning spurious? Based on everything written on this so far, I'm

[bug #42675] \} considered as macro argument

Update of bug #42675 (group groff): Summary: \} considered as macro argument regarding register .$ => \} considered as macro argument ___ Follow-up Comment #7: More wisdom from the email threads cited in comment #1 and

[bug #45502] [troff] .if, .ie, .el parsing incompatible with Unix V7, DWB, and Heirloom Doctools troff

Follow-up Comment #17, bug #45502 (group groff): [comment #16 comment #16:] > Sometimes I don't evaluate the truth value of a proposition > until I've inspected the machine that interprets it.  "Trust, but verify," as they say (though the second step seems to render the first moot). > You are

[bug #60260] [troff] formatter matches `el` requests with `ie` differently than Unix V7, DWB, and Heirloom

Update of bug #60260 (group groff): Item Group: Incorrect behaviour => Warning/Suspicious behaviour Status: Invalid => Duplicate ___ Follow-up Comment #7: [comment #6

[bug #65474] [troff] spurious "warning: unbalanced 'el' request" when formatting zic(8) from TZDB project

Follow-up Comment #26, bug #65474 (group groff): [comment #24 comment #24:] > I think my recast[1] of the relevant material in our Texinfo > manual is a reliable guide to interpretation. It's a reliable guide to other-troff interpretation. But in groff, change that example's ".nr

[bug #65474] [troff] spurious "warning: unbalanced 'el' request" when formatting zic(8) from TZDB project

Follow-up Comment #25, bug #65474 (group groff): [comment #22 comment #22:] > Sure, but I'd like to do that once the 3 of us (you, me, and > Paul) are on the same page, so that we aren't arguing any > facts, just the advisability of future action.  > Yours and Bjarni's claims in that ticket

[bug #65474] [troff] spurious "warning: unbalanced 'el' request" when formatting zic(8) from TZDB project

Follow-up Comment #23, bug #65474 (group groff): [comment #11 comment #11:] > Solaris 10 /usr/bin/nroff outputs "CASE a", which is what I'd expect. Heirloom troff does as well. > gnroff outputs "NOTREACHED", which is surprising. My guess at the end of comment #16 was wrong. This, it turns

[bug #65474] [troff] spurious "warning: unbalanced 'el' request" when formatting zic(8) from TZDB project

Follow-up Comment #19, bug #65474 (group groff): [comment #18 comment #18:] > I propose to fix this by killing the warning category along with > the spuriousness. With two longtime groff users (Tadziu and Bjarni, with me still on the fence) arguing that the warning isn't spurious, I wonder if

[bug #65474] [troff] spurious "warning: unbalanced 'el' request" when formatting zic(8) from TZDB project

Follow-up Comment #16, bug #65474 (group groff): [comment #11 comment #11:] > Could you explain why Tadziu's argument is cogent? I'm not > following it. In a nutshell, groff short-circuits in a quirky and nonintuitive way. In this code: .ie condition1 action1 .el .ie condition2 action2 .el

[bug #45502] [troff] .if, .ie, .el parsing incompatible with Unix V7, DWB, and Heirloom Doctools troff

Follow-up Comment #15, bug #45502 (group groff): [comment #12 comment #12:] > Wow, it's actually GNU _troff_ that aggressively reads through > the newline. That _was_ Carsten's original complaint. [comment #14 comment #14:] > That last version of the exhibit is now the basis of the > regression

[bug #45502] [troff] .if, .ie, .el parsing incompatible with Unix V7, DWB, and Heirloom Doctools troff

Follow-up Comment #8, bug #45502 (group groff): [comment #6 comment #6:] > GNU troff treats a newline and EOF equivalently in this case. Also I don't get how that's possible. GNU troff treats a newline at the end of an .if condition as an implied join with the following line. If EOF instead

[bug #45502] [troff] .if, .ie, .el parsing incompatible with Unix V7, DWB, and Heirloom Doctools troff

Follow-up Comment #7, bug #45502 (group groff): [comment #6 comment #6:] >If an `el` request or the >conditional expression of an `if` or `ie` request is followed >immediately by a newline, then (A) if in AT compatibility >mode, ignore the newline character as AT troff did This

[bug #65558] [UPGRADE] improve paragraph formatting within groff's line-at-a-time processing

: None ___ Follow-up Comments: --- Date: Thu 04 Apr 2024 11:52:22 PM CDT By: Dave Bug #40716 seeks to bring TeX's Knuth-Plass algorithm to groff. This is in progress but is a monumental, and thus slow, task. Th

Re: [PATCH] Distribute bootstrap and bootstrap.conf

On Sun, Mar 31, 2024 at 5:31 AM Colin Watson wrote: > I've omitted README.git to ensure that we still warn people who don't > know what they're doing that running "./bootstrap" may not be the right > place to start. *raises hand* I am one of those who don't know what they're doing -- at least

Re: paragraph-at-once breaking algorithm (was: Re: *roff hyphenation trivia challenge)

On Tue, Apr 2, 2024 at 10:14 PM Steve Izma wrote: > Good question. One experiment might be to choose a long paragraph > and typeset it in TeX, Heirloom troff, and groff and see what the > differences are. Yes, I know, I should probably walk the talk, > but I don't have Heirloom troff installed

Re: paragraph-at-once breaking algorithm (was: Re: *roff hyphenation trivia challenge)

On Tue, Apr 2, 2024 at 3:29 PM Dave Kemper wrote: > It would be interesting to know if someone with experience using the > Heirloom troff implementation of this algorithm (and with a good > typographic eye) has noticed the same problem there. That is, is it a > bug in the algo

[bug #65474] [troff] spurious "warning: unbalanced 'el' request" when formatting zic(8) from TZDB project

Follow-up Comment #10, bug #65474 (group groff): [comment #9 comment #9:] > I'll leave this one to cope with the issue of when we should > throw a warning, how. Tadziu makes a cogent argument (http://lists.gnu.org/r/groff/2021-03/msg00024.html) that the warning is not spurious. Bjarni might be

[bug #42675] \} considered as macro argument regarding register .$

Follow-up Comment #6, bug #42675 (group groff): [comment #0 original submission:] > Output with groff-1.22.2 on OpenBSD: > 0 1 1 2 [The above is what was entered in the original submission; savannah interprets a leading "0" on a line as list markup, so it renders incorrectly in the original

[bug #65474] spurious "warning: unbalanced 'el' request" when formatting zic(8) from TZDB project

Follow-up Comment #8, bug #65474 (group groff): Upon further digging, this appears to be a duplicate of bug #60260. Jim opened that bug report in 2021, but it's a restatement of an issue he previously brought up in 2013: http://lists.gnu.org/r/bug-groff/2013-02/msg3.html

Re: *roff hyphenation trivia challenge

On Tue, Apr 2, 2024 at 1:52 PM Dave Kemper wrote: > .ll 1n > \[rq]\%antidisestablishmentarianism\[lq] > .br > \%\[rq]antidisestablishmentarianism\[lq] Ha, if I'd looked at the output of something other than -Tascii, I'd have realized I got my "lq" and "rq" backw

[bug #65474] spurious "warning: unbalanced 'el' request" when formatting zic(8) from TZDB project

Follow-up Comment #5, bug #65474 (group groff): I agree with Paul that -ww is not intended as a style check. But I further contend that this is not subpar style. [comment #3 comment #3:] > The translator is not happy about how the instructions are > written, they are not informative enough

paragraph-at-once breaking algorithm (was: Re: *roff hyphenation trivia challenge)

On Tue, Apr 2, 2024 at 2:23 PM Steve Izma wrote: > I used TeX and LaTeX [...] and the oversetting of lines caused > by the periodic failure of the paragraph-justification algorithms > drove me nuts. [...] The many lines that overset by only a > few points made proofreading really difficult.

  1   2   3   4   5   6   7   8   9   10   >