[bug #65967] [PATCH] [docs] Say "input" instead of "input file" where appropriate

Planned Release: None ___ Follow-up Comments: --- Date: Tue 09 Jul 2024 01:37:50 AM CDT By: Dave The attached patch changes the term "input file" to "input" in groff documentation in cases where

[bug #65886] [PATCH] repeated word in some man pages

Follow-up Comment #3, bug #65886 (group groff): As a bonus (mostly because this doesn't seem to warrant a new ticket), I've attached a second patch to address a small number of other typos in the Texinfo manual and one man page. (file #56235)

[bug #65886] [PATCH] repeated word in some man pages

Update of bug #65886 (group groff): Summary: repeated word in some man pages => [PATCH] repeated word in some man pages ___ Follow-up Comment #2: As the cited line numbers will eventually get stale, I've converted the

[bug #65962] [troff] want stack limit reduced to <=100

Follow-up Comment #3, bug #65962 (group groff): This bug report does highlight one bit of inaccurate wording in the manual, though. [comment #1 comment #1:] > You can disable this protective measure, or > raise the limit, by setting the 'slimit' register. In fact, you can also lower

[bug #65961] pre-html.cpp: suppress spurious warnings from buggy pnmcrop

Update of bug #65961 (group groff): Summary: pre-html.cpp: use option "-blank-image=pass" for "pnmcrop" to avoid warnings => pre-html.cpp: suppress spurious warnings from buggy pnmcrop ___ Follow-up Comment #1: As Ingo

[bug #65936] [grohtml] litters working directory with 0-length image files

Follow-up Comment #7, bug #65936 (group groff): [comment #4 comment #4:] > I carelessly rendered Git HEAD's version of "ms.ms" in comment #3. > > When I render 1.23.0's "ms.ms" with 1.23.0, I do get _some_ > complaints from _pnmcrop_ and _pnmtopng_, and _some_ zero-length > files, but not 59 of

[bug #65936] [grohtml] litters working directory with 0-length image files

Follow-up Comment #6, bug #65936 (group groff): [comment #3 comment #3:] > We do have the following recent note in our "PROBLEMS" file > (unfortunately, I think most distributors don't ship it, and > to be fair we don't install it). Bug #61950 seeks to give user-relevant items in this file more

[bug #65962] [troff] want stack limit reduced to <=100

Follow-up Comment #2, bug #65962 (group groff): Since the value is user-configurable, and since the reason for the default _is_ documented (and reasonable for the reasons Branden mentioned), I agree it shouldn't be changed. But the source code does lack a comment where DEFAULT_INPUT_STACK_LIMIT

[bug #64043] [ms] mixing formatting requests with macro calls produces different unspecified behavior with groff than with AT troff

Follow-up Comment #13, bug #64043 (group groff): Sounds good. While the bug has been Rejected for over a year, the discussion seemed have been left in limbo, so I wanted to make sure everything that might have been resolved has been resolved. Only one other potentially loose thread that I see:

[bug #64043] [ms] mixing formatting requests with macro calls produces different unspecified behavior with groff than with AT troff

Follow-up Comment #10, bug #64043 (group groff): Additional discussion on the email list can be found in the threads starting at: * http://lists.gnu.org/r/groff/2023-04/msg00074.html (the start of a thread linked in the original submission) * http://lists.gnu.org/r/groff/2023-04/msg00137.html *

[bug #64043] [ms] mixing formatting requests with macro calls produces different unspecified behavior with groff than with AT troff

Update of bug #64043 (group groff): Summary: mixing formatting requests with macro calls produces different unspecified behavior with groff than with AT troff => [ms] mixing formatting requests with macro calls produces different unspecified behavior with groff than with AT troff

[bug #65955] [troff] enable "input" warning category by default and add one-off alert

Follow-up Comment #1, bug #65955 (group groff): I raised a concern about discontinuing native ISO 8859-1 support on the email list (http://lists.gnu.org/r/groff/2024-05/msg00030.html). There were no further replies in the thread. ___

[bug #65930] [me] large values of register `tv` cause infinite trap recursion

Follow-up Comment #12, bug #65930 (group groff): It might also be worth your confirming that the patch file I attached (comment #5) matches the one you're applying, just to verify that I edited it correctly. ___ Reply to this item at:

[bug #65930] [me] large values of register `tv` cause infinite trap recursion

Follow-up Comment #11, bug #65930 (group groff): Using the bug-65930b.me test file from comment #8, I can reproduce the problem in groff 1.22.4; using tv-stack-limit.me from comment #2, I cannot. $ groff --version | head -n 1 GNU groff version 1.22.4 $ cat bug-65930b.me .\"mso e.tmac .br .nr $v

[bug #65930] [me] large values of register `tv` cause infinite trap recursion

Follow-up Comment #10, bug #65930 (group groff): [comment #9 comment #9:] > These aren't exercising the formatter in the same way; they're > using different output drivers Yes, the intent was to show that I didn't see the bug with either the devps or devascii output driver. Sorry I was unclear

[bug #65930] [me] large values of register `tv` cause infinite trap recursion

Follow-up Comment #7, bug #65930 (group groff): OK. So. The patch has no effect on my original test file. Test fails with it, fails without it. Your updated test file (from comment #2) does not generate the error under any circumstances for me. Not with patched -me, not with unpatched, not

[bug #65930] [me] large values of register `tv` cause infinite trap recursion

Follow-up Comment #5, bug #65930 (group groff): [comment #2 comment #2:] > Try this patch: First speed bump: patch fails to apply. This turns out to be because the tab characters in the patch have been reduced to strings of spaces. I initially suspected being bitten by

[bug #65930] [me] large values of register `tv` cause infinite trap recursion

Follow-up Comment #3, bug #65930 (group groff): [comment #2 comment #2:] > Try this patch: Thanks! I'll give this a shot once I'm done chasing down a bash issue. > If I'm right about Allman not contemplating multi-line headers/footers His "-me Reference Manual" explicitly addressed such

[bug #65936] [grohtml] grohtml litters working directory with 0-length image files

Follow-up Comment #1, bug #65936 (group groff): What version of groff are you running? I can't reproduce this under either 1.22.4 or a recent git build (1.23.0.1262-4c62e-dirty). That is, I do get 59 .png files, but they all have content (file sizes vary from 553 to 28196 bytes), and some are

[bug #65936] [grohtml] grohtml litters working directory with 0-length image files

Update of bug #65936 (group groff): Category:None => Driver grohtml Item Group:None => Incorrect behaviour ___ Reply to this item at:

[bug #65930] [me] Large values of register "tv" cause fatal error

ed Release: None ___ Follow-up Comments: --- Date: Sat 29 Jun 2024 03:48:35 PM CDT By: Dave This bug is in at least 1.22.4 and 1.23. The below example uses the register name "$v" rather than its

[bug #65929] groff.texi.in: .linetabs example input has vestigial line

: None ___ Follow-up Comments: --- Date: Fri 28 Jun 2024 09:43:11 PM CDT By: Dave [http://git.savannah.gnu.org/cgit/groff.git/commit/?id=ce4ec3b65 Commit ce4ec3b65] added this example: .de Tabs . ds x a\t\c . ds y b\t\c . ds z c .

[bug #65910] Some dashed ellipse sizes produce irregular dashes

Follow-up Comment #1, bug #65910 (group groff): (spawned from bug #65901) ___ Reply to this item at: ___ Message sent via Savannah

[bug #60052] [tbl] want option to output HTML

Follow-up Comment #1, bug #60052 (group groff): [comment #0 original submission:] > That would render groff_hdbtl(7) unnecessary s/hdbtl/hdtbl/, to get to an existent man page. But I wonder if there is also a thinko here: elsewhere (e.g., bug #63837) it seems like tbl having this functionality

[bug #63837] [grohtml] only the last page of multi-page tables is rendered

Follow-up Comment #3, bug #63837 (group groff): [comment #0 original submission:] > That leaves _only_ tbl as a reason for pre-grohtml to exist. Bug #60052 seeks to abolish that reason. ___ Reply to this item at:

[bug #63587] [troff] set .R register to maximum representable integer

Follow-up Comment #10, bug #63587 (group groff): [comment #5 comment #5:] > I can think of no situation where a user might need 10,001 > registers, so, despite this number having no clear connection to > any internal groff limit, it's probably a reasonable limit to > _claim_ to the user who asks.

[bug #65763] strictly compare strings in macro packages

Update of bug #65763 (group groff): Severity: 3 - Normal => 2 - Minor ___ Reply to this item at: ___ Message

[bug #65763] strictly compare strings in macro packages

Update of bug #65763 (group groff): Severity: 2 - Minor => 3 - Normal ___ Follow-up Comment #3: ("cc" bug that affects this ticket (and probably others) reported in

[bug #65763] strictly compare strings in macro packages

Update of bug #65763 (group groff): Severity: 3 - Normal => 2 - Minor ___ Follow-up Comment #2: [comment #1 comment #1:] > I suspect this may be low priority, I agree. > perhaps so low that

[bug #65886] repeated word in some man pages

Follow-up Comment #1, bug #65886 (group groff): Not all repeated words are erroneous. You have to look at the context. [comment #0 original submission:] > ! ./man/groff.7.man: 5736 --> to > ! ./man/groff_diff.7.man: 772 --> to These are both copies of the same sentence, the relevant phrase of

[bug #24050] [mm] footnote/end-of-page problem

Update of bug #24050 (group groff): Depends on: => bugs #56499 ___ Follow-up Comment #5: [comment #3 comment #3:] > This (mis)behavior is consistent with DWB 3.3 and Heirloom Doctools mm.

[bug #24050] [mm] footnote/end-of-page problem

Follow-up Comment #4, bug #24050 (group groff): Problem originally reported on bug-groff (http://lists.gnu.org/r/bug-groff/2007-07/msg00010.html). That report offers no additional information about the problem, but does tell who reported it. There were no follow-ups on the list.

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

Follow-up Comment #4, bug #65710 (group groff): [comment #3 comment #3:] > Bjarni's prescription was much too strong. Bjarni's "prescription" was an editorial recommendation to users that had no bearing on his proposed code change. Users would be free to ignore it. The current proposal--to

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

Follow-up Comment #13, bug #55154 (group groff): [comment #11 comment #11:] > I presume this is due to this explanation in the Texinfo manual: > > -- Request: .char c ['"'][contents] > Every time C is to be output, CONTENTS is processed in a > temporary environment and the result

[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 |

  1   2   3   4   5   6   7   8   9   10   >