XSweet issueshttps://gitlab.coko.foundation/groups/XSweet/-/issues2018-03-15T16:56:20Zhttps://gitlab.coko.foundation/XSweet/XSweet/-/issues/86Dialogue formatted with tabs2018-03-15T16:56:20ZAlex ThegDialogue formatted with tabsSee Garcia Ch 3 (files on #84) for an interesting case of dialogue formatting.
The quote is formatted as dialogue with a speaker designated, and the dialogue tabbed over. Perhaps we could eventually do something with these tabs.
On ho...See Garcia Ch 3 (files on #84) for an interesting case of dialogue formatting.
The quote is formatted as dialogue with a speaker designated, and the dialogue tabbed over. Perhaps we could eventually do something with these tabs.
On hold and low priority; just parking this here as an interesting example.https://gitlab.coko.foundation/XSweet/editoria_typescript/-/issues/13Errors in the "reduce" step2017-05-25T16:30:57ZAlex ThegErrors in the "reduce" step[resduce-errors.txt](/uploads/37753140cf716f6426217b7519133f8c/resduce-errors.txt)
Looks like the most recent changes to the "editoria-reduce" step cause it to fail on most of the books. Here are the error messages I get when it runs...[resduce-errors.txt](/uploads/37753140cf716f6426217b7519133f8c/resduce-errors.txt)
Looks like the most recent changes to the "editoria-reduce" step cause it to fail on most of the books. Here are the error messages I get when it runs. You can see that errors happen on all the chapters from most books, but not in the books by Gilbert or Goldstein.
The errors stop the conversions from producing their final typescripted output Can you tell what's going on?Wendell PiezWendell Piezhttps://gitlab.coko.foundation/XSweet/XSweet/-/issues/87Don't distinguish between otherwise equivalent style signatures on "text-alig...2019-07-07T22:39:46ZAlex ThegDon't distinguish between otherwise equivalent style signatures on "text-align: left" aloneGarcia bibliography: [e_BibliographyGGv6.docx](/uploads/c994d731e262919ab6c4a84d8df7ec66/e_BibliographyGGv6.docx)
Alex, check this for entries and lines that are promoted to headers. Hopefully considering the display text differentl...Garcia bibliography: [e_BibliographyGGv6.docx](/uploads/c994d731e262919ab6c4a84d8df7ec66/e_BibliographyGGv6.docx)
Alex, check this for entries and lines that are promoted to headers. Hopefully considering the display text differently (#81) will stop some of the spurious promotions.1.0.0Wendell PiezWendell Piezhttps://gitlab.coko.foundation/XSweet/XSweet/-/issues/88Bibliographic entries are indented farther than they should be.2018-03-14T19:58:45ZAlex ThegBibliographic entries are indented farther than they should be.See #87 for files (Garcia bib)
The way the majority of these bibliography entries are formatted, they display as indented farther to the right than they do in the Word doc:
```html
<p style="font-family: Times New Roman; font-size: 12p...See #87 for files (Garcia bib)
The way the majority of these bibliography entries are formatted, they display as indented farther to the right than they do in the Word doc:
```html
<p style="font-family: Times New Roman; font-size: 12pt; margin-left: 36pt; padding-left: 36pt; text-indent: -36pt">Aiton, Arthur Scott. “Real Hacienda in New Spain under the First Viceroy.” <i>Hispanic American Historical Review</i> 6, no. 4 (1926): 232–45.</p>
```
I think it's because there's both margin and padding - removing either one makes it display correctly. Low priority because I expect this formatting would be lost when imported into Editoria.Wendell PiezWendell Piezhttps://gitlab.coko.foundation/XSweet/XSweet/-/issues/89Some bib entries formatting coming through inconsistently2018-03-15T16:28:13ZAlex ThegSome bib entries formatting coming through inconsistentlyGarcia bib (file on #87)
The bibliography entry for "Haring, C. H." is not indented like the other entries. The other entries all have margin-left, text-indent, and padding-left properties:
```html
<p style="margin-left: 36pt; text...Garcia bib (file on #87)
The bibliography entry for "Haring, C. H." is not indented like the other entries. The other entries all have margin-left, text-indent, and padding-left properties:
```html
<p style="margin-left: 36pt; text-indent: -36pt; padding-left: 36pt; font-family: Times New Roman; font-size: 12pt">
```
But this one only has:
```html
<p style="font-family: Times New Roman; font-size: 12pt">
```
Can you tell why this is extracted differently than the others? There are a few more similar cases in the bib. However it's implemented under the hood, we'd want the conversion to reflect the actually display as much as possible.
Incidentally, it also has a spurious line break in it, but this was introduced by the author so nothing to do about it.1.0.0Wendell PiezWendell Piezhttps://gitlab.coko.foundation/XSweet/XSweet/-/issues/90Some indentations not reflected in HTML2018-03-22T19:18:06ZAlex ThegSome indentations not reflected in HTMLGarcia ch 4: [d_Chapter4GGv5.docx](/uploads/394c8e688977abb7158be3801f068a21/d_Chapter4GGv5.docx)
The first 3 paragraphs are indented in the HTML as `<p style="text-indent: 36pt">`, but starting with the 4th paragraph ("The urban struct...Garcia ch 4: [d_Chapter4GGv5.docx](/uploads/394c8e688977abb7158be3801f068a21/d_Chapter4GGv5.docx)
The first 3 paragraphs are indented in the HTML as `<p style="text-indent: 36pt">`, but starting with the 4th paragraph ("The urban structures..."), the indentation stops. This appears to come from the styles. The first 3 paragraphs are "Normal + First Line: 0.5" but the 4th on are just "Normal." However, these paragraphs are indeed indented when displayed in Word.
Is there a way to respect these 1st-line indentations that aren't coming through? This is related to #81 in that we want to recreate what's actually displayed in Word.1.0.0Wendell PiezWendell Piezhttps://gitlab.coko.foundation/XSweet/XSweet/-/issues/91Centering not captured in HTML2018-03-14T19:51:20ZAlex ThegCentering not captured in HTMLGilbert: [a01_ti.docx](/uploads/3700d924a92610925a5f80dab0c0031e/a01_ti.docx)
The last line is centered in the Word doc but not in the HTML. How come?
On hold for now as text alignment doesn't port into Editoria for now.Gilbert: [a01_ti.docx](/uploads/3700d924a92610925a5f80dab0c0031e/a01_ti.docx)
The last line is centered in the Word doc but not in the HTML. How come?
On hold for now as text alignment doesn't port into Editoria for now.https://gitlab.coko.foundation/XSweet/XSweet/-/issues/92Header promotion example for Alex to check2019-07-07T22:40:39ZAlex ThegHeader promotion example for Alex to checkIn Gilbert, fwd: [a03_fwd.docx](/uploads/69b43e22a61426ec09e83037cf875c35/a03_fwd.docx)
Why is "Holly Near" not labeled a header, but "12/21/2014" is?
For Alex to check after next iteration of header promotionIn Gilbert, fwd: [a03_fwd.docx](/uploads/69b43e22a61426ec09e83037cf875c35/a03_fwd.docx)
Why is "Holly Near" not labeled a header, but "12/21/2014" is?
For Alex to check after next iteration of header promotion1.0.0Alex ThegAlex Theghttps://gitlab.coko.foundation/XSweet/XSweet/-/issues/93Normalize invisible formatting on single spaces2017-05-26T12:46:07ZAlex ThegNormalize invisible formatting on single spacesSee Weaver, Ch 1: [b05_ch01.docx](/uploads/e4065a9648f08d3aa103cc2e1b96b74e/b05_ch01.docx)
Low priority improvement for later.
Sometimes, there will be single spaces that are formatted differently than the surrounding text. In th...See Weaver, Ch 1: [b05_ch01.docx](/uploads/e4065a9648f08d3aa103cc2e1b96b74e/b05_ch01.docx)
Low priority improvement for later.
Sometimes, there will be single spaces that are formatted differently than the surrounding text. In this example, there are 2 bold spaces. While this doesn't affect how it looks to the eye, it leads to cluttered formatting under the hood.
```html
To which he might have replied<b> </b>as he had to a showbiz promoter 25 years earlier:<b> </b>“Act? That was no act; that
```
Can you implement a rule that looks for tags that
1. enclose only a space or tab, and
2. denote bold, underline, or italics
And then scrub these out in a cleanup step?https://gitlab.coko.foundation/XSweet/XSweet/-/issues/94Inconsistent indentation2018-03-15T16:27:37ZAlex ThegInconsistent indentationSee Gilbert ch 2: [b06_ch02.docx](/uploads/6bd821eeabee201b9cd021c00aff5382/b06_ch02.docx)
The indented spot starting with "Gramma?", has the same indentation level as the dialogue right below it:
![Screen_Shot_2017-04-19_at_11.09.3...See Gilbert ch 2: [b06_ch02.docx](/uploads/6bd821eeabee201b9cd021c00aff5382/b06_ch02.docx)
The indented spot starting with "Gramma?", has the same indentation level as the dialogue right below it:
![Screen_Shot_2017-04-19_at_11.09.32_AM](/uploads/c383012829026bab0f8fe39033c0547c/Screen_Shot_2017-04-19_at_11.09.32_AM.png)
But in the HTML, there are 3 lines that have a "padding-left: 18pt," which makes them appear more indented than they do in the Word doc:
“How come some of them have their shawls over their heads?”
“Nisht shawl,” Gramma corrects, “tallis.”
“But why are they bowing up and down?”
Low priority as indentation doesn't port into Editoria.1.0.0https://gitlab.coko.foundation/XSweet/XSweet/-/issues/95Handle lists2017-08-09T19:00:55ZAlex ThegHandle listsKohl-Arenas, Ch 4:
[b_kohl-arenas_ch4.docx](/uploads/c6e9bbf254f76892d7c88f2b3ebc7b98/b_kohl-arenas_ch4.docx)
This is an example of list items that should eventually be extracted and ported into Editoria.
Search for "One in five male ...Kohl-Arenas, Ch 4:
[b_kohl-arenas_ch4.docx](/uploads/c6e9bbf254f76892d7c88f2b3ebc7b98/b_kohl-arenas_ch4.docx)
This is an example of list items that should eventually be extracted and ported into Editoria.
Search for "One in five male subjects" for the first list item.Alex ThegAlex Theghttps://gitlab.coko.foundation/XSweet/XSweet/-/issues/96Only use header promotion inside `<div class="docx-body">`2017-04-21T22:46:50ZAlex ThegOnly use header promotion inside `<div class="docx-body">`[e.BoylesChapter3-9RINSED.html](/uploads/b7dcd4064381d3b1cfe6cf81c7a14700/e.BoylesChapter3-9RINSED.html)
In Boyles Ch 3, most of the footnotes get promoted to headers. Can header promotion be limited to what's inside the `<div class=...[e.BoylesChapter3-9RINSED.html](/uploads/b7dcd4064381d3b1cfe6cf81c7a14700/e.BoylesChapter3-9RINSED.html)
In Boyles Ch 3, most of the footnotes get promoted to headers. Can header promotion be limited to what's inside the `<div class="docx-body">`?Wendell PiezWendell Piezhttps://gitlab.coko.foundation/XSweet/XSweet/-/issues/97"Chapter One -2017-04-21T13:39:08ZAlex Theg"Chapter One -https://gitlab.coko.foundation/XSweet/XSweet/-/issues/98"Chapter One - " text dropped from extraction2018-03-15T20:05:00ZAlex Theg"Chapter One - " text dropped from extractionBoyles Ch 1 [e._Boyles_Chapter_1.docx](/uploads/86a58da52d6b60a5568a284f3225f592/e._Boyles_Chapter_1.docx)
[e.BoylesChapter1-1EXTRACTED.html](/uploads/dee5c6517f5f46d846e33d0922fa20cb/e.BoylesChapter1-1EXTRACTED.html)
[e.BoylesChapter1...Boyles Ch 1 [e._Boyles_Chapter_1.docx](/uploads/86a58da52d6b60a5568a284f3225f592/e._Boyles_Chapter_1.docx)
[e.BoylesChapter1-1EXTRACTED.html](/uploads/dee5c6517f5f46d846e33d0922fa20cb/e.BoylesChapter1-1EXTRACTED.html)
[e.BoylesChapter1-9RINSED.html](/uploads/da01d16780e6f8cc2dd7e8b02877db1c/e.BoylesChapter1-9RINSED.html)
The top level header reads "Chapter One - Introduction" in Word. But the text "Chapter One - " is not coming through from Word into html. It seems to have been implemented as some kind of list in Word, but I can't find anything evidence of it in the initial extraction.
![Screen_Shot_2017-04-21_at_1.42.36_AM](/uploads/55402036b54e43e7429bb576ce93278c/Screen_Shot_2017-04-21_at_1.42.36_AM.png)
Is there an easy fix?Wendell PiezWendell Piezhttps://gitlab.coko.foundation/XSweet/XSweet/-/issues/99Split header promotion logic by display and by Style into 2 distinct pathways2017-04-23T22:06:11ZAlex ThegSplit header promotion logic by display and by Style into 2 distinct pathwaysContinuing after implementing #81, @wendell is separating these two different approaches out from each other:
1. all the logic to consider header promotion based just on display properties
2. capturing information from Word styles, whi...Continuing after implementing #81, @wendell is separating these two different approaches out from each other:
1. all the logic to consider header promotion based just on display properties
2. capturing information from Word styles, which will happening eventually but has now been turned off.Wendell PiezWendell Piezhttps://gitlab.coko.foundation/XSweet/XSweet/-/issues/100Ignore all character style information from the paragraph level2017-08-16T18:17:08ZAlex ThegIgnore all character style information from the paragraph levelSome paragraphs that look like normal text in Word are being extracted as bold, which has the added effect of sabotaging header promotion.
Here are 2 examples of where the extraction goes wrong:
[bBowenChapter1.docx](/uploads/ad1ce...Some paragraphs that look like normal text in Word are being extracted as bold, which has the added effect of sabotaging header promotion.
Here are 2 examples of where the extraction goes wrong:
[bBowenChapter1.docx](/uploads/ad1cea812824d5353237f94b735fe809/bBowenChapter1.docx)
[outputs_bowen_ch1.zip](/uploads/fb532748f7160c323193a5e4049bcb5d/outputs_bowen_ch1.zip)
Bad bolding:
* "In the second half of the 19th century..."
* "In a modern global food system characterized..."
* "When people want to show how protecting terroir..."
[bBowenChapter3.docx](/uploads/6de2759e35daa9478f546cda6904507b/bBowenChapter3.docx)
[outputs_bowen_ch3.zip](/uploads/cbe334e1702d943eb76caebbef932f09/outputs_bowen_ch3.zip)
Bad bolding:
* "The standard that regulates tequila production..."
* "As I discuss later in this chapter, several..."
* "Tequila’s regulatory infrastructure sounds like something..."
* "The main premise behind any DO is..."
In both of these cases, it stops almost all of the headings that should be promoted from being caught. Headers are denoted with bold. If you look at the digest-paragraph output, you'll see that p style correctly included in the assimilated list of discrete styles, but it doesn't make it through into the "filtered" group because the data-average-length gets skewed too high (120+ character average length) by the improperly bolded paragraphs, causing the style to be dropped from consideration.
So, fixing the underlying incorrect bolding issue will kill two birds. I will also keep an eye out for other places a "<120char" rule stops correct promotions.Wendell PiezWendell Piezhttps://gitlab.coko.foundation/XSweet/XSweet/-/issues/101Line break inside a paragraph2017-06-07T20:17:25ZAlex ThegLine break inside a paragraphIn the original Word file for Powell00 (5-10-17-conversions.zip), there’s a paragraph that contains a line break in it: `<w:br/>`
This comes between the very last line of the paragraph and the rest of it (between “...scholarly speculati...In the original Word file for Powell00 (5-10-17-conversions.zip), there’s a paragraph that contains a line break in it: `<w:br/>`
This comes between the very last line of the paragraph and the rest of it (between “...scholarly speculation about” and ““interpolated” non-genuine...”. It’s invisible in the original Word file, unless you change the font size of the paragraph, in which case you can see the paragraph reflow but preserve the break.
When it goes through XSweet, the break is preserved where it originally is:
```html
...of scholarly speculation about <br class="br" />“interpolated” non-genuine portions of the Homeric and Hesiodic poems. </p>
```
Right now, breaks don't go through Typescript, so it's simply dropped. But what might cause a line break to show up inside a paragraph in a Word file in the first place? Any ideas?
Here’s the paragraph from the original Word file xml:
```xml
<w:p w14:paraId="749A5FF6" w14:textId="77777777" w:rsidR="00687B92" w:rsidRPr="008B5A47" w:rsidRDefault="00687B92" w:rsidP="00687B92">
<w:pPr>
<w:spacing w:line="480" w:lineRule="auto"/>
<w:rPr>
<w:rFonts w:ascii="Times New Roman" w:hAnsi="Times New Roman" w:cs="Times New Roman"/>
</w:rPr>
</w:pPr>
<w:r w:rsidRPr="008B5A47">
<w:rPr>
<w:rFonts w:ascii="Times New Roman" w:hAnsi="Times New Roman" w:cs="Times New Roman"/>
</w:rPr>
<w:tab/>
<w:t xml:space="preserve">It is common to speak of “rhapsodic interpolations” in examining ancient texts, but they were probably uncommon, at least in archaic literature. A rhapsode may make up verses to suit his pleasure, but unless they are written down in the tradition that becomes canonical, that is copied and recopied, they do not survive. Therefore the texts of Homer and Hesiod that we possess </w:t>
</w:r>
<w:r>
<w:rPr>
<w:rFonts w:ascii="Times New Roman" w:hAnsi="Times New Roman" w:cs="Times New Roman"/>
</w:rPr>
<w:t>must be</w:t>
</w:r>
<w:r w:rsidRPr="008B5A47">
<w:rPr>
<w:rFonts w:ascii="Times New Roman" w:hAnsi="Times New Roman" w:cs="Times New Roman"/>
</w:rPr>
<w:t xml:space="preserve"> substantially the texts that these poets composed, recorded by dictation in the </w:t>
</w:r>
<w:r>
<w:rPr>
<w:rFonts w:ascii="Times New Roman" w:hAnsi="Times New Roman" w:cs="Times New Roman"/>
</w:rPr>
<w:t>eighth c</w:t>
</w:r>
<w:r w:rsidRPr="008B5A47">
<w:rPr>
<w:rFonts w:ascii="Times New Roman" w:hAnsi="Times New Roman" w:cs="Times New Roman"/>
</w:rPr>
<w:t>entury BC at the dawn of alphabetic literacy. Of course such texts are liable to the usual distortions that come from copying and recopying, but these distortions are always minor and do not affect the main narrative</w:t>
</w:r>
<w:r>
<w:rPr>
<w:rFonts w:ascii="Times New Roman" w:hAnsi="Times New Roman" w:cs="Times New Roman"/>
</w:rPr>
<w:t xml:space="preserve">, in spite of an inordinate amount of scholarly speculation about
</w:t>
</w:r>
<w:r>
<w:rPr>
<w:rFonts w:ascii="Times New Roman" w:hAnsi="Times New Roman" w:cs="Times New Roman"/>
</w:rPr>
<w:br/>
<w:t>“interpolated” non-genuine portions of the Homeric and Hesiodic poems
</w:t>
</w:r>
<w:r w:rsidRPr="008B5A47">
<w:rPr>
<w:rFonts w:ascii="Times New Roman" w:hAnsi="Times New Roman" w:cs="Times New Roman"/>
</w:rPr>
<w:t xml:space="preserve">. </w:t>
</w:r>
</w:p>
```Wendell PiezWendell Piezhttps://gitlab.coko.foundation/XSweet/XSweet/-/issues/102Inline italics lost because "font-style: italic" applied at paragraph level2018-03-22T22:50:50ZAlex ThegInline italics lost because "font-style: italic" applied at paragraph levelIn Powell00, the heading “[b]The Hittite-Hurrian Kingship in Heaven and The Song of Ullikummi” has some inline italics that don’t come through, because the paragraph has a `font-style: italic` applied to it. This means that the whole li...In Powell00, the heading “[b]The Hittite-Hurrian Kingship in Heaven and The Song of Ullikummi” has some inline italics that don’t come through, because the paragraph has a `font-style: italic` applied to it. This means that the whole line shows in the browser in italics, and the differentiation between the normal text and the italics is hidden. Removing the paragraph-level italic styling means you can see the inline italics again.
Everything in the paragraph is contained within a series of spans - there is no text in this `<p>` that's not enclosed by another tag. In Word, the text in the spans that don't specify italics come through as normal, unitalicized text. But in the extracted version, the entire line is italicized. Put a different way, in Word, the spans in the paragraph that specify style seem to override *all* the paragraph-level style information, but in the extracted html, they don't.
Is there a good way to correct for this?
This is how it's extracted:
```html
<p style="font-family: Times New Roman; font-style: italic; color: #19191B">
<span style="font-family: Times New Roman; font-weight: bold; color: #19191B">
<b>[b]</b>
</span>
<span style="font-family: Times New Roman; color: #19191B">The Hittite-Hurrian
</span>
<span style="font-family: Times New Roman; font-style: italic; color: #19191B">
<i>Kingship in Heaven </i>
</span>
<span style="font-family: Times New Roman; color: #19191B">and </span>
<span style="font-family: Times New Roman; font-style: italic; color: #19191B">
<i>The Song of Ullikummi</i>
</span>
</p>
```
Interesting to note that this also gets promoted to a header, and the bolding, while preserved, is thus not apparent in a browser (it is if you change this back to a `<p>` again though).Wendell PiezWendell Piezhttps://gitlab.coko.foundation/XSweet/XSweet/-/issues/103Capture carriage returns from Word2017-06-07T20:17:26ZAlex ThegCapture carriage returns from WordSee Powell01.
There is a poem at the very end of this chapter, and many of the different lines are being combined into one paragraph, losing the returns that separate the lines. This is because the xml carriage return tag `<w:cr/>` c...See Powell01.
There is a poem at the very end of this chapter, and many of the different lines are being combined into one paragraph, losing the returns that separate the lines. This is because the xml carriage return tag `<w:cr/>` comes through as an empty span in the extraction step. Can you please add the xml carriage return tag to the list of elements XSweet pays attention to?
Compare the two examples below.
1. Here are two lines in Word that get combined into one p in the html. In the xml, they are separated by a carriage return tag `<w:cr/>`, and many lines like this are enclosed in one single `<w:p>`. This get extracted as a series of spans inside one `<p>`.
```xml
<w:r w:rsidRPr="008B5A47">
<w:rPr><w:rFonts w:ascii="Times New Roman" w:hAnsi="Times New Roman" w:cs="Times New Roman"/></w:rPr><w:tab/>
<w:t>no flood will carry you away.</w:t>
</w:r>
<w:r w:rsidRPr="008B5A47">
<w:rPr><w:rFonts w:ascii="Times New Roman" w:hAnsi="Times New Roman" w:cs="Times New Roman"/></w:rPr><w:cr/></w:r>
<w:r w:rsidRPr="008B5A47">
<w:rPr><w:rFonts w:ascii="Times New Roman" w:hAnsi="Times New Roman" w:cs="Times New Roman"/></w:rPr><w:tab/>
<w:t>You will not taste the river’s evils,</w:t>
</w:r>
<w:r w:rsidRPr="008B5A47">
<w:rPr><w:rFonts w:ascii="Times New Roman" w:hAnsi="Times New Roman" w:cs="Times New Roman"/></w:rPr><w:cr/></w:r>
```
2. This is the xml for two lines that DO come through properly, as separate `<p>`s in the html. These use a close paragraph tag `</w:p>` for each line, instead of a `<w:cr>`:
```xml
<w:p w14:paraId="0E41693A" w14:textId="77777777" w:rsidR="00CE3D10" w:rsidRPr="008B5A47" w:rsidRDefault="00CE3D10" w:rsidP="00CE3D10">
<w:pPr><w:spacing w:line="480" w:lineRule="auto"/>
<w:rPr><w:rFonts w:ascii="Times New Roman" w:hAnsi="Times New Roman" w:cs="Times New Roman"/></w:rPr>
</w:pPr>
<w:r w:rsidRPr="008B5A47">
<w:rPr><w:rFonts w:ascii="Times New Roman" w:hAnsi="Times New Roman" w:cs="Times New Roman"/></w:rPr><w:tab/>
<w:t>nor will your boat be idle.</w:t>
</w:r>
</w:p>
<w:p w14:paraId="7E6E92D5" w14:textId="77777777" w:rsidR="00CE3D10" w:rsidRPr="008B5A47" w:rsidRDefault="00CE3D10" w:rsidP="00CE3D10">
<w:pPr><w:spacing w:line="480" w:lineRule="auto"/>
<w:rPr><w:rFonts w:ascii="Times New Roman" w:hAnsi="Times New Roman" w:cs="Times New Roman"/></w:rPr>
</w:pPr>
<w:r w:rsidRPr="008B5A47">
<w:rPr><w:rFonts w:ascii="Times New Roman" w:hAnsi="Times New Roman" w:cs="Times New Roman"/></w:rPr><w:tab/>
<w:t>No accident will affect your mast,</w:t>
</w:r>
</w:p>
```Wendell PiezWendell Piezhttps://gitlab.coko.foundation/XSweet/editoria_typescript/-/issues/14Split paragraphs on breaks2017-05-19T19:57:20ZAlex ThegSplit paragraphs on breaksXSweet captures breaks and carriage returns as either `<br class="cr"/>` or `<br class="br"/>`.
Typescript currently drops these altogether. Instead, it should split the paragraphs on the breaks. One thing to note is that the new para...XSweet captures breaks and carriage returns as either `<br class="cr"/>` or `<br class="br"/>`.
Typescript currently drops these altogether. Instead, it should split the paragraphs on the breaks. One thing to note is that the new paragraph should reuse the same styling from its parent paragraph.
See https://gitlab.coko.foundation/wendell/XSweet/issues/103 for the back storyWendell PiezWendell Piez