But only before a special character like an apostrophe or quotation. Then everything past that is fine. I’m using a standard font both have (Courier New) and have pasted without formatting. If I remove the special character from the original text it works just fine. Or if I paste it into a Google Doc, copy that text, and then paste it into Scrivener then everything is ok.
I’m totally stumped why these characters are causing everything proceeding them to be tofu.
I have no way of testing this myself, so some things I can think to try:
Does export (to RTF or DOCX) and then import work better? That could narrow down whether it is a problem in the data or rather how that data is being conveyed.
Do you have any other Adobe products you could test in, perhaps Illustrator or Photoshop into a text box?
Of the characters not showing correctly, do they appear to be genuine encoding errors, or does the problem go away when forcing the font to something different?
Google Docs, by the way, is probably copying HTML not RTF, and if so that doesn’t say a whole lot as one would be pasted as \uc1\u8220\'93quote\uc1\u8221\'94 from Scrivener, but something along the lines of “The quoted text.” from a web page (or maybe even the UTF-8 character itself).
A better test would be any other RTF-capable editor that encodes special characters similarly to Scrivener. LibreOffice might work, because it does include an RTF copy on its clipboard, and it encodes characters in a very similar way, but it does also include HTML and it’s difficult to know which version of the clipboard InDesign will prefer—but probably RTF as that is more expressive for what it needs.
Thanks for the reply! So if I compile the manuscript to an RTF then everything is fine. The tofu only appears when I try and copy/paste directly from Scrivener into InDesign. Which I suppose is a workaround but not really what I’d want out of my workflow. I’m often only updating small sections at a time and compiling just those sections is a bit tedious.
Thanks, so then the good news is that there is nothing wrong with the data itself. Perhaps there is some confusion though; since I can’t test this myself I was wondering if you could provide some results for the various tests I suggested. It seems these were taken as overall suggestions to you to change how you work from this point on, however.
In addition to the remaining tests in the first post, I thought of another: below is a test project you can open and copy and paste from into InDesign, and see if it works. This will help determine whether there is some specific condition not yet described, such as what kind of smart quotes you use, your font settings, and so on.
So if my sample text does work normally, the best way to share what isn’t working is in the exact same format. Make a little test project from “Blank”, format some text that you’ve verified pastes incorrectly, and use File ▸ Back Up ▸ Back Up To... to create a zipped copy of it that you can upload here to the forum.
I look forward to any other results that you have time to provide.
I would also start the process of reporting this as a bug to Adobe (unless you in fact have indeed a set of variables that creates a broken clipboard, and my sample project worked fine—because ordinarily what Scrivener generates is normal and valid RTF). In order to avoid them pressing the corporate “not our problem” boilerplate response, I would supply to them merely the raw RTF from the clipboard itself, in isolation, and tell them that this data, on a clipboard as text/rtf MIME type, fails to paste properly.
If you are unsure of how to examine a clipboard and extract the raw contents from it, I can help with that.
Using LibreOffice Writer I’m able to copy from Scrivener (both my text and your line you provided), paste it into Writer, then copy that text and paste it into InDesign without a problem. However, if I copy directly from Scrivener (both my file and the one you provided) I get the tofu.
All right, thanks for checking that. So it is definitely some kind of predictable pattern to how our text engine formulates these encoded characters that is tripping it, regardless of formatting.
As another potential work-around, if InDesign has a “smarten quote” text transformer that fixes upright quotes, you could mass convert your Scrivener source with Edit ▸ Transformations ▸ Convert Quotes to Straight Quotes, and disable the automatic smart quote on typing feature in the Corrections options tab. Of course if you need those for other purposes that might not be the best option though!
But yes, otherwise I would see what Adobe has to say about it. If you don’t have a tool for doing so, the free CopyQ utility has a File ▸ Show Clipboard Content menu command that will let you browse all of the different internal clipboard variants (and is a super useful utility anyway, even if just for saving everything you copy). What you want to send them a sample of is any of the text/richtext, text/rtf or application/rtf samples.
Otherwise you could use one I copied, using the simple test project:
RTF code
{\rtf1\ansi\ansicpg1252\uc1\deff0
{\fonttbl{\f0\fnil\fcharset0\fprq2 Segoe UI;}{\f1\fnil\fcharset0\fprq2 Sitka Text;}}
{\colortbl;\red0\green0\blue0;\red255\green255\blue255;\red128\green128\blue128;}
\paperw12240\paperh15840\margl1800\margr1800\margt1440\margb1440\deftab1200\fet2\ftnbj\aenddoc
\f0\fs20\cf0\ftnbj\ftnnar\aftnnar
\sectd\sftnnar\saftnnar\sftnnar\saftnnar\pgndec\pgnrestart\pgnstarts1{\header{}}{\footer{}}
\pard\plain \tx0\tx270\tx540\tx810\tx1080\tx1350\tx1620\tx2160\tx2700\tx3240\fi270\ltrch\loch {\f1\fs24\b0\i0 This is the beginning of the \loch\af1\hich\af1\dbch\af1\uc1\u8220\'93line\u8221\'94 and this is the end of it.}}
Looks like the problem is the smart quotes. When I did the Convert Quotes to Straight Quotes it fixed the issue. Thank you so much for your help and patience trying to figure out why this was such an issue. I hope someone else in the future will find this thread helpful.