Scrivener to Publisher

[Andy Jones]

Does anyone have any recommendations for the best workflow to get a text + images document created with Scrivener through Affinity Publisher to create a  print-ready PDF ?

My Scrivener binder is designed to compile to Markdown for web publication, so it has implied headings as well as linked images.

Ideally I'd let to get a process where the content when imported to Publisher has both text styles and images in picture frames.

I have other tools lying around such as Marked2 and Pandoc that might be useful for creating intermediate formats. So far, I've found that compiling to .docx manages the text styles properly and compiling to .pdf handles the images as I would wish.

Any suggestions to get both working at once ?

Edited August 16, 2021 by Andy Jones

[Andy Jones]

Well I think there's something going on that I don't understand (no surprise !)

If I "Place" the pandoc .docx in a text frame in Publisher, initially the images don't seem to be editable (i.e. movable, resizable). But after adding an image to the document (dragging from Finder on Mac), now ALL the images in the document are moveable and editable !

[Callum]

Hi Andy Jones,
Welcome to the forums

I think you may have already found an ideal workflow with exporting to a common format from Scrivener and then placing that document into Publisher. When you have placed your document into a frame try selecting the frame in the layers panel and double clicking your document that should be clipped as its child layer this will open the document in a separate window and allow you to make edits to it.

Thanks
C

[Mareike]

When I import from Scrivener (via Word) with copy and paste, I lose all the links. 

Does this happen as well, when I place the document? 

[John Rostron]

50 minutes ago, Mareike said:

When I import from Scrivener (via Word) with copy and paste, I lose all the links. 

Does this happen as well, when I place the document? 

Have you tried it?

John

[PaoloT]

Just here for adding a useless contribution, in asking more integration with Scrivener! It is the tool of choice of many self-published authors, and Publisher will be the ideal companion!

Paolo

 

[PaoloT]

My ideal workflow (in perspective), with Scrivener + Publisher?

Write and structure with Scrivener. Add linked images. Create your (hierarchically organized) paragraph, character, object and table styles.

Import to Publisher. Since all documents inside a Scrivener project is an RTF file, Publisher will simply import them as RTF files.

The Publisher project will have the same structure as the Scrivener one. The Section pane will give access to the separate Publisher documents making the project. Styles will be imported (and adapted to the existing styles, if any). Linked images will be linked, and the relevant object styles applied.

Do you need to restart in Scrivener, for a new version of the project? Export from Publisher to Scrivener. Everything will be preserved, if supported by Scrivener. Styles will be preserved, so that they will be ready to be applied again when importing back to Publisher.

Paolo

