Globally Redefining Style Presets ?

If you redefine a text preset style in Scrivener I’ve noticed that it is does not automatically update any other text that is using this preset in the Project. For instance if I redefined my Chapter_Heading preset and added bold, the current chapter heading would be updated by the preset but I would then manually have to update all of the other 40 chapter headings in my scrivener doc with the new chapter heading preset style. This problem applies to all scrivener style presets including title, chapter text and other main headers and styled text in your scriv doc. After you have redefined any one of these styles, there’s just no easy way or no automatic mechanism that implements that redefined preset change globally throughout your whole project.

Wouldn’t it be better, after you have just redefined that preset style, for all chapter headings using this preset style in your project to be automatically updated to that new style after you have redefined it ? This is also the common norm for para and char style redefinitions or updates in Word, OpenOffice, InDesign etc.

Of course it would be better, but, if you had read through the information and posts available on this, you would have realised that the “Presets” are just that, not “Styles” in the sense of Word’s or ID’s styles, rather a “format painter” type of approach.

Furthermore, you would have found that true “Styles” will be coming with Scrivener 3, to be released sometime in the next year or so — both for Mac and Windows.

And Scrivener is a different beast from ID, Word or OpenOffice, with a project consisting of potentially thousands of small files on disk across which all “styles” will have to be updated, even if those files are not open at the time when the change is made to the style code … and Lit&Lat is not a huge organisation like Adobe or Microsoft, but is one developer on Mac and two — or maybe 1 1/2 — on Windows.

:slight_smile:

Mr X

Indeed, as Mr X says, the reason we call them “formatting presets” instead of “styles” is that they are just that: formatting presets that you can apply to the text. A full styles system in Scrivener is much more difficult than it is in applications that show you all the text in a single document (such as most word processors), because whenever you change a style, it would have to update all of the text throughout the project, even text that isn’t even open, in potentially large projects. There is also the problem of how to deal with styles during Compile and in the various formats that Scrivener supports.

However, as noted, we have finally tackled that problem. I put several months into the issue last year and have a full styles system implemented for the next major update of Scrivener, which will be out sometime in 2016. The Windows team are also working on getting styles working in the PC version (I believe, at the time of writing, that they are mostly implemented but with some issues to iron out).

All the best,
Keith

My thanks to both KB and Mr X for your replies which were very informative and helpful.

I would like to add that the purpose of my suggestion, as always, is not to criticize but to improve on what is already a wonderful app which I will always use as an author. There’s just nothing better. I must also add that, for just simple reflowable ebooks(not EPUB 3, not Fixed layout etc) Scrivener is untouchable for speed. I use Scrivener to zap my novel straight to epub and then I do the final end tweaks in html and CSS with Sigil(also a class app). This workflow allows me to push out an ebook, completely tested and ready for epub or mobi upload, in less than 45 mins.

I’m also impressed with the html that Scrivener produces in the epub output. I’ve noted that Scrivener renders styles very differently in the CSS. I think it was very a clever design tactic to convert ALL para style and char styles – including para and char overrides – into just global text styles or classes within the CSS. Very clever indeed. That means that the text xhtml code that is produce by Scrivener contains no messy open span style code and that makes for cleaner more compact html which is easier to work on. Forgive me harping on about HTML, but I’m an old s/w programmer who likes to acknowledge a good conversion app when he sees it. This is so rare for auto-generated HTML(think Word HTML – Ugh!!). :slight_smile: