Formatting and compilation

Hi Folks

I think I’m missing something obvious, but having spent a couple of hours grappling, I’m posting here …

While writing a technical document, I want to have a numbered figure ‘label’ under each figure. So, I insert Figure <$n:figure:nameofthingy> and apply a defined style of “figure” to the text. Basically, the style centres the text “Figure 1”, changes to a bold font, and slightly smaller text than the body style.

When I compile, all text gets replaced with body styles, so I lose the centre/font/size attributes set for the “Figure 1” text. It becomes left justified and in the same text as the rest of the document.

I can override each of these individual figure labels throughout my document (type in text, apply “figure” style, highlight the text, then go to format->formatting->preserve formatting), but surely there’s something in the compilation output that allows me to specify the centre/font/size for each style I have created on output.

So, for example, if I wanted to change all the “figure” styles from its current sensible format to being in comic sans, underlined and in blue on output, the compiler should do it … the alternative is that I have to go to every figure throughout the document, change the style and then apply a format->formatting->preserve formatting.

… I hope that makes sense.

Basically, I want to know how to create a compiler override on output for the style presets I define. Alternatively how to use the style preset I used in the main document without having to go through the format->formatting->preserve formatting routine each time I add a new figure.

Thanks in advance.
Mike

You can apply preserve formatting to your preset. What I would do is put your cursor within such a caption with preserve formatting applied, then go to Format —> Formatting —> Redefine Preset from Selection. After that, all text you apply your Caption preset to should have preserve formatting applied automatically.

HTH

Mr X

Aha - thank you - I didn’t realise the preserve formatting was ‘sticky’ (so to speak). I take it that I can’t do an override during compilation?

This suggests that I can only set formatting options for ‘Heading’, ‘Sub-Heading’ et al, during the editing stage. So Heading 1, in bold/black/18pt during edit, vs. output being bold-font/blue/20pt for colour printing; Helvetica/bold/black/24pt for monochrome would require a style redefinition prior to compilation?

(Not saying that I would do that, merely wanting to understand the concept).

You can also add a custom keyboard shortcut to the “Preserve Formatting” command itself. Then you can just toggle it as easily as you might toggle italics.

To answer one of your main questions: there are a number of global options for how text formatting can be preserved (beyond the explicit use of Preserve Formatting), in the Options button of the Formatting compile pane, as well as how much preservation that Preserve Formatting actually does. So there’s a bit of flexibility here. “Preserve alignment: Centered text only” would get you pretty close to preserving captions—small font size aside, without using Preserve Formatting at all.

While you’re in the Formatting pane, play with the “Title” checkbox. In addition to the Section Layout… button, this is the most popular way to do headings, since you can control the formatting in one location, and additionally add (or use exclusively) generic text such as Chapter <$n> to get automatically numbered chapters. Since formatting rules can be supplied by icon type and depth, there is a huge amount of flexibility here for multiple heading levels. In most cases, I would recommend that approach over using typed in titles with Preserve Formatting in the editor. The latter is of course a lot easier to do—just type it in and you’re done, no figuring out multi-level outline stylesheets—but as you note it’s rather inflexible if you need to make unforeseen changes to the look of the document.

We do have plans to improve that aspect in the future, which will mean text-based headings will be more useful and convenient in the future.

Great responses thank you. I look forward to the new options - I thought the compiler would do something akin to the mapping that the import dialogue boxes in InDesign provide:

input style H1->document style Heading 1
input style H2->document style Some other style

So my document with figures could go out to review to a peer group thus:
Document Figure Style->Output Figure Style for PDF compilation
Document Figures for review->Output Figure Style for PDF review during compilation

and, for non-review peers
Document Figure Style->Output Figure Style for RTF
Document Figure Style for review->Output Figure Style for RTF (same style for both)

So, the compiler creates output styles based on mapping the input style tags to the output style. This would really expand the capabilities of the compiler stage. If I were going all out with my nice-to-have list, perhaps we could also have a ‘null’ output style …

Document style for comments from peer group->null (not output) for final RTF

I know we can do that with annotations, but this would offer greater flexibility, particularly when working with technical documentation as it would allow me to create different ‘review’ variants for different audiences. Some of the technical documentation contains life-critical bits, and need legal as well as technical review - comments and notes to different peer groups would prove extremely useful.

This would provide a mechanism to do something like:

Compile for technical peers:
Technical comments->Comments for technical audience, bold, blue
Technical comments->italics, blue, and smaller font for information to lawyers

Compile for lawyers:
Legal comments->Comments for lawyers, bold, red, double-spaced
Legal comments->italics, green, and smaller font for information to technical peers

Compile for internal management:
Technical comments->italic, blue, smaller font for review output
Legal comments->italic, green, smaller font for review output

Compile for final output:
Technical comments->null
Legal comments->null

Basically, providing ways of including/formatting relevant comments, to appropriate audiences

At the moment, I’m creating new text documents and dropping them in and out of the compile run, based on audience. This, however, destroys the flow somewhat (and takes some effort to maintain).

If there’s something like the above input/output style mapping in the pipeline, I shall be one happy bunny! (I’m actually happy already, so it’s more a case of banking future happiness).

Thanks again for the response.

Thanks for the feedback. The details are not all hammered out yet, so I can’t get into specifics, but I think you should be able to do most of what you are talking about here. To be clear this is a long way off though, don’t start working with the idea that it will be something you can use fairly soon. It’s a big thing, with a lot of moving parts, and above all we want it to be dirt simple to use (unlike InDesign!).

For right now, something you could give some thought to is MultiMarkdown. That has always been our answer for more complicated document formats and workflows in the past. The user manual does some stuff similar to what you describe, where I can tag ranges of text and do different things with them depending on the output (for example, removing Windows or Mac specific text from one platform version or the other). Vanilla MMD has a stock number of semantic forms you can use that are general purpose, but since it has a programmable interface for conversion, and makes use of flexible formats like Flat ODT and LaTeX, you can program a lot of “smarts” into your compile workflow. It really is the advanced end of Scrivener usage. The main drawback is that it requires a more technical approach to writing. No GUI stuff for the most part. It is Markdown based though, so it’s not like you’d be writing in XML code or anything overly dense.

Understood - I thought I’d make the most of the spotlight while in it :wink: Happy to beta test that bit, if and when it appears.

Thanks lots
Mike