(To be honest: I know this is probably just a (wet) dream; but it would be really great if if happened. A two-faced monster: the smart writer and research assistant, and the layout professional, both working on the same thoughts. But if Publisher could adopt a project structure philosophy similar to Scrivener's, and would remain fast and light, we would be able to work right in the layout program, doubling as a writing and structuring tool).

 

[PaoloT]

A few word more to explain why some of us want integration with Scrivener.

Desktop publishing programs can do several very different things. They can be used to finish a flyer. To put a novel in page. To create a manual or textbook.

Some of us users rely strongly on the graphic aspects of a publication. Some other on text. So create a page freely, some other heavily structure everything.

Page layout programs have always lived between these extremes. PageMaker was page-oriented. FrameMaker was structure-oriented. InDesign, starting from CS5.5, tried to integrate features from both worlds: sophisticate page appearance, structured long documents. Unfortunately, this evolution stopped at what was in CS6 (from year 2012).

People dealing with long, structured text often use Scrivener for writing, before creating the layout. They deal with an abstract shape, that will only become real when imported in the page layout software.

Some programs, notably MadCap Flare, try to blends the ease of structuring of Scrivener with some more advanced page layout (and web site) features. Unfortunately, the graphic aspect is not really that sophisticate.

Affinity Publisher could be the next step, and the still missing tool: dealing with complex, structured projects; and very sophisticate as for graphic appearance.

Paolo

 

[PaoloT]

Me again, with a couple use cases.

CASE 1 – Publisher as the output tool for simple layout projects. You develop the project structure in Scrivener, using all the supplied tools (binder, outliner, corkboard, collections, notes, research folder…). Images are linked. No fancy styles, just the simplest text, with a minimum of formatting used as a signal for structure elements.

You send the drafts to proofreaders as raw PDF files, ebooks, or web pages. Every element is there, but not in the final appearance. Your annotations to proofreaders are added as Scrivener annotations. All corrections are made in Scrivener.

When done, you import your project to Publisher. Styles are converted to the ones in the Publisher template. The document preserves the original structure. You generate the TOC. No other change is due, apart, maybe, some forced page break. The project is ready to be output in the file formats supported by Publisher (print, PDF, ebook, web pages).

If having to update the project, you start again from Scrivener.

 

CASE 2 – Publisher for finishing the layout. You do all the above work in Scrivener, up to external proofreading. Your customers want a graphically sophisticate document. You complete your work in Publisher, adding complex layout details with no corresponding elements in Scrivener.

If having to update the project, you have either to stay in Publisher, or go back to Scrivener, and then repeat all the advanced page layout operations.

 

In general, I would say that Case 1 would satisfy most technical documentation requirements. Case 2 would be a more complicated matter, but this is where the design creativity comes into play, and the poor text writer slips into the shadows.

Paolo

 

[Old Bruce]

I have to say that if you are doing the writing and layout in Scrivener then maybe just stay in Scrivener all the way. If you are doing only the writing in Scrivener then export as plain text and get the images and use Publisher. I am not a fan of importing finished work and then having to redo all the formatting and sizing of photos etc. I am a big fan of Plain Text.

[PaoloT]

3 hours ago, Old Bruce said:

I have to say that if you are doing the writing and layout in Scrivener then maybe just stay in Scrivener all the way. If you are doing only the writing in Scrivener then export as plain text and get the images and use Publisher.

Exchanging big projects, like the ones Scrivener is usually called in for, using plain text as the interchange file format, would be incredibly inefficient. I would say plainly impossible, since you wouldn't even know the role of each paragraph and span of text.

Scrivener is usually used to write without caring about the final look of the text. You work in a structured environment, where each document in a project is at a particular level in the structure. Create a containing folder, that is an H1 level paragraph, and add a document inside it. The document's title is an H2 level heading, and its text can be any style you apply (Body, Indented, Bulleted…).

Insert a document inside the document, and you get an H3 level heading, with all the subsequent body text. And if you need it, select one word or a few, and apply a character style. It hasn't to have the same look as the finished document: it just has to have that style applied as a structural indicator.

The final look is so little relevant in Scrivener, that you can even write in a dark full screen mode, with a totally different font. Maybe a non-proportional one. Or, you can go and scribble into index cards, or in a outline. The final look of the document may even be far from being imagined.

You can export in several different file formats. RTF, DOCX, ePub, HTML, ICML, MultiMarkDown, Pandoc. What will happen to its output depends on how you will treat it. You can import an RTF file into Publisher, an ICML file into InDesign, and the original styles will likely be preserved. ICML will also preserve linked images.

Only at this point you will apply styling to an already structured document. The styles are already there. It is in Publsher that you have to give them an actual appearance.

At the same time, a different Scrivener's output from the same project may have already been delivered as an ebook…

Paolo

 

 

 

[Old Bruce]

19 minutes ago, PaoloT said:

Scrivener is usually used to write without caring about the final look of the text.

Which is why I suggested keeping it all in Scrivener. Why double the amount of work by bringing it into Publisher?

[PaoloT]

14 minutes ago, Old Bruce said:

Which is why I suggested keeping it all in Scrivener. Why double the amount of work by bringing it into Publisher?

Because Publisher has the tools to make the final look of the document well crafted, elegant, typographically refined. Something that Scrivener, based on a much more basic text engine and lacking several graphic tools, can't do.

Paolo

 

[PaoloT]

I believe that the current incommunicability between writing and publishing software dates back to the birth of the page layout machines. Typesetting was unidirectional, with manuscripts put into metal plates by way of engraving. The early page layout software was meant to produce graphically pleasant printed documents. Once done, they were done.

The typical workflow for early page layout programs was easy: a book or a newsletter starts from a handwritten page or a Word/WordPerfect document, that the graphic artists transforms into a sophisticate-looking graphic document. Publishing software has been for long considered something for visual artists, not text writers.

Things started to be more complicate with magazines. Here, several different contributions were involved. The full magazine issue was a patchwork of writing, photos, original writings, advertising, totally diverging topics. Adobe had to invent the ICML file format, to include flexible text contribution from multiple writers, while the layout artists were working in the same space. The workflow was now a complex one.

Technical writing has always been neglected. Partly because of the social stigma around technical writers (Stephen King considers them the scum of humankind, in his On Writing). Partly because not even those who need technical writing realize that technical writing is a thing. Many companies are still astounded when someone starts to speak about reuse and updates. The book is done once done. Updates? Add another booklet, or more than two.

So, we still have that unidirectional workflow. A writer sends texts, a graphic artist put it into page. Illustrations are assembled with the text. Done, published. To a PDF, considered as virtual paper. eBooks, web magazines, online help, are still a different thing. No way to go back and forth between the input and the output. No way to deal with granular components of the final document (final? nothing is final anymore!).

Who knows. Maybe it's time for a new paradigm to be adopted. Technical writing can be continuously changing, and so its byproducts.

Paolo

 

[Josef Rapaport]

Very informative exchange of ideas and info.

as a visual artist who wants to write a visually appealing book that explains some concepts regarding Form Color Shape and Design the styling important as the writing itself, perhaps even more. 
so yes, I am with you Paulo on the need to integrate the two aspects.

thanks again

 

josef

 

[tudor]

On 9/4/2022 at 8:11 PM, PaoloT said:

So, we still have that unidirectional workflow. A writer sends texts, a graphic artist put it into page. Illustrations are assembled with the text. Done, published. To a PDF, considered as virtual paper. eBooks, web magazines, online help, are still a different thing. No way to go back and forth between the input and the output.

For InDesign users, there is an excellent plugin called WordsFlow, that allows a true bidirectional workflow between source documents in Word format and the InDesign layout file. It works pretty well. You can make changes either in the Word source file, or in InDesign, and have then synced. There's also another plugin made by the same company, called DocsFlow, that uses online Google Docs source documents instead of Word files.

Not having a plugin interface for their apps is a huge missed opportunity for Affinity.