Style management

I write many types of things; different categories of stuff.

But when I open Scrivener, and apply the (horribly inaccessible - sorry Keith, but true) formatting presets, my choices are cripplingly limited. Body is body is body.

But the reality is that when I am writing one type of document, I want a certain font, line spacing and paragraph spacing for my body; when writing another, the optimal body formatting is different. (Novels want no additional paragraph spacing, but first line indents; technical stuff wants paragraph spacing without the indents.)

Can we please have either per-document formatting definitions, or a styling template that allows us to select which one we want.

A true per-document style system is planned for the next major iteration of Scrivener.

Formatting presets are readily available from the left-most button in the Formatting bar.

Thanks.

So I know what kind of rabbit hole I am looking down in considering moving all my stuff to Scrivener, is the new style system actually going to use styles, or just be a mechanism for applying pre-defined hard formatting to text?

When I say “use styles,” I mean that if I change the definition of body, it automatically updates all body paragraphs. (Basic semantic writing, really.)

And - I know, pushy, pushy - what time scales are we looking at? (for Windows)

It will be a true styles system. We’re talking some time in [redacted], but I can’t give exact dates since it is early days in terms of the next major version as yet.

Oops, now you’ve done it! :unamused:
Who’ll take bets on the date of the first complaint about the “mythical” version 3 being sometime in January? I can see it now, “You said 2015 and it’s January already and there’s still no sign!” My bet is January 1…*

[size=85]I’ve made a note in my diary to post the complaint myself, just in case no-one else does*. :wink:
**Which probably invalidates my bet. :blush: [/size]

Quick! Delete it before anyone reads it.

I’ll cause a distraction.

QUICK LOOK AT THIS WEBSITE:

DUCKSARETHEBEST.COM

Sometimes I wonder if vic-k, wock and I really are the rampant miscreants here. You two with your subtleties and suggestions may actually be worse than our blatant changing of topics in a thread.

[size=150]I think green is better than red[/size]

See, obvious. Avoidable.

Just sayin’

That’s us: The Minus Two.

Ha ha, this is exactly why we are not talking about 3.0 yet, because if we give any rough estimates as to when it will be ready, we will get a lot of flak when it’s not, we have learned the hard way. :slight_smile: So let me rephrase that: Styles will be in the next major iteration of Scrivener, which will probably be developed and released some time this decade, although we cannot confirm whether any development has yet begun or say what other features may or may not go into this putative future version. Terms and conditions may apply.

So tomorrow, right? Right?

I mean tomorrow is in this decade isn’t it?

And then we can all watch vic-k write … wait … hang on … watch. vic-k. No. No! NO! BAD BAD BAD!!! DO NOT RELEASE!!! DO NOT RELEASE!!!

I just ran across this quote in an article about Apple, but it would seem to apply in Lit&Lat’s case as well

cultofmac.com/283720/apple-j … d-the-mac/

This would be soooo awesome! Also, please finish the Linux version so I can pay you guys!

Are you talking about a style sheet similar to what the original character based MS-WORD had?

If you are, that’s terrific. It would be the perfect answer to the original suggestion.

I was in charge of setting it up to use across an aerospace engineering contract at Rockwell. We had style sheets defined for every type of document we produced. We put those style sheets on a server and locked them. We had 1,000+ engineers producing documents and they all looked the same. We could have 50 people contributing to a presentation and it was uniform. A body text paragraph copied from one document to the other automatically reformatted to match the new document on arrival.

Indents, font, paragraph spacing, lists, numbering (for specifications, etc.) all adjusted on the fly.

It would allow the user of Scrivener to define the styles wanted for the various document. The style sheet could be attached to the document, or stored in a library of style sheets, which is what we did. If the customer changed a format specification, all we had to do was change the master in the library and every time after that a document was called up, it automatically adopted the proper format settings.

Probably TMI, but I thought I’d put it out there.

Fitch

It’s worth mentioning that for broad strokes, Scrivener already accomplishes much of what you’re describing there, Fitch. The compiler, and in particular the Formatting compile option pane, is a very good way to design the overall look of a document, from the headings down to the body text. With this system, all of your engineers could be writing documents using their own person preferences for font and overall formatting (why force everyone to stare at some universal requirement all day, right?), but then all could compile to a centrally maintained compile preset that tidies up all of their individual messes. Multiple presets can be employed to distribute copies to different standards, all from the same source.

What Scrivener lacks at the moment, is a fluid definition for anything other than “body text”, making format revisions to existing text a manual process. So that’s where theoretical stylesheets could fit in, in this theoretical future version of Scrivener that may or may not exist. :wink:

I just wanted to let you know that there is already a pretty good 90% (for technical work, I’d say, and much higher if there are never frequent revisions to the formatting specifications—then you can just use Preserve Formatting for these individual components, in conjunction with the existing Formatting Presets) system for fluid document production off of a single text source—and for most authors not doing technical work, that’s probably much closer to 99%. If your publisher needs the margins tweaked or the leading incremented slightly, that’s not a problem in the current iterations of Scrivener.

Given the OP’s wording, I do wonder if compile presets might not just be enough? There isn’t mention of the problem where a text is composed of many semantic components that require different formatting that must be adjusted dynamically to produce to multiple document specifications—but rather that different documents require different body text formatting.

If that is all one needs, or their different semantic components are written to a static specification (like Chicago style), then Scrivener already does that beautifully. The compiler is the stylesheet for simple (in terms of formatting) documents, and Preserve Formatting is the tool to handle exceptions to that.

