With the new release, my attempts to paste bibliographic references (CMOS full note style) from Zotero to Scrivener are creating lines that write on top of one another (in Document Notes field or main text field). Three lines become one scribbled mess. If I paste the same data into Word, it’s fine. And if I then copy it from Word and paste it into Scrivener, it’s fine.
I’ve got Windows 7, Scrivener 1.2.1.0, and Zotero 3.0.7.
Looks like the line-spacing got severely messed up the first time you pasted. Try selecting the scrambled up text with Ctrl-A, and then use the Format Bar to set the line spacing to “1.0”. If that fixes it, then you can avoid this problem happening for now by using Edit/Paste and Match Style to paste from Zotero.
Whether the above works or not, to help us figure out what is going on, there is a utility in the Scrivener program folder called “clipboard.exe”. Run that, and then paste the Zotero text into the top half of the window. You’ll see a bunch of technical data appear in the lower half of the window. Simpy copy and paste that into a code block in the forum here, or if it contains data you’d rather not have in public, send us a support ticket with this data. If you do the latter, be sure to reference the URL of this forum thread as I might not be the one who first sees your request. Thanks!
I can confirm this, and add that the clipboard contents at the lower pane of the clipboard.exe tool displays non-english characters in a weird fashion, if it makes any difference.
Copied from Zotero:
Thanks for the help. It looks like the clipboard tool has an encoding issue, but that’s okay, the important stuff is around the weird characters. If I had to guess I’d say it is because Zotero isn’t specifying a unit for the line-height code. You can see how the text indent and padding values have an “em” after the number, that is a unit for specifying lengths based on the current font size. In HTML, numbers without a unit specification are handled as pixels, so Scrivener is setting the line-height to 1.35 pixels, which is extremely tiny. That’s why both lines are overlapping each other.
So it looks like Zotero needs to be made aware of this. I suppose we could break convention and assume a bare number is “em”—that might be what Word is doing—but they’ll probably want to fix that on their end. I’ll make sure Lee sees this thread so he can make a decision on how to handle it.
Sorry it has taken me so long to get back to this issue. I posted a notice with Zotero about the issue with line height. They responded that Scrivener has it wrong. Here’s the text I posted at Zotero and the response:
Several of us have posted on the Scrivener site that we are having problems pasting bibliographic references into the Scrivener note fields from Zotero. The lines write over each other, making several lines look like one line of scribbles. I can paste into Word, then copy and paste from there–clearly not ideal.
Scrivener has identified it as a problem with Zotero that Word has apparently worked around. Here’s the Scrivener support response:
It looks like the clipboard tool has an encoding issue, but that’s okay, the important stuff is around the weird characters. If I had to guess I’d say it is because Zotero isn’t specifying a unit for the line-height code. You can see how the text indent and padding values have an “em” after the number, that is a unit for specifying lengths based on the current font size. In HTML, numbers without a unit specification are handled as pixels, so Scrivener is setting the line-height to 1.35 pixels, which is extremely tiny. That’s why both lines are overlapping each other.
So it looks like Zotero needs to be made aware of this. I suppose we could break convention and assume a bare number is “em”—that might be what Word is doing—but they’ll probably want to fix that on their end. I’ll make sure Lee sees this thread so he can make a decision on how to handle it.
Thanks, looks like that might be the case for this type of formatting. Typically non-specified numbers are pixels, but this one has a secondary usage which uses no length specifier rendering that fall-back unusable.