Style indicator?

ja
jandavid
Posts: 67
Joined: Wed Apr 06, 2016 8:41 am
Platform: Mac

Thu Nov 23, 2017 10:14 pm Post

Thanks so much for these hints!

Nontroppo's suggestion did the trick!
So, I'm assuming the default behavior is:
> When changing from a style to no style, then bold/italics is preserved.
> When applying no style to a no style paragraph then it gets rid of everything, including bold/italics and character formatting, and applies whatever is the default set in the prefs.
Seems like this is intended behavior, and it's fine.

... apply that kind of modification at the compile stage

That's actually not my concern, as I export to LaTeX (something which I still need to reconfigure, but which I'm very excited about the new options!!).

Is there a solid reason to be using character formatting in your paragraph style? If you can all avoid it do so, that’s the problem. Character formatting is applied equally to the entire paragraph when these two are combined.

Well, I do need italics for scientific terms, emphases etc. So I had hoped that "no style" would act like a paragraph style, but it seems that it combines paragraph, font, and character information.
I might end up doing what nontroppo did, remapping cmd-I and cmd-B to actual character styles (... will figure that out after I get to setting up my export workflows).

And here is probably the only point where I'm thinking that defining a "Normal" style would probably be better than the "No style" style. One of the strengths of the style system (as well as the previous presets system) is imo that one can set paragraph and character information independently and, in addition decide whether to include font information or not (took me a while to figure it out how to best make use of that in Scriv2 but ended up loving it ever since). But there seems to be no such option for "No style".
For example, when I want to change the font/font size/spacing info, etc. for all of the "no styles" sections but not character information like italics/bold, then going to the preferences and changing the default font won't do anything. I have to manually select the no style sections and change the font. Or I manually select and reapply "No style" to those sections after changing the defaults in the preferences – but that will also get rid of character formatting.
Or maybe I still haven't fully understood how no style works?

What would be the big disadvantage of defining a "Normal" style instead of "No style"? According to Keith:
For the main body text, you should just use "No Style". Otherwise, you'll reduce some of the flexibility of Compile for overriding unstyled text.

Can't I just not define any formatting or pre/suffixes for a custom Normal style, which upon export then doesn't do anything?
(Sorry, if this is a bad question, I haven't had the time to look in depth into the new compiler myself.)

In any case thanks so much for the comprehensive input!

User avatar
nontroppo
Posts: 1287
Joined: Mon Mar 05, 2007 5:22 pm
Platform: Mac
Location: Airstrip One

Fri Nov 24, 2017 1:46 am Post

jandavid wrote:> When changing from a style to no style, then bold/italics is preserved.
> When applying no style to a no style paragraph then it gets rid of everything, including bold/italics and character formatting, and applies whatever is the default set in the prefs.
Seems like this is intended behavior, and it's fine.


This is how I understand it.

jandavid wrote:I might end up doing what nontroppo did, remapping cmd-I and cmd-B to actual character styles (... will figure that out after I get to setting up my export workflows).


It is slightly easier to make these styles before you create your compile format. It is really simple to set up: select a bold word, type ⌃S (Styles panel), click the + icon, name it "Strong" and make it a character style. Now when you create your compile format, you can "import" this style into the compile-format-editor, and (if you use MMD to create your LaTeX) add a ** to prefix and suffix. Then in System Prefs (or BetterTouchTool etc.), rebind ⌘B to trigger "Strong". Keith made sure these rebindings toggle ON/OFF just like the original direct formatting would.

jandavid wrote:What would be the big disadvantage of defining a "Normal" style instead of "No style"? According to Keith:
For the main body text, you should just use "No Style". Otherwise, you'll reduce some of the flexibility of Compile for overriding unstyled text.

Can't I just not define any formatting or pre/suffixes for a custom Normal style, which upon export then doesn't do anything?


I think for those of us who compile to plain text formats, the use of a "Normal" style is less of an issue (we don't have override issues that other users may). Though I strongly prefer writing with styles, I have tried to stick to the recommendation of using "No style" as a base then using styles for clearly defined semantic structure. It has worked fine for me so far, but I never switch my base font/size etc. in a project so haven't really faced this issue. In theory at least, you should be able to transform the "Normal" style just as much during compile (so I believe), but because Compile supports so many output formats, each with a different processing path, I think Keith recommends "No style" with a general "one layer of complexity less" attitude.

User avatar
AmberV
Posts: 24630
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Ourense, Galiza
Contact:

Fri Nov 24, 2017 11:46 am Post

In theory at least, you should be able to transform the “Normal” style just as much during compile (so I believe), but because Compile supports so many output formats, each with a different processing path, I think Keith recommends “No style” with a general “one layer of complexity less” attitude.

Yeah, I might not have elaborated on that concept well enough in my earlier how-to on applying Normal at compile time. It is of course trivial to go into the format designer, add a Normal style and then make it look like whatever you want. It’s fundamentally the same thing I was demonstrating, the only difference is that in my example the compile settings were also responsible for the application of the style itself to the text, rather than having that be something you do consistently in the text editor as you write.

The bigger problem is that you have to do that with each and every format you use, unless you really want whatever “Normal” looks like in the editor to be what it looks like no matter the format.

With the method I was describing, the choice of having “Normal” applied to all body text is specific to the format itself as a function of that format. It is saying, “computer, document, classic Nisus/Word, styled”, and the replicator obeys. But meanwhile you can switch over to Proofing and print out a PDF in double-spaced monotype with a single click.

If your text is “Normal”, you can’t as easy do that. You have to go in an manually edit the proofing format to accommodate the body text.
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

User avatar
xiamenese
Posts: 4690
Joined: Mon Jan 29, 2007 1:32 am
Platform: Mac
Location: London or Exeter, UK.

Fri Nov 24, 2017 12:23 pm Post

Ioa, thanks; that gives me real food for thought.

As a beta tester, I spent quite some time getting my head round the new compile system to get it to produce the output pretty much exactly how I wanted it. I had spent as much time over the years tinkering with the compile system in v.2 so that it would export a document using colour or size coding for which I could use a macro in NWP to convert the various elements into appropriate text styles and headings. In NWP, if I want to change the body-text font throughout, I only need to change it in the 'Normal' style and it cascades down.

In a way, I was using a "junior version" of what @nontroppo does, substituting NWP for MMD+Pandoc.

With the system I developed for v.2, all my documents were compiled in the same way, and in NWP the macro then imported an appropriate set of styles and applied them; a 45 page document was done in under a minute with a couple of clicks. So, essentially, I set about creating a system in v.3 that did the same, only providing the styles, rather than using colour/size coding. In that, I succeeded.

However, from what I've read here, I can see the limitations of the style system I've created, and if—as now seems possible—I need to compile to ePub/mobi, my current style system will be a hindrance rather than a help. I can also see that not having to apply Normal explicitly during writing/editing would be an advantage

So, I'll digest what you and KB have said, and then set about seeing how to change things to be able to use "No Style" converting to Normal on compile, rather than having an explicit Normal style.

Thanks

Mark
The Scrivenato sometimes known as Mr X.
M1 MacBook Air (2021), 11.2.1, 16GB RAM, !TB SSID
iMac 27" (late 2015) 10.15.7, 24GB RAM, 512GB SSID
2017 iPad, iPadOS 14.3, 128GB, Apple Pencil
Scrivener, Scapple, Nisus Writer Pro, Bookends …