I’m running a wiki (from atlassian.com/software/confluence) and need to import Word documents and create one or more Confluence pages from the content out of scrivener. Therefore, I compile my articles into Word and then import them into Confluence.
I can create a single page, or divide the contents up into multiple pages, based on the headings in my document.
The reason for this is to import the full content of my article with Images etc. into the wiki. It’s saves a lot of time for me and is really important.
Here’s the problem:
When I import the word doc (which was compiled by scrivener) two things are not ok:
a) There is no formatting for the heading. In Word, the heading is just a larger font but not formatted as heading. So if I format a page in scriveners as “heading” it’s not a heading in Word.
How can I change that? It’s way too much manual work to correct that after exporting the doc.
b) Links are no correctly displayed/parsed
Links to websites/URLs appear like this:
which has two different links in the background:
one for {+} which leads to the correct URL and the other part lead to the same URL but with a “+” at then …ending as an error message.
What I did so far:
Uploading a “normal” word (=not compiled by scrivener) with links etc. into confluence works fine, no “strange links”
Compiling different word versions…no difference
Tried *.odt format, same problem
Checked the word documents after compiling, nothing to see for me, all links look “normal” and are functional.
see this screenshot:
There is no way to achieve that out of the box as Scrivener does not support stylesheets. All formatting is simply just as you see it, not tied back to some central definition. It shouldn’t be too difficult to fix this however. Word has a tool for selecting all text with similar formatting, which should be all like-styled headings in the document, so you can apply the “Heading 1” stylesheet type with one click after that.
I’m not sure what the issue is there, that doesn’t look like anything Scrivener does. We’re using standard RTF codes for those links. It could be the makers of this web page have only bothered to make sure it works with how Word and OpenOffice make links, that is not uncommon. They would probably appreciate a bug report on that. It could be that even all standard Mac programs (i.e. not ports like Word and OO) have this same issue.
I checked that with the maker of Confluence and they tell me that if other word imports are fine… the problem must be caused by something Scrivener does with the word while exporting.
That’s also my view… if I prepare word with any other program (open office, ms word etc.) they all work fine. ONLY the scrivener export cause this link problem.
Would be great if somebody can review that, it’s really an issue for me.
Best regards,
I just double-checked and RTF files compiled by Scrivener have identical hyperlink syntax in the code as RTF files created by TextEdit, Mail and most native Mac software (like Scrivener). They all have the same style of syntax because they all use the same Cocoa methods to produce them. I would try this on your machine as well, to make sure there isn’t a difference in configuration or compile settings that is complicating things. Just make a simple one-liner test in TextEdit with a + hyperlink in the text, save as RTF, and see if the result is the same on the web page.
I tried the RTF idea, created a rtf (attached) as you told me and uploaded the file to the web page, here is shows the correct links for everything starting with http://
If I compile an RTF in Scrivener with different types of links, they are so far all ok, incl the ones with , see:
So still the question is, why are there this kind of links only in word export from Scrivener and only if the link starts with http://
I need one information to exclude possible problems on my side…when scrivener compiles word docs…has that anything to do with the installed word version? Or is that an independent process?
Update: I used a new mac, installed scrivener, created a file with several different links in it and compiled to word…imported this doc into confluence and received again bad links for links starting with http://
sorry for the number of post, but that’s the Update from Confluence. It seems that your format for the word is creating the problem.
----quote start-----------
"Thank you for providing the raw files from a manually created and from a word compiled with Scrivener.
I’ve tried to open both files in RTF format and was able to verify that there are difference in the format, that might cause the issue when importing the compiled word from Scrivener. Link Test Made with Microsoft Word (Manually Created)
\par \pard\plain \s0\ql\widctlpar\ltrpar{\*\hyphen2\hyphlead2\hyphtrail2\hyphmax0}\cf0\afs24\hich\af9\langfe2052\dbch\af9\lang1081\fs24\loch\f4\lang1033\sl288\slmult1\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\li0\ri0\lin0\rin0\fi360{{\field{\*\fldinst HYPERLINK "http://corma.de" }{\fldrslt \cf4\ul\ulc0\langfe255\lang255\lang255\cf3\ul\ulc1\afs24\rtlch \ltrch\loch\fs28
http://corma.de}}}
It would be best to provide this information to Scrivener to verify why there is a difference between the encoding from manual word and the word compiled with Scrivener. I suspect that it might be some compiling format that Scrivener do that it’s not the same with the standard format that MS Word is using. The fact that normal word document is working and the problem only appears on word document compiled with Scrivener."
Well if we are talking about .doc or .docx that is slightly different than what Scrivener itself does. To answer one of your questions, we use a third-party converter (on a Mac, it is not a possibility to use an installation of Word, but we do that on Windows where we can). Scrivener works in RTF natively, so in nearly every single case that is the best format to use because it has the fewest moving parts and there is nothing .doc/x can do that RTF cannot (from the perspective of what Scrivener does of course). It is mainly of use when you cannot use RTF—Pages for example, has extremely limited document format support for a word processor and requires one to use the .docx conversion out of Scrivener.
So from what I see in your posts, the RTF worked fine from Scrivener as well as from TextEdit. All instances of the problem are derived from cases where you used the built-in converters to build a .doc or .docx file? If that is the case then it sounds like the problem is in the converter we use. It is made by Aspose, by the way, and if there is a problem with it we could probably file a bug report with them. They have been good about fixing glitches in the past.
Where I get confused is in your follow-up from Confluence, where they mention the RTF code is different (we wouldn’t expect it to be identical, RTF has too many right ways to do one thing—it’s a bit like HTML+CSS in that regard, every HTML generator is going to produce different looking HTML code but it will all be valid and potentially even look the same in a browser despite using different techniques for doing so—spans with classes, classes on paragraphs, divs with IDs, modular classes compounded together, inline CSS, old-school font alterations, you get the idea ). Yet above you seemed to indicate that with RTF the output worked fine from Scrivener, and that it matched how other Mac programs export RTF as well—or did I misunderstand that? If it works with RTF from Scrivener, then whatever the problem is is happening after the RTF stage, so examining differences in the RTF code wouldn’t say much.
Anyway, if you could clarify whether the problem is happening with RTF or just DOC/X files, that would help me direct this info to the right parties.
Has Confluence given you any idea why this might be a problem? From what I’ve seen, all they have said is that there is a difference in the RTF, but the RTF files import fine, so that is actually making no difference - it’s the Word files. I can pass on this information to Aspose (the makers of the third-party converters we use), but so far I’m not seeing anything to indicate that it’s a bug on their side - to me, this seems like a bug in Confluence. The links in the .doc and .docx files generated by Aspose conversion open fine in every word processor I’ve tried - Word, Nisus, OpenOffice and so on. Confluence is the only platform that has this problem, so the evidence suggests that it is a problem with their .doc/.docx readers whereby they are having problems with some otherwise valid files.
As I’ve never used the wiki software in question, though, could you please provide a list of steps required to see the problem, including how to get access to the wiki software and what we have to do to upload to that software to see the issue? That way I can pass on the necessary information to Aspose to see what they say.
Simply create a word doc (with some links …with http:// and without) with your Microsoft Word Version and choose “import document” from within the wiki.
That will create a test page and all links should work in that page in the wiki.
Compile a word doc from Scrivener with links (http:// and with www.), import into the wiki and you will see the problem.
My view is the same as the one from Confluence:
Standard Word doc work fine with Import. Compiled docs from Scrivener produce bad links if the doc contains a link starting with http://
So …for me it does not point to Confluence.
Okay, so the problem does indeed seem to lie with Confluence. I just created an account and tested this for myself. I generated .doc and .docx files from Microsoft Word, Pages, TextEdit, Nisus Writer and Scrivener. The only one that imported without the extra “+” characters was the Microsoft Word-generated one. The files generated by Scrivener, Nisus Writer, TextEdit and Apple Pages all had the same problem with the extra charactes. All of these use different exporters (Scrivener uses Aspose, Nisus uses OpenOffice-based exporters, and Pages and TextEdit use Apple’s own .doc and .docx generators, although they both use different generators). So it seems that Confluence’s import methods are somewhat limited and have a bug somewhere whereby they are expecting certain Word-specific formatting rather than allowing for any valid .docx or .doc file. I therefore recommend taking it up with Confluence and asking them to try exporting files from TextEdit or Pages for their testing purposes so that they can reproduce the problem.
Styles, by the way, will be coming in a future version.
). Yet above you seemed to indicate that with RTF the output worked fine from Scrivener, and that it matched how other Mac programs export RTF as well—or did I misunderstand that? If it works with RTF from Scrivener, then whatever the problem is is happening after the RTF stage, so examining differences in the RTF code wouldn’t say much.