The line numbering in brat seems somewhat inconsistent. Consider the following cases (tested in the live embedding demo):
Single line
A single line obviously renders ok.
"text": "Ed O'Kelley was the man who shot the man who shot Jesse James. And another sentence.",
Multiple lines
If we have line breaks outside span annotations, all is ok as well. Yet, I somehow feel that the second line should also carry a number. It looks like a glitch not to have one.
"text": "Ed O'Kelley was the man who shot the man who shot Jesse James.\n\nAnd another sentence.",
Linebreaks within span
If we have line breaks inside a span, then the number in brat no longer corresponds to the actual line numbering in the document.
"text": "Ed O'Kelley was the man who shot the man who shot Jesse\n\nJames.And another sentence.",
Expected - I would expect that the line breaks are only delayed and not completely consumed. So I would expect something like this:
Actual - However, what brat renders is this:
The optimal solution here would be to split the "Jesse James" into two fragments, but the visualization does not support this (yet) - see #1101. I opened this issue for the numbering because it might be solvable without fixing #1101.
The line numbering in brat seems somewhat inconsistent. Consider the following cases (tested in the live embedding demo):
Single line
A single line obviously renders ok.
Multiple lines
If we have line breaks outside span annotations, all is ok as well. Yet, I somehow feel that the second line should also carry a number. It looks like a glitch not to have one.
Linebreaks within span
If we have line breaks inside a span, then the number in brat no longer corresponds to the actual line numbering in the document.
Expected - I would expect that the line breaks are only delayed and not completely consumed. So I would expect something like this:
Actual - However, what brat renders is this:
The optimal solution here would be to split the "Jesse James" into two fragments, but the visualization does not support this (yet) - see #1101. I opened this issue for the numbering because it might be solvable without fixing #1101.