fix(text): Render list items correctly #1137
Conversation
|
I think it's worth trying to change things such that generatiing we generate Unless that breaks the intended fix for the rfc-to-be. |
|
What is better about that superfluous empty line? (You can probably have one if you want with |
|
Look at it in context with the rest of the nested xml2rfc/tests/valid/elements.bom.text Lines 366 to 458 in fdb6fb8 <li> and <ol> at xml2rfc/tests/input/elements.xml Lines 472 to 473 in fdb6fb8 |
|
I have converted PR to a draft. |
kesara
changed the title
kesara
changed the title
kesara
force-pushed
the
fix/lists
branch
2 times, most recently
from
b64f6f1 to
ef83be5
Compare
|
The above list is a bit confusing? I only see impact from this PRs change on rfc9599. |
In most case there's |
|
@rjsparks, On that list I only found following I-D to have a output change because of the proposed fix: https://author-tools.ietf.org/diff?url_1=https://www.ietf.org/archive/id/draft-haynes-nfsv4-flexfiles-v2-00.txt&url_2=https://github.com/kesara/t4/raw/main/xml2rfc-1137-ids/draft-haynes-nfsv4-flexfiles-v2-00.txt |
|
Is it clear what the authors of that draft could do to get the output they originally wanted given this change? |
@rjsparks The original document with the issue RFC9599 has already published with the suggested workaround using This is the changes for latest draft from https://github.com/loghyr/flexfilesv2: Footnotes |
|
so this would leave the generated .txt file for flexfilesv2 unchanged with this PR applied then: |
|
@rjsparks yes, that will have unchanged output. |
I agree. |
@ajeanmahoney |
|
@rjsparks, @ajeanmahoney, @cabo, I think we have 3 options here:
BTW |
|
@rjsparks, @ajeanmahoney, @cabo, I think we have 3 alternatives here:
• Keep the empty line. (Current PR does this)
I’m not sure I know which line is empty, but maybe you are talking about the line with just a bullet that is being added?
The bullet wasn’t in the source, so it shouldn’t be in the output.
• Don't keep an empty line but add the missing list style (bullet/number/char).
The bullet wasn’t in the source, so it shouldn’t be in the output.
There should be exactly as many bullets as there are <li elements.
• Don't do anything and leave the bug as it-is.
(I need to look up what the bug was…)
BTW xml2rfc will probably have to add an empty line with the list style, when li contains an artwork, figure, sourcecode etc. as the first child to avoid confusion.
I’m not sure what the problem is
1. int main() {}
2. public static void main(String args[])
Sourcecode and artwork can be in exactly the same place where normal text can be, no newline needed.
Grüße, Carsten
|
|
@cabo: from the beginning of the PR: Note in the original report that the txt output is currently fundamentally different from the html/pdf output. If there's something to address here, it's that. The problem in the document mentioned in #1135 was addressed the same way I suggested the flexfilesv2 doc could be repaired above, and maybe the outcome of this whole thread is "If it hurts, don't do it" with advice to put the lead in a |
|
@rjsparks wrote:
Agree.
I wonder about giving a warning so that the user is aware that the input yields this variance in the output files. |
|
The examples in the referenced issues all show entirely reasonable text structures that for some reason aren't shown correctly in the plaintext form. |
Well, that example is bad because the text structure doesn't reflect the text content. |
Also agree. I would have suggested a lead-in sentence to the authors as a workaround, but the workaround suggested by @kesara in #1135 also works. This is an obscure corner case for nested lists that isn't covered by the Chicago Manual of Style, which says to use your word processor's outline list functionality to format lists correctly. FWIW I tried to get MS Word and Google Docs to recreate the following text from RFC 9599 and couldn't: I'm good with the workaround here. |
|
1. approximate preservation of the presence (and therefore timing)
of congestion marks on the L2 frames used to construct an IP
packet;
2. a. at high frequency of congestion marking, approximate
preservation of the proportion of congestion marks arriving
and departing;
b. at low frequency of congestion marking, approximate
preservation of the timing of congestion marks arriving and
departing.
First of all, people should be able to create exactly this nested list if it is their intention.
This is an <ol with two <li, where the second <li contains an <ol with two <li.
I have a hard time generating respect for a text formatting system that can’t do nested lists this trivial way.
Note that
1. approximate preservation of the presence (and therefore timing)
of congestion marks on the L2 frames used to construct an IP
packet;
a. at high frequency of congestion marking, approximate
preservation of the proportion of congestion marks arriving
and departing;
b. at low frequency of congestion marking, approximate
preservation of the timing of congestion marks arriving and
departing.
…also is a nested list that authors might want to create.
This is an <ol with one <li, which has a paragraph and an <ol with two <li as content.
Grüße, Carsten
|
|
@cabo Authors can create such a list with the formatting described here: I've called it a workaround, but it's not really. Using |
Well, allowing both mixed content (span-level) and t (block-level) sure is, avoiding the h word, interesting. One problem here is that in markdown there is no difference, which is pretty much the reason why kramdown-rfc is still generating v2 for these because the v2v3 converter seems to do something that generally works. One other problem is that the content models of <t and <li are different, which creates serious headaches. |
Fixes #1135
Fixes #1138
See changes made in 3712523 for context.
This change can affect if
olis used inside alias the first element and thelielement is inside anotherolelement.I could not find any published RFCs with XML that match the above condition.
These are the RFCs that I found that use
olas the first element inli:I didn't notice any changes in text output due to this change. But there are a few minor changes (with spacing) due to changes over the years.