Description of problem: This problem seems to exist where there is white space inserted around the <envar> tags. For example: <para>Blah Blah Blah <envar> derp </envar> Blah Blah Blah</para> Version-Release number of selected component (if applicable): Latest PressGang CCMS Next UI How reproducible: 100% on topics that have not been edited. Steps to Reproduce: 1. Add the structure described. 2. Note how the Live Preview renders. 3. Actual results: White space in the XML is reproduced in the Live Preview. The final published version on docbuilder contains some extra whitespace between the envars that have not had the whitespace corrected. http://docbuilder.ecs.eng.bne.redhat.com/22538/remarks/#PortalContainer_Settings http://topika.ecs.eng.bne.redhat.com:8080/pressgang-ccms-ui-next/#SearchResultsAndTopicView;query;topicIds=18942 Expected results: Whitespace is ignored in the XML, and the Live Preview and published content is paginated as normal body text. Additional info:
The space that you see around the word "PortalContainerDefinitionChange" in Docbuilder is actually padding defined in the Bootstrap CSS. From memory we also have a conflict with <code> elements (they are displayed in pink). Bootstrap is the UI library used to add the menu to the right hand side. The easiest way to ensure that the Bootstrap CSS and Publican CSS don't collide is to reuse the CSS modification code that was implemented in the Portal brand, which limits certain styles to elements under certain HTML DOM parent elements.
Oops sorry forgot to update this on Friday. This was actually caused by making <envar> an inline element in the formatting rules (as it should have been), so when the formatting was applied to any existing XML it was being re-written as <envar> PortalContainerDefinitionChange </envar>. That is primarily where the extra space was coming from, as for the extra bit it's coming from the padding Matt mentioned above. Anyways I've gone through all the topics that used envar and fixed them up so that the formatting is correct (ie inline).
I see several people adding themselves to CC for this bug without adding extra reports to the blocker list. This type of bug has no single, central fix: if you are experiencing a bug of this type with hardware that does not already have a bug report filed, you *need to file a report for your hardware*, or it will never get fixed. If you've filed such a report, please add it to the list of bugs that blocks this bug, so we can track it properly. Thanks. -- Fedora Bugzappers volunteer triage team https://whizzdot.com/