Bug: Conflict between character and paragraph style (with workaround)

Windows 10 pro
Scrivener Beta 2.9.0.10 64bit

I created a paragraph style “centered with line break after” by adding:

Prefix:[code]

[/code], and
Suffix:[code]

[/code]

When compiled to latex, this works perfectly.

I also created a character style “small caps” by adding:

Prefix:[code]

[/code]

This also compiles perfectly to latex.

But when I apply the “centering/line after” style to a paragraph AND the “small caps” style to the whole text of the paragraph, latex crashes, and the .tex file for that paragraph looks like this:

\textsc{\begin{center}PARAGRAPH TEXT}\plainbreak*{1}\end{center}

That is, the prefix for the character style comes before the prefix for the paragraph style, AND the suffix for the character style comes before the suffix for the paragraph style.

So, rather than one nesting the other, the character style comes to an end before the paragraph it contains does.

And latex can’t handle that.

For anyone who needs a temporary workaround, if I add a space to the beginning of the paragraph, and leave that one space un-styled, the format comes out nested properly, with the character formatting inside the paragraph formatting, and latex handles it fine.

I tried adding the initial space, doing the formatting, then deleting the space, but that doesn’t work–which seems to imply that the problem comes later in the process, for what that’s worth.

Yep, I had a similar experience when writing a routine to convert Scrivener-inflected RTF to HTML. Though they’re masked in Scriv’s editor, styling tags such as <$Scr_Ps::0 > are part of the document’s visible text as shown in any other RTF editor or viewer. Thus they’re subject to character formatting. So if you convert them in place, you’re going to get something improperly nested, such as

<span (attribs)><blockquote>...</span> ... <span (attribs)>...</blockquote></span>
A bit of string manipulation is needed to migrate Scriv’s paragraph styling tags to HTML’s paragraph boundaries, and similarly for any other conversion. Improper nesting is trouble down the line, even if the code seems to render well.

I’m confident the developers are entirely familiar with this issue; it’s just a beta in progress.

Rgds - Jerome