adomasven today at 1:33pm
This is almost certainly a problem with pasting formatted HTML into Scrivener. 1.9.7.0 release notes say that they fixed a bug:
Removed code attempting to clean up styles from HTML on the clipboard when pasting into Scrivener, as doing so could lose parts of the original text.
I suspect this may have introduced the problem you are seeing. You should try posting on their forums regarding this.
Hope someone can look into this as it’s making my use of Scrivener far more difficult
Simplest approach is to think of this not as a bug but as a text block that is formatted in a way that doesn’t match your default prefs. Happens all the time on HTML drags and pastes. You can run Documents > Convert > Formatting to Default Text Style to get the block lined up.
Here’s an old discussion about why pasting from the HTML clipboard, which is what we’re doing from Zotero, will often yield an odd initial display in Scriv’s editor.
A solution recommended in that thread works here also: Select All in Scriv’s editor, then cut and paste again. (Ctrl-A Ctrl-X Ctrl-V).
My user take is that Scrivener tries to pick up formatting cues from the HTML clipboard as it converts the block into RTF for editing. But it isn’t going to recognize all elements among the infinite varieties and dialects of HTML. One thing it’s fussy about is the unit of measure in style parameters. If you happen to paste directly from OneNote 2016 into Scrivener, for example, your block won’t reflect OneNote’s indents, which govern OneNote’s expand/collapse outlining facility. That’s because OneNote’s HTML clipboard defines its margins in inches (in), whereas Scriv’s engine looks for em or px or % values. (If you paste from OneNote to AbleWord, and thence into Scrivener, you’ll retain the indents usefully, as margin settings.)
Similar situation here, from Zotero. The bibliography paste specifies a line height of 1.35 but provides no unit. That’s valid HTML, but uncommon; we’d typically use 135% which Scriv would have accepted. I’d love it if Scrivener could recognize all valid units of measure on an HTML clipboard, but realize that handling odd HTML clips to precision is never going to be one of Scrivener’s core competencies.
Update: I previously wrote that the HTML editor BlueGriffon exhibits the same behavior on a biblio paste from Zotero, but I’m not getting that now. Dragging the block into BlueGriffon shows that Zotero identifies the elements in the block with “class” tags. So it’s up to the user of an HTML destination program to apply formatting via CSS to the applicable classes. As a Rich Text program, Scriv won’t recognize these classes, so we just apply a desired style via selection.