Follow-up Comment #3, bug #68303 (group groff): On Monday, 4 May 2026 23:30:02 BST you wrote: > Update of bug #68303 (group groff): > > Severity: 3 - Normal => 4 - Important > Status: Confirmed => In Progress > Planned Release: None => 1.25.0 > Summary: asciify and nroff => [troff] > left_italic_corrected_node::asciify(macro*): Assertion `nodes != 0' failed. > > _______________________________________________________ > > Follow-up Comment #2: > > [comment #0 original submission:] > >> This is a strange one! > > ... > >> So the crash only happens in nroff not troff, also asciify left italic was >> corrected for troff in bug #67509. I found the issue running nroff on >> ms.ms >> with the new s.tmac (.I and .BI include italic correction). My latest >> s.tmac fixes the problem by not adding italic correction unless it is run >> by troff (.if t), but the underlying issue remains. > > Yeah, that's a good workaround for this bug, but definitely not something we > want to recommend to users.
I will probably reinstate the code as it was after asciify is fixed - s.tmac
is sufficiently convoluted as it is!
>> I wonder if the problem is limited to nodes which do nothing in nroff
>> mode.
>
> Pretty much. More precisely, (I think) it's limited to node types that are
> containers and typically populated by other nodes in troff mode, but are
> always empty in nroff mode.
>
> ...which describes `left_italic_corrected_node` and no other type I can
> think of. I remember being a little uneasy with the asymmetry between that
> and `italic_corrected_node` at the time I was doing my asciification revamp
> work.
>
> I experimented with not creating a `left_italic_corrected_node` in the first
> place in nroff mode, but that revealed a SEGV elsewhere (see forthcoming
> commit), and in any case I think I want to minimize the differences in
> output node topology between troff and nroff modes.
Parsing and building the node tree ought to be the same for nroff and troff,
the difference is what they output to grout for each node, and even then the
code could be the same, just filter out stuff which which has a null effect at
the resolution advertised for the output device it is writing grout for, or
device does not support (drawing commands).
> That way, if we
> develop more capable nroff-mode devices in the future, it will be less work
> and less code churn to support them. The better place to discard features
> the output device can't use is when translating the nodes to grout.
>
> Good catch! And as usual you found the root cause right away. Thanks!
>
Thanks.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68303>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
