I noticed that the way styles are handled depending on the format is inconsistent. When a file is created in TextMaker and saved as ODT, several of the default styles, like normal, body text and footnote text are handled as custom/user created styles, not as the document-default ones. So if this file is then edited in LibreOffice, styling inconsistencies show intermediately, most notably with footnotes.
Steps to reproduce:
1. Create a document in TM. Add text and apply any default style provided by TM. Do not create custom styles. Add footnotes so you can spot quickly the problem.
2. Save as ODT.
3. Open in LibreOffice and add another footnote to see the difference on styling.
4. On the styling sidebar provided LibreOffice, select the custom filter. There you will find every single style that was applied by TextMaker.
This situation makes it incredibly annoying when exchanging files with other people that use LibreOffice, since the default formats never match, due to TextMaker inability to properly translate default styles to odt's default naming conversions.
I am certain this issue affects to any kind of element that is inserted into the document and that depend of default styles.
Take a look at the attached demo file.
When the file is reopen in TextMaker, TM treats LibreOffice styles as custom and modified them to match its own (the original ones), basically creating duplicates leaving a big mess since how some footnotes have "footnote text" applied, while the others have "footnote" and some paragraphs have "normal" while other "standard" or "body text".
Inconsistent styles between formats
Inconsistent styles between formats
- Attachments
-
- footnote demo.odt
- (9.65 KiB) Downloaded 915 times
Re: Inconsistent styles between formats
Most likely this inconsistency is related to two of my previous reports: this one about comments losing formatting in ODT and this one ODT syntax is invalid. . Something to keep in mind, just as well the fact both issues remain unresolved after a few months.
Edit: After further review and testing I can say that the syntax issues I reported months ago has nothing to do with styles, but are related to tracking changes and an incorrect ODT heading. And while this issues persist and remain unresolved since the beginning of the year (and should be addressed) are not the culprit here. I do not now, and I cant not tell if this styles issue is related to TextMaker's custom styling extension, with is one of the things the validator warns about.
While I understand that ODF support is a bit of a after thought, and not much of a priority, I think is quite important to have, at least a reliable implementation even if it lacks support for more new/advanced odf features as those introduced in version 1.4. So please don't ignore this post nor the previous ones and please find solutions for it.
Edit: After further review and testing I can say that the syntax issues I reported months ago has nothing to do with styles, but are related to tracking changes and an incorrect ODT heading. And while this issues persist and remain unresolved since the beginning of the year (and should be addressed) are not the culprit here. I do not now, and I cant not tell if this styles issue is related to TextMaker's custom styling extension, with is one of the things the validator warns about.
While I understand that ODF support is a bit of a after thought, and not much of a priority, I think is quite important to have, at least a reliable implementation even if it lacks support for more new/advanced odf features as those introduced in version 1.4. So please don't ignore this post nor the previous ones and please find solutions for it.
Re: Inconsistent styles between formats
The attached screen recording shows that the same behavior occurs in LibreOffice as well, so this does not appear to be specific to SoftMaker Office.
Please discuss unrelated issues in separate topics so that each one can be tracked and addressed clearly.
Please discuss unrelated issues in separate topics so that each one can be tracked and addressed clearly.
Re: Inconsistent styles between formats
Seems some clarification is in order:
1. Create a odt document in TextMaker and insert a footnote. (Notice that TextMaker will use the "footnote text" style).
2. Replicate the same document on LibreOffice. (Notice how Write uses "footnote" style instead)
3. Open in LibreOffice the document created in TextMaker and insert a new footnote (Notice how now you have "footnote text" and "footnote" as styling for footnotes, where "footnote" is used on LibreOffice and "Footnote text" on TextMaker.)
4. Replicate the exercise on TextMaker by editing the LibreOffice generated file. (Once again, notice how you will also get two different styling for footnotes).
This same experiment can be performed with other styles as "First Line Indent" and "Body Text First Indent", Headings, and other styles. You end up with duplicates, where the edits made in LibreOffice uses a set of styles and the edits made on TextMaker uses another set of styles. That is what illustrates the file I provided: Parts of the file uses styles from one application, and the other uses parts from the other, witch leaves a mess and becomes a headache when a new style is introduced on the document that is different between applications. Sure, a quick fix is to use the option to force «Style B» to match/copy «Style A».
What this points to is a mismatch as how styles are named/treated. And if you look closely at the odt file created by TextMaker, you will see that the styling structure ends up being something like: Normal > Standard > Everything else. In reality Normal = Standard/Default Paragraph Style, just as Footnote = Footnote Text. And if you use the styles filter you will notice any style created by LibreOffice will be treated as a custom style, like «Standard», while those created by TextMaker, like «Normal» will be treated as custom by LibreOffice.
Then, by some reason First Indent gets a bizarre structure too on TextMaker: Normal > Text body > First Line Indent. This is particular since none TextMaker or LibreOffice recognize this style as a document default...
1. Create a odt document in TextMaker and insert a footnote. (Notice that TextMaker will use the "footnote text" style).
2. Replicate the same document on LibreOffice. (Notice how Write uses "footnote" style instead)
3. Open in LibreOffice the document created in TextMaker and insert a new footnote (Notice how now you have "footnote text" and "footnote" as styling for footnotes, where "footnote" is used on LibreOffice and "Footnote text" on TextMaker.)
4. Replicate the exercise on TextMaker by editing the LibreOffice generated file. (Once again, notice how you will also get two different styling for footnotes).
This same experiment can be performed with other styles as "First Line Indent" and "Body Text First Indent", Headings, and other styles. You end up with duplicates, where the edits made in LibreOffice uses a set of styles and the edits made on TextMaker uses another set of styles. That is what illustrates the file I provided: Parts of the file uses styles from one application, and the other uses parts from the other, witch leaves a mess and becomes a headache when a new style is introduced on the document that is different between applications. Sure, a quick fix is to use the option to force «Style B» to match/copy «Style A».
What this points to is a mismatch as how styles are named/treated. And if you look closely at the odt file created by TextMaker, you will see that the styling structure ends up being something like: Normal > Standard > Everything else. In reality Normal = Standard/Default Paragraph Style, just as Footnote = Footnote Text. And if you use the styles filter you will notice any style created by LibreOffice will be treated as a custom style, like «Standard», while those created by TextMaker, like «Normal» will be treated as custom by LibreOffice.
Then, by some reason First Indent gets a bizarre structure too on TextMaker: Normal > Text body > First Line Indent. This is particular since none TextMaker or LibreOffice recognize this style as a document default...
