fix(odt): markdown styles no longer shadow common styles of styles.xml - #229
Merged
Merged
Conversation
A new automatic T{n} style could take the name of a common text style referenced from content.xml, which LibreOffice then rendered with the markdown formatting (#138).
|
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found by the new
OdtTextStylescoverage tests and checked in LibreOffice (#138). Markdown creates automatic text styles namedT{n}. The name had to be free in the part only (content.xml), but acontent.xmlspan can also reference a common (named) style ofstyles.xml. When that common style was calledT3(a user character style, or one from another generator), processing added an automaticT3(bold). LibreOffice resolves the automatic style first, so the existing redT3text turned bold and lost its character style. After a LibreOffice resave, both spans pointed to one bold style.Changes
OdtTextStyles.ReserveNamesholds names that new styles must not take.OdtTemplateEngine.Processreserves the style names ofstyles.xml'soffice:stylesbefore processing, andCreateUniqueNameskips them.OdtPlaceholderProcessor.Stylesexposes the style set to the engine (internal).styles.xmlcan still beT1whilecontent.xmlhas its ownT1.OdtDocumentBuilder.AddCommonStylesadds common styles tostyles.xml.Tests
OdtMarkdownTests.NewStyleName_DoesNotShadowACommonStyleOfStylesXml: commonT3(text style) andT4(list style). The markdown style becomesT5, and the red span keepsT3with no automatic style of that name.OdtMarkdownTests.HeaderStyles_MayReuseNamesOfContentStyles.OdtLibreOfficeRoundTripTests.MarkdownStyle_DoesNotShadowACommonStyle_InLibreOffice(LibreOffice trait, local): after a resave, the red text keepsT3and is not bold, and the markdown text is bold. This check failed before the fix (both spans wereT1bold after the resave).TriasDev.Templify.Testsnet10/9/8 (2,140 each, LibreOffice round trips included); Tools.Tests 63; Converter.Tests 95;dotnet format --verify-no-changes.Public API impact
None. Unreleased code (OpenDocument support, 1.9.0). Output changes only for templates with a common style named like the next free
T{n}.