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

Follow-up Comment #6, bug#59442 (group groff): [comment #5 comment #5:] > It occurs to me that I hadn't actually written up this idea with these > particulars before. This should probably be a new ticket. Now bug #65108. ___ Reply to

[bug #65098] merge branch deri-gropdf-ng to master

Follow-up Comment #4, bug#65098 (group groff): Red Tree I assume you have built my branch at some point, any Titian hues? Special Pleading (MR) = You were correct I was bending a general case to try to fit a special case. For Iterator I can see many

[bug #65109] [troff] no diagnostic in nroff mode when composite character unavailable

URL: Summary: [troff] no diagnostic in nroff mode when composite character unavailable Group: GNU roff Submitter: gbranden Submitted: Wed 03 Jan 2024 12:04:47 AM UTC

[bug #65099] 1.24.0 release goals

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

[bug #65108] [troff] support construction of general file name request arguments

URL: Summary: [troff] support construction of general file name request arguments Group: GNU roff Submitter: gbranden Submitted: Tue 02 Jan 2024 10:59:42 PM UTC Category:

[bug #58894] remove nonfunctional lines from groff font files

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

[bug #65098] merge branch deri-gropdf-ng to master

Follow-up Comment #3, bug#65098 (group groff): [comment #2 comment #2:] > Dealing with gropdf.pl separately, I have cobbled together a document > which may help you in the task. It is a list of all the diffs with a > following comment which describes what the changes accomplish. One way > of

[bug #65099] 1.24.0 release goals

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

[bug #65101] [mdoc] topics in "Name" section set in roman since 1.23.0

Follow-up Comment #5, bug#65101 (group groff): I won't wade into the minutiae of man-page rendering, but I'll address some larger points. [comment #4 comment #4:] > Why do you consider "all the manuals must look the same, by > force, regardless of what the authors have written" a goal? This is

[bug #65099] 1.24.0 release goals

Follow-up Comment #2, bug#65099 (group groff): [comment #1 comment #1:] > Is bug #59442 worth considering for 1.24? I think so, yes. And the file name-handling thing that needs its own ticket. ___ Reply to this item at:

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

Update of bug#59442 (group groff): Summary: [PATCH] groff.cpp: move soelim before preconv in constructed pipeline => [PATCH] groff.cpp: move soelim before preconv in constructed pipeline ___ Follow-up Comment #5:

[bug #65098] merge branch deri-gropdf-ng to master

Follow-up Comment #2, bug#65098 (group groff): Dealing with gropdf.pl separately, I have cobbled together a document which may help you in the task. It is a list of all the diffs with a following comment which describes what the changes accomplish. One way of handling this is to introduce each

[bug #65099] 1.24.0 release goals

Follow-up Comment #1, bug#65099 (group groff): Is bug #59442 worth considering for 1.24? ___ Reply to this item at: ___ Message sent via Savannah

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

Follow-up Comment #4, bug#59442 (group groff): [comment #1 comment #1:] > 1. What happens if a .so(urced) file has a non-ASCII character > in its filename? This seems more likely to work with the proposed change than without it. Currently, with preconv preceding soelim, preconv will change the

Re: uppercase german umlaut

[moving this back to the thread where it belongs] On 1/2/24, hoh...@posteo.de wrote: > If gpic gets Ä (0xc3 0x84) it complains about 0x84. > If gpic gets ä (0xc3 0xa4) it does not complain about 0xa4. True, but irrelevant, because *in neither case will the character be interpreted the way you

[bug #65101] [mdoc] topics in "Name" section set in roman since 1.23.0

Follow-up Comment #4, bug#65101 (group groff): >comment #2: >> Why are you doing this? >I said already. See comment #1. "I was pursuing my goal of consistent styling between rendered groff's own man(7) and mdoc(7) documents. In my opinion, it should be difficult to impossible

Re: Proposed GNU troff behavior change: require end-of-input macros to exit

Quoth hoh...@posteo.de: If gpic gets Ä (0xc3 0x84) it complains about 0x84. If gpic gets ä (0xc3 0xa4) it does not complain about 0xa4. gpic says: "invalid input character". So because both being above ASCII (8 bit area), what makes 0x84 wrong? It seems that 0x84 is located in a control area

Re: gpic and 8-bit characters (was: Proposed GNU troff behavior change: require end-of-input macros to exit)

Quoth G. Branden Robinson: So because both being above ASCII (8 bit area), I'm going to stop you right there. ASCII is not an 8-bit code. It is a 7-bit code, per USAS (later ANSI) X3.4-1968 and ECMA-6. https://ia800800.us.archive.org/35/items/enf-ascii-1968-1970/Image070917151315.pdf

Re: gpic and 8-bit characters (was: Proposed GNU troff behavior change: require end-of-input macros to exit)

> > So because both being above ASCII (8 bit area), > ASCII is not an 8-bit code. It is a 7-bit code, [...] Latin-1 is a superset of ASCII, with ASCII occupying the lower half, so technically I would argue that the above statement "being above ASCII" (namely, being in the area where the