XSweet issueshttps://gitlab.coko.foundation/groups/XSweet/-/issues2022-04-05T05:50:36Zhttps://gitlab.coko.foundation/XSweet/editoria_typescript/-/issues/49Retain image file names on import2022-04-05T05:50:36ZRyan Dix-PeekRetain image file names on import**Description;** the purpose of this task is to retain image file names for images imported into Kotahi via MS Word file. MS Word files store the image names, these names need to be retained for all converted images in the object store.**Description;** the purpose of this task is to retain image file names for images imported into Kotahi via MS Word file. MS Word files store the image names, these names need to be retained for all converted images in the object store.BharathydasanBharathydasanhttps://gitlab.coko.foundation/XSweet/HTMLevator/-/issues/21Reference lists imported with extra redundant numbering / Literal numbers not...2021-12-23T15:38:23ZBharathydasanReference lists imported with extra redundant numbering / Literal numbers not removed after list detection.
While detecting and converting the normal paragraphs to a list, literal list numbers are not removed from the text. This should be fixed in the scrub function (`scrub-literal-numbering-lists.xsl`), This issue is reported in [kotahi-711]...
While detecting and converting the normal paragraphs to a list, literal list numbers are not removed from the text. This should be fixed in the scrub function (`scrub-literal-numbering-lists.xsl`), This issue is reported in [kotahi-711](https://gitlab.coko.foundation/kotahi/kotahi/-/issues/711)
![image](/uploads/73eb808fae75aa8f84bca6bfab498a81/image.png)
@BenWh @ryandixpeekBharathydasanBharathydasanhttps://gitlab.coko.foundation/XSweet/editoria_typescript/-/issues/48Split docx files at Heading 12022-05-12T11:46:58ZRyan Dix-PeekSplit docx files at Heading 1**Description;** the purpose of this task is to support the splitting of a single docx file imported in Editoria. Editoria supports importing a single docx file per chapter. This solution will allow a user to select an option to split a ...**Description;** the purpose of this task is to support the splitting of a single docx file imported in Editoria. Editoria supports importing a single docx file per chapter. This solution will allow a user to select an option to split a single docx file into multiple chapters.
![Screenshot_2021-11-17_at_14.31.31](/uploads/72f5f3a3d887b57b380155d1bde5aaaa/Screenshot_2021-11-17_at_14.31.31.png)
The proposed solution; to introduce an XSweet pipeline that ~~would parse out files at an `h1` level~~ [see below comment] using XSLTs. A user interface to handle the selection of a 1) multiple or 2) single docx import. If a single docx is selected, the uploaded file will be split into chapters using ~~a `Heading 1` as a reference tag~~ (see comment below) to action the chapter split.
Reference; Editoria docx splitter issue; https://gitlab.coko.foundation/editoria/editoria/-/issues/481
**Acceptance criteria;**
- a new Xsweet pipeline will convert a single file into multiple chapters ~~split by `h1`~~ (see below comment).
- the pipeline that handles the conversation on multiple `h1` into `h2` and `h4` should be disabled for a single docx import; see #46Suki VenkatSuki Venkathttps://gitlab.coko.foundation/XSweet/editoria_typescript/-/issues/47Tables not being retained upon import2021-10-26T10:06:29ZRyan Dix-PeekTables not being retained upon import**Issue description;** table structure is not retained, only text pulls through when importing Docx files into Kotahi. (XSweet Core pipeline](https://xsweet.org/documentation/xsweet-core/) should handle table conversion, but this does no...**Issue description;** table structure is not retained, only text pulls through when importing Docx files into Kotahi. (XSweet Core pipeline](https://xsweet.org/documentation/xsweet-core/) should handle table conversion, but this does not appear to be happening. 'Import tables into Wax 2' was implemented here; #41 but the issue persists.
See Kotahi issue for [further context](https://gitlab.coko.foundation/kotahi/kotahi/-/issues/613)https://gitlab.coko.foundation/XSweet/editoria_typescript/-/issues/46Multiple H12021-11-17T12:32:08ZAlexandros GeorgantasMultiple H1It seems that XSweet conversion results in multiple `<h1>` tags. Headings found inside of a `docx` should be treated differently as the `HTML` equivalent should only have a single `<h1>` tag in order to be semantically correct as a stand...It seems that XSweet conversion results in multiple `<h1>` tags. Headings found inside of a `docx` should be treated differently as the `HTML` equivalent should only have a single `<h1>` tag in order to be semantically correct as a standalone chapter. Also, that `<h1>` should be first element in the doc as authors expect this text to be the title of the chapter.
All the rest of the headings inside a `docx` should be converted into `h2` to `h4` accordingly.Wendell PiezWendell Piezhttps://gitlab.coko.foundation/XSweet/editoria_typescript/-/issues/45Math2022-03-09T10:47:36ZChristosMathXSweet captures equations created with Word’s built-in equation tool (Office MathML format) and passes them through to the HTML as standard MathML. (docs [here](https://xsweet.org/documentation/xsweet-core/#math))
The Wax editor should ...XSweet captures equations created with Word’s built-in equation tool (Office MathML format) and passes them through to the HTML as standard MathML. (docs [here](https://xsweet.org/documentation/xsweet-core/#math))
The Wax editor should be passed LaTeX so that users can easily edit the math after the Word docs are imported (see library [mml2tex](https://github.com/transpect/mml2tex)). This will be rendered with MathJax (https://www.mathjax.org/)BharathydasanBharathydasanhttps://gitlab.coko.foundation/XSweet/editoria_typescript/-/issues/44Notes format for Wax 22022-03-09T11:14:20ZAlex ThegNotes format for Wax 2# Target format for Wax 2
Unlike Wax 1, which has inline note callouts that reference the contents of the notes at the end of the file, Wax 2 keeps the contents of the notes inline, where they're referenced.
```html
<p class="paragraph">...# Target format for Wax 2
Unlike Wax 1, which has inline note callouts that reference the contents of the notes at the end of the file, Wax 2 keeps the contents of the notes inline, where they're referenced.
```html
<p class="paragraph">Quisque posuere fermentum.<footnote id="de87b2a3-6186-440e-9249-fb07ce9ff344" data-group="notes">note 1 with some content </footnote> Duis ut volutpat nunc.<footnote id="b8cc2013-ba52-48cb-b42c-dbe407de0c69" data-group="notes">note 2</footnote> Nunc elementum id nulla nec tempor. Sed fringilla lacinia diam non tempus.</p>
```
All notes - both endnotes and footnotes - should be turned into `<footnote>` tags. The `<footnote>`s should have two attributes:
1. A unique `id`
2. A `data-group`, which should have a value of "notes"
This transformation needs to happen in the Editoria Typescript steps.
# How it works now
The starting format for notes is the final step of the XSweet chain: the HTML-like format. This will not change. At the end of that, notes take this format:
```html
<div class="docx-body">
<p>Simple notes test. Here’s a footnote.<span class="FootnoteReference"><a class="footnoteReference" href="#fn1">a</a></span> And another footnote.<span class="FootnoteReference"><a class="footnoteReference" href="#fn2">b</a></span> And here’s an
endnote.<span class="EndnoteReference"><a class="endnoteReference" href="#en1">1</a></span> And another endnote.<span class="EndnoteReference"><a class="endnoteReference" href="#en2">2</a></span></p>
</div>
<div class="docx-endnotes">
<div class="docx-endnote" id="en1">
<p class="EndnoteText" style="font-size: 10pt"><span class="EndnoteReference"><span class="endnoteRef">1</span></span> First endnote!</p>
</div>
<div class="docx-endnote" id="en2">
<p class="EndnoteText" style="font-size: 10pt"><span class="EndnoteReference"><span class="endnoteRef">2</span></span> Second endnote!</p>
</div>
</div>
<div class="docx-footnotes">
<div class="docx-footnote" id="fn1">
<p class="FootnoteText" style="font-size: 10pt"><span class="FootnoteReference"><span class="footnoteRef">a</span></span> The first footnote!</p>
</div>
<div class="docx-footnote" id="fn2">
<p class="FootnoteText" style="font-size: 10pt"><span class="FootnoteReference"><span class="footnoteRef">b</span></span> Second footnote</p>
</div>
</div>
```
At the end of the Editoria Typescript process, notes come out looking like this:
```html
<container id="main">
<p>Simple notes test. Here’s a footnote.<note data-id="fn1"/> And another footnote.<note data-id="fn2"/> And here’s an endnote.<note data-id="en1"/> And another endnote.<note data-id="en2"/></p>
</container>
<div id="notes">
<note-container id="container-en1">
<p> First endnote!</p>
</note-container>
<note-container id="container-en2">
<p> Second endnote!</p>
</note-container>
<note-container id="container-fn1">
<p> The first footnote!</p>
</note-container>
<note-container id="container-fn2">
<p> Second footnote</p>
</note-container>
</div>
```
The steps that will need an update are `editoria-basic.xsl` and `editoria-reduce.xsl`.
Currently, the `editoria-basic.xsl` step transforms the inline note callouts:
```html
Before:
<span class="FootnoteReference"><a class="footnoteReference" href="#fn1">a</a></span>
After:
<note data-id="fn1"><!-- implicit --></note>
```
It also transforms the note content itself:
1. turning the `<div class="docx-endnote">` into a `<note-container>`
2. prepending "`container-`" to the `id`
3. dropping out the `<span class="EndnoteReference">` and its contents
```html
Before:
<div class="docx-endnote" id="en1">
<p class="EndnoteText" style="font-size: 10pt">
<span class="EndnoteReference">
<span class="endnoteRef">1</span>
</span>
First endnote!
</p>
</div>
After:
<note-container id="container-en1">
<p class="EndnoteText" style="font-size: 10pt">
First endnote!
</p>
</note-container>
```
The `editoria-reduce.xsl` step leave the note callout as-is, but strips extraneous attributes from the note's `<p>` (`class`, `style`, etc.):
```html
<note-container id="container-en1">
<p> First endnote!</p>
</note-container>
```
# Implementation notes
The `editoria-basic.xsl` step needs to be updated to:
* Find the corresponding note content for every callout, by matching the callout's `href` value to the `id` of the endnote/footnote
* Copy that note content inline, into a `<footnote>` tag, generating a UUID (see https://gitlab.coko.foundation/XSweet/editoria_typescript/issues/43#note_52278) and setting it as the `<footnote>`'s `id` attribute. Also, add a `data-group="notes"` attribute to it.
* Cleanup the old callouts and notes
* For the callouts, the new `<footnote>` tags should completely replace the `<span class="FootnoteReference">` and `<span class="EndnoteReference">` and their contents.
* The notes section at the end of the docx should be dropped completely. The `editoria-basic.xsl` step takes the `<div class="docx-endnotes">` and `<div class="docx-footnotes">` and collapses them both into one `<div id="notes">`. This should be updated to simply drop the `<div class="docx-endnotes">` and `<div class="docx-footnotes">` tags and their contents.
The `editoria-reduce.xsl` step will likely need some minor tweaks to update specific references to outdated notes tags.BharathydasanBharathydasanhttps://gitlab.coko.foundation/XSweet/editoria_typescript/-/issues/43Translate HTML-like track changes into Wax 2 target format2023-02-03T09:52:17ZAlex ThegTranslate HTML-like track changes into Wax 2 target formathttps://gitlab.coko.foundation/XSweet/XSweet/issues/172 defines the target format for TCs in Wax.
TCs currently make it through the `editoria-basic.xsl` step, but are dropped by the `editoria-reduce.xsl` step. I feel we should do the co...https://gitlab.coko.foundation/XSweet/XSweet/issues/172 defines the target format for TCs in Wax.
TCs currently make it through the `editoria-basic.xsl` step, but are dropped by the `editoria-reduce.xsl` step. I feel we should do the conversion of TCs for Wax 2 format as part of the `editoria-basic.xsl` step, though, before the `editoria-reduce.xsl` step, then make sure it's passed through the `editoria-reduce.xsl` step.
Here are the tag translations:
* `<ins>` maps to `<span class="insertion">`
* `<del>` maps to `<span class="deletion">`
* `<track-change>` maps to `<span class="format-change">`
These two attributes' values should be passed through unchanged and set on all TCs in Wax:
* `id` to `data-id`. Example values: `"tc-1", "tc-2"`.
* `data-author` to `data-username`. E.g. `"Alex Theg"`
Additionally, these tags need to have their values not just passed through but transformed:
* `datetime` needs to be converted into the datetime format Wax uses, then set as `data-date` on every TC
* `data-addedtype` and `data-oldtype`, when present, need to be converted to Wax's target format and set as `data-after` and `data-before`, respectively. Not only does the format of the values need to be modified, but we probably need to decide what formatting is worth saving. That may be a Amnet-specific step. For example: you may want to save underline, bolding, italics, and ignore everything else.
@christos I have questions about these three attributes and how to handle them:
* `data-user`: could we also pass the `data-author` value from XSweet into this attribute and have it serve as a user unique identifier, in addition to setting it as into `data-username`?
* `data-group`: what are the possible values? This is either `"main"` or what? Can Wax 2 assign this or would it be XSweet?
* `datetime`: @christos what format does Wax use for date time? Does MS Word's timestamp need to be converted? E.g. `2020-02-05T19:02:00Z`BharathydasanBharathydasanhttps://gitlab.coko.foundation/XSweet/editoria_typescript/-/issues/42How to run Wax 22020-11-12T02:02:44ZAlex ThegHow to run Wax 2This worked for me on macOS Mojave:
1. `git clone https://gitlab.coko.foundation/wax/wax-prosemirror`
2. `cd wax-prosemirror`
3. `yarn install` with node >= 12
4. `yarn editoria`
The last step starts a dev server and `localhost:3000` r...This worked for me on macOS Mojave:
1. `git clone https://gitlab.coko.foundation/wax/wax-prosemirror`
2. `cd wax-prosemirror`
3. `yarn install` with node >= 12
4. `yarn editoria`
The last step starts a dev server and `localhost:3000` running Wax 2
The demo file for the editor's content comes from `wax-prosemirror/editors/editoria/src/demo.js`. Changes to its content hot reload into the editor.https://gitlab.coko.foundation/XSweet/editoria_typescript/-/issues/41Import tables for Wax 22022-03-09T11:21:11ZAlex ThegImport tables for Wax 2Wax 2 supports tables. The differences between what the XSweet pipeline currently produces and the format Wax 2 uses is not big:
* XSweet's `<td>`s have a `style` attribute; Wax does not
* XSweet's `<p>`s do not have a `class` but Wax's ...Wax 2 supports tables. The differences between what the XSweet pipeline currently produces and the format Wax 2 uses is not big:
* XSweet's `<td>`s have a `style` attribute; Wax does not
* XSweet's `<p>`s do not have a `class` but Wax's do
* XSweet doesn't wrap the table in a `<tbody>` tag; Wax does
XSweet output:
```html
<table>
<tr>
<td style="border-bottom-style: solid; border-bottom-width: 0.5pt; border-left-style: solid; border-left-width: 0.5pt; border-right-style: solid; border-right-width: 0.5pt; border-top-style: solid; border-top-width: 0.5pt; vertical-align: top">
<p>One</p>
</td>
<td style="border-bottom-style: solid; border-bottom-width: 0.5pt; border-left-style: solid; border-left-width: 0.5pt; border-right-style: solid; border-right-width: 0.5pt; border-top-style: solid; border-top-width: 0.5pt; vertical-align: top">
<p>Two</p>
</td>
<td style="border-bottom-style: solid; border-bottom-width: 0.5pt; border-left-style: solid; border-left-width: 0.5pt; border-right-style: solid; border-right-width: 0.5pt; border-top-style: solid; border-top-width: 0.5pt; vertical-align: top">
<p>Three</p>
</td>
</tr>
<tr>
<td style="border-bottom-style: solid; border-bottom-width: 0.5pt; border-left-style: solid; border-left-width: 0.5pt; border-right-style: solid; border-right-width: 0.5pt; border-top-style: solid; border-top-width: 0.5pt; vertical-align: top">
<p>Four</p>
</td>
<td style="border-bottom-style: solid; border-bottom-width: 0.5pt; border-left-style: solid; border-left-width: 0.5pt; border-right-style: solid; border-right-width: 0.5pt; border-top-style: solid; border-top-width: 0.5pt; vertical-align: top">
<p>Five</p>
</td>
<td style="border-bottom-style: solid; border-bottom-width: 0.5pt; border-left-style: solid; border-left-width: 0.5pt; border-right-style: solid; border-right-width: 0.5pt; border-top-style: solid; border-top-width: 0.5pt; vertical-align: top">
<p>Six</p>
</td>
</tr>
<tr>
<td style="border-bottom-style: solid; border-bottom-width: 0.5pt; border-left-style: solid; border-left-width: 0.5pt; border-right-style: solid; border-right-width: 0.5pt; border-top-style: solid; border-top-width: 0.5pt; vertical-align: top">
<p>Seven</p>
</td>
<td style="border-bottom-style: solid; border-bottom-width: 0.5pt; border-left-style: solid; border-left-width: 0.5pt; border-right-style: solid; border-right-width: 0.5pt; border-top-style: solid; border-top-width: 0.5pt; vertical-align: top">
<p>Eight</p>
</td>
<td style="border-bottom-style: solid; border-bottom-width: 0.5pt; border-left-style: solid; border-left-width: 0.5pt; border-right-style: solid; border-right-width: 0.5pt; border-top-style: solid; border-top-width: 0.5pt; vertical-align: top">
<p>Nine</p>
</td>
</tr>
</table>
```
Wax 2 table:
```xml
<table>
<tbody>
<tr>
<td>
<p class="paragraph">one</p>
</td>
<td>
<p class="paragraph">two</p>
</td>
<td>
<p class="paragraph">three</p>
</td>
</tr>
<tr>
<td>
<p class="paragraph">four</p>
</td>
<td>
<p class="paragraph">five</p>
</td>
<td>
<p class="paragraph">six</p>
</td>
</tr>
<tr>
<td>
<p class="paragraph">seven</p>
</td>
<td>
<p class="paragraph">eight</p>
</td>
<td>
<p class="paragraph">ten</p>
</td>
</tr>
</tbody>
</table>
```
When an XSweet table like the first example is passed in, Wax appears to gloss over the differences seamlessly, adding `class` attributes and a `body` tag, and dropping the `style` information entirely. That is great news.
To complete table import into Wax 2, the only change need (that I can identify) is to pass tables through the final `editoria-reduce.xsl` step. Currently, that drops all table tags, leaving cell contents unchanged.BharathydasanBharathydasanhttps://gitlab.coko.foundation/XSweet/XSweet/-/issues/172Track changes target format for Wax 22022-03-01T08:41:15ZAlex ThegTrack changes target format for Wax 2@christos is working on the next version of the Wax editor for Editoria, and it will include some changes to the way certain elements are coded. We had laid out the current format of TCs in #162; going forward, this issue will serve as t...@christos is working on the next version of the Wax editor for Editoria, and it will include some changes to the way certain elements are coded. We had laid out the current format of TCs in #162; going forward, this issue will serve as the reference for the expected target format.
Rather than using a `<track-change>` element, track changes will be a `<span>` tag with a class describing the specific type of change:
* `<span class="insertion">`
* `<span class="deletion">`
* `<span class="format-change">`
Track change elements will have the following attributes:
* `data-id`: A unique identifier string. There is no specific requirement for the format, just that something's passed in.
* `data-user`: A unique identifier string for the user. There is no specific format required, but something does need to be passed in. Down the line, this is going to change to `data-userid`.
* `data-username`: When changes are made within the editor, this will be the user's username. We won't have access to usernames since we're coming from Word, so pass in the author name as-is.
* `data-date`: the date of the change, in the format ____
* `data-group`: what part of the content the change happened in. Either "main" or else "____"
For formatting track changes, these two additional attributes will apply:
* `data-before`: The format before the change. As a starting point, there is no need to pass in anything here and it's fine to omit the tag altogether.
* `data-after`: The formatting change that has been made. More important than the `data-before` attribute.
If `data-id` and `data-group` are both omitted, then the right-hand side track change pane won't show the change (see attached screenshot), and the change will only appear inline. This would be fine as a starting point.
![side_callout](/uploads/8007c007d801d716bd99355f86cc70d9/side_callout.png)
Example:
```html
<p class="paragraph">
<strong>
<span class="format-change"
data-id="9b863ae5-a1ba-4714-93e9-3674b3ef3edf"
data-user="1234"
data-username="demo"
data-date="5316364"
data-before="[]"
data-after="["strong"]"
data-group="main">
this
</span>
</strong>
is a paragraph.
</p>
```
@christos, here are some questions I have:
1. Is this correct, that TCs will be a `<span>` rather than a `<p>` tag?
1. What format does the date need to be in?
1. What are the possible values for `data-group`? `main` and what? Do we need to include this in what we pass in?
1. Can I get a check about when the side callout won't be available? Are the two relevant fields `data-id` and `data-group`? Do both need to be missing before the side callout won't show up, or just one? If I'm wrong, can you correct what I wrote above by the screenshot?
1. We're going to have the `data-before` data. Is there any reason not to include it if we already have it?https://gitlab.coko.foundation/XSweet/XSweet/-/issues/171Express the most recently applied formatting inline on formatting track changes2020-10-29T14:57:25ZAlex ThegExpress the most recently applied formatting inline on formatting track changesThe formatting track changes @bharathydasan has been working on with #164 express the styling information in CSS style syntax, rather than using inline tags. At some point in the pipeline, the styling from the CSS should be expressed inl...The formatting track changes @bharathydasan has been working on with #164 express the styling information in CSS style syntax, rather than using inline tags. At some point in the pipeline, the styling from the CSS should be expressed inline, for two reasons.
First and most importantly, it's what Wax expects to see, per the target format provided by @christos:
```html
<track-change-format status="add-formating"
oldtype="[]"
addedtype="[{" username ":"demo ","type ":"strong "}]"
user-id="1"
username="demo">
<strong>test</strong>
</track-change-format>
```
Additionally, by duplicating the CSS styling from formatting track changes as inline tags, HTML in the browser would display the inline formatting even if it ignored the track change tags altogether.
That it's what Wax expects is the more important point. If we set aside the second point, this could also plausibly live in the Editoria Typescript portion of the pipeline, but I think this really belongs as one of the final steps targeting HTML (maybe before the `final-rinse.xsl` step?).
@bharathydasan and @wendell have started a discussion on #164 (specifically [here](https://gitlab.coko.foundation/XSweet/XSweet/issues/164#note_45058)), which we can carry forward on this issue.
I'd propose that we all agree on the target format explicitly before building anything. My suggestion would be to use exactly the target format for Wax, perhpas differing only on the exact tags used if there's a good reason (e.g. we might use `<b>` for the HTML and `<strong>` for Wax).https://gitlab.coko.foundation/XSweet/XSweet/-/issues/170Track changes not supported in list format conversion2022-03-01T08:32:01ZBharathydasanTrack changes not supported in list format conversionHi @atheg and @wendell,
I tried to do some test in list style and understood that the conversion process completely removes the track changes and even the inline formattings in the list element, I believe this should be addressed first...Hi @atheg and @wendell,
I tried to do some test in list style and understood that the conversion process completely removes the track changes and even the inline formattings in the list element, I believe this should be addressed first before adding anything new to list styles.
1. List (numbering)formats are not captured:
-- I looked some of the existing issues and understood that this was already raised in #148 and #149 and open.
2. Inline format tags are removed in list:
-- Inline formats are completely lost or removed in the conversion pipeline at the '8DETECTLISTS' stage.
3. Track change tags are removed in list:
-- Similarly, track changes (ins/del) are also removed in the conversion pipeline at the '8DETECTLISTS' stage.Alex ThegAlex Theghttps://gitlab.coko.foundation/XSweet/XSweet/-/issues/169Preserve tab spaces2022-05-09T12:02:31ZBharathydasanPreserve tab spacesThe tab characters are actually converted to `<span class="tab"> <!-- tab --></span>` element in initial conversion, but it is removed in the conversion pipeline, this happens at the `15EDITORIABASIC.xhtml` where the span elements are...The tab characters are actually converted to `<span class="tab"> <!-- tab --></span>` element in initial conversion, but it is removed in the conversion pipeline, this happens at the `15EDITORIABASIC.xhtml` where the span elements are removed. well, the track-changes for tab character are preserved properly with `<ins>` and `<del>` which was added earlier.
Only the elements `<pre>` and `<code>` in HTML can render the tab spaces. Here my question is how these tab spaces are handled in `Editoria` or `Wax`.https://gitlab.coko.foundation/XSweet/XSweet/-/issues/168test2020-05-09T16:10:56ZGhost Usertesttesttesthttps://gitlab.coko.foundation/XSweet/XSweet/-/issues/167Support options for different handling of track changes2020-09-20T20:46:25ZAlex ThegSupport options for different handling of track changesNow that the basic functionality to extract character insertion/deletion track changes into HTML is part of the initial extraction sheet, it's easy to comment that bit out if that's not desired.
We should consider how to give options to...Now that the basic functionality to extract character insertion/deletion track changes into HTML is part of the initial extraction sheet, it's easy to comment that bit out if that's not desired.
We should consider how to give options to XSweet users who may want to handle track changes differently: accept or reject them all away, drop them at a later stage, etc.
* This could possibly be managed with runtime flags
* We could also have a standalone sheet in the pipeline that a user could tweak to specify how to handle track changes: accept them all, reject them all, etc. This could work by passing in a runtime option, commenting/uncommenting the desired sections, etc.https://gitlab.coko.foundation/XSweet/XSweet/-/issues/166Track changes for tables?2020-10-29T08:27:20ZAlex ThegTrack changes for tables?Tracking changes to tables came up in this week's discussion with @bharathydasan and @wendell. There may not ultimately be a need for this, but if there is, it can come after the initial TC implementation.
This could also be potentially...Tracking changes to tables came up in this week's discussion with @bharathydasan and @wendell. There may not ultimately be a need for this, but if there is, it can come after the initial TC implementation.
This could also be potentially very complex. @wendell suggested that as a way to limit the scope/complexity of a solution, a simple whole-table before/after comparison could be surfaced, rather than a granular representation of the specific changes.https://gitlab.coko.foundation/XSweet/XSweet/-/issues/165Paragraph-level formatting track changes2020-06-17T02:26:16ZAlex ThegParagraph-level formatting track changesThis is a placeholder ticket for handling paragraph-level track changes. See also #162 and #164 for additional context.
Paragraph-level formatting changes will be ignored for a first implementation of track changes. However, they may me...This is a placeholder ticket for handling paragraph-level track changes. See also #162 and #164 for additional context.
Paragraph-level formatting changes will be ignored for a first implementation of track changes. However, they may merit revisiting at some point. From @bharathydasan:
> there are few things stored in paragraph properties such as center, left, and right alignments that need attentionhttps://gitlab.coko.foundation/XSweet/XSweet/-/issues/164Track changes to inline formatting2020-09-20T21:13:16ZAlex ThegTrack changes to inline formatting@bharathydasan, would you mind outlining your approach to capturing track changes to formatting in this ticket? From the `track-changes` branch `README.md`:
> Formatting Changes: Formatting changes are recorded in `w:rPrChange`, all the...@bharathydasan, would you mind outlining your approach to capturing track changes to formatting in this ticket? From the `track-changes` branch `README.md`:
> Formatting Changes: Formatting changes are recorded in `w:rPrChange`, all the inline and other formattings should be retained during the transformation. Development for fomatting changes will start once the development on Character changes is completed.
Specifically, it would be great to have a list of the formatting changes you're targeting to capture initially, so we can have a reference and then discuss what is or isn't included/ignored/transformed etc. in the first implementation. Thanks!BharathydasanBharathydasanhttps://gitlab.coko.foundation/XSweet/XSweet_runner_scripts/-/issues/3Next steps for track changes with Amnet2020-03-20T01:28:50ZAlex ThegNext steps for track changes with AmnetNext steps for moving forward with preserving track changes:
1. @Bharathydasan to update runner scripts so they work in a Windows 10 environment, to get a comfortable dev environment set up. These 2 scripts in particular need updating:
...Next steps for moving forward with preserving track changes:
1. @Bharathydasan to update runner scripts so they work in a Windows 10 environment, to get a comfortable dev environment set up. These 2 scripts in particular need updating:
* https://gitlab.coko.foundation/XSweet/XSweet_runner_scripts/blob/master/xsweet_runner.rb
* https://gitlab.coko.foundation/XSweet/XSweet_runner_scripts/blob/master/execute_chain.sh
2. Once that's done, Amnet will consider a strategy for passing through track changes. Any thoughts and discussion can take place on this issue: (https://gitlab.coko.foundation/XSweet/XSweet/issues/162)
3. Before any track changes development happens, Amnet, @wendell @atheg and @adam will meet next week to discuss the approach and talk through the overall strategy and architecture for capturing track changes.