I agree, the template should do most of what the old (long time ago) MS-WORD style sheet did. It might if I could figure out how to tailor it.

What I miss, or haven’t found yet, in Scrivener is the ability to go to one handy menu and set up all aspects of a template. I’m really new to this SW so I need to do some investigation. I’d like to be able to set up everything about both the document and how scrivener appears on screen in one place instead of always being surprised by something.

I started a new project using the ‘novel’ template. I tried to get it all setup the way I wanted it. How Scrivener looks on the screen is important. Having to squint to read menus doesn’t make the SW transparent to the writing process which is, I think, one of the designers goals. The ability to easily adjust the size of the print in the composition window is evidence of that. My 72 year old eyes love that feature!

I use three monitors, but the center one which Scrivener runs on is a high resolution monitor, 2560 x 1440, so the stock fonts on about everything are too small. So are the editor icons but there is no fix for that, at least none that I’ve found. I run the binder with Aerial at 16 points, for example. I have found a way to make everything but the icons easy to see. I thought I had it right but when I saved it as a template and exited, some things didn’t stay preset and I had to do some of it again. It’s probably user error.

But the template, if I ever figure it out, has the potential to act as a style sheet.

Fitch

PS: I’m retired now writing thriller novels, which will probably never be published, to keep my brain from turning to oatmeal. A lot of engineers (I’m one) are very visual. I’ve written tens of thousands of pages of technical documentation. How it appeared on screen was important. Especially when it was necessary to explain analysis. I’d have loved a program like SCAPPLE for creating figures.

frw

That is the File/Compile… command. If you’ve been looking at it from a standard word processor perspective, then you won’t find anything like that. The editing environment in Scrivener is intentionally divorced from the production components, so you can, for example, type in 16pt Arial all day even though you’d rarely ever use that for print. Again, not too dissimilar from advanced stylesheet usage in something like Word, but different.

While the primary purpose of Compile is to of course turn an arbitrary number of fragments into a single document, in doing so, it can handle a variable amount of structure and design for that document. At its most basic, the “Original” preset, it functions mostly as a pass-through, but what you’d be more interested in is the Formatting pane. Click the blue up-arrow to view all options, and within that section you’ll find the ability to override the source text formatting, generate structural headings, handle automatic numbering and other things of this nature. As with Word’s outliner-based stylesheets, it is capable of producing multi-level formats (so level one folders could function as major sections, level two as subsections, and so forth). One of the major differences between our system and a traditional word processor is that outliner levels can dictate all formatting—not just the headings (I’d say another major difference is that our system lets you write “off the record”, leaving content in certain sections of the hierarchy out of the output—i.e. one can outline deeper than what should be visible to the end reader). There are some interesting implications there—some people use document depth specifically to implement fluid formatting designs—if all of your block quotes are level 3 text, you can style them independently from the body text on levels 1 & 2. They can be indented for one preset, or set as green sans serif text for HTML output, etc. It’s a big component of the software, definitely more advanced, but if you want to design outputs for documents—that’s your tool.

Without learning too much about it or digging into the options, you could briefly test it by throwing some sample content together and then compiling RTFs using different “Format As” presets. You’ll see from that that you can control quite a bit about the design of the document. The interactive tutorial in fact goes over this in its compile introduction. One of the first things it has you do is compile the tutorial with different presets to see how you can use the software in a more WYSIWYG fashion, vs. a fluid “stylesheet” fashion.

You are correct in that there is no way to resize the icons. They are raster images, not vector, so to allow for a larger size we would have to hand draw an entirely new set at a different size. However the high-res monitor issue is something specifically not fully supported at the moment, which is why you’re probably seeing things far smaller than they should be. That is something we definitely intend to fix. I think there is a Windows setting that will blow up UI rasters. The result is fuzzy, but at least not microscopic, right? I wish I knew the trick off-hand; it was just something I happened across when playing with a Lenova Yoga2 at a store.

At the moment it sounds like you’re using the program in the least visually appealing configuration (though I understand why, text just looks so nice on those high-res screens!), mainly because we’re still halfway in the middle of high-res adoption (a lot of the hold-up is the coding toolkit, Qt). Having high-res icon sets and more acceptable text layout at varying UI sizes is the goal, though. Check around on the forum, there are a few threads with tips for tweaking the settings to work better with Scrivener.

With one trivial correction to terminology, yes. It’s not the template that controls this, but the compile settings (and the presets that one uses or creates). Templates in Scrivener are more like starting points, or elaborate boilerplates. After their creation, everything about them can be changed. They do nothing you cannot do yourself, and starting with one (or not) doesn’t lock you into any particular approach. At the project creation stage, everything is malleable. In that sense, there isn’t a direct analogy to DOT files in Scrivener.

We’re still a little ways from what I would consider a solid solution for technical documents with fluid output requirements, but we’re working toward that!

Thank you very much for the in-depth reply. Much appreciated.

Fitch

I understand why “true” styles were not part of Scrivener from the beginning: Scrivener is not a WYSIWYG word processor. Scrivener was designed to be a writing tool. In the same way that you use LaTeX to structure a document and let the formatting happen at the end, Scrivener focuses on the structure of your research and assets and writing, allowing you to easily organize and change the structure of your document on the fly (something that’s not easy to do, IMHO, in something like MS Word).

LaTeX is too geeky for general writers.

That said, some basic “true” style capabilities will be a nice addition.

Stay tuned! :wink: