They are different. Nisus is a fully-fledged word processor, like for example MS Word or the word processor of the LibreOffice suite.
I can imagine, yes. As said, they are different. Nisus is very good for creating self-contained documents for print or PDF, Scrivener is more like a project/resources manager with integrated typesetting capabilities, no? (I’m not using Scrivener a lot, I bought it out of curiosity.)
Not much, I would say. It has a very Mac-like GUI, even a bit old fashioned, if you want so. Compared with MS Word it is marvelous: UI elements are there where you expect them, they are structured/organized in a logical way, and they do the things you expect them to do. Let’s say, the complete opposite of MS Word
You find a very short review of Nisus on my blog.
No, I just said that probably the most reliable way (in terms of getting the same appearance) would be to have a RTF document.
The thing is the macOS clipboard, as I tried to explain in my post above:
The clipboard is not a single chunk of data, it has various flavors, aka clipboard types. Example:
If you copy text from a MS Word document you’ll find the copied data on the clipboard as…
- RTF
- HTML
- Plain text
- and many more clipboard types
My assumption is that KM’s Named Clipboards work similar to the OS clipboard. That means (if my assumption is true): if you read a file to a Named Clipboard it’s similar to selecting all and copying it to the OS clipboard.
Now the important stuff:
-
It depends on the source which clipboard types will be populated when copying. If you copy a JPEG image you won’t find any data on the RTF clipboard type, nor on the HTML type.
-
When pasting from the clipboard, it’s the target app that decides which clipboard type to choose.
Since KM’s Display Text action will most likely prefer the RTF clipboard (if not available it will take the Plain Text) we should assure that there is something good on the RTF clipboard type. And the best way to do this is certainly to have a fully RTF-compatible format, speak an RTF document.
As said, this is not necessary, since also non-RTF documents will allow the clipboard to take RTF data. But the chance to loose formatting is higher in that case. Just copy from an Excel document and paste into a RTF document (or a KM Display Text action): some formatting will be maintained, other things will be messed up.
So, my proposal to save as RTF was only to optimize chances to get the KM window to display the same as you see in the source document.