Change Background and Foreground colour at runtime (Feature Request)

[viegasfh]

Hi!

When writing my stories, I usually have several storylines and in the software I used to work with (the defunct Sophocles) I was able to create outlines with background and foreground colours for each thread. I was wondering if it is possible, at runtime, to change the background colour and foreground colour of a particular portion of text, provided that we use tags to signal this.

Given that Fountain uses [[ ]] that are ignored, I was wondering how feasible it would be to precede any text with instructions for background colour and foreground colour that would change at runtime. For instance, let's say we have the following synopsis

=[[bg:#ffdece;fg:#ffffee]]This is is the text that goes in the synopsis

Another example would be:

#[[bg:#ffdece;fg:#ffffee]] This section will have background and foreground colour set at runtime

[[bg:#ffdece;fg:#ffffee]]This is a paragraph that also has foreground and background set at runtime.

How feasible would this be in VS Code?

Look forward to your input

[viegasfh]

Hi again!

It just occurred to me that what goes inside the notes to mark the foreground and background could actually be a json object. This way this could be extended to tag text with other features. For instance, SHOTS for shotlist extraction, etc...

[piersdeseilligny]

Hi! So I don't see why this wouldn't be possible; in fact Highland 2 does something similar, but with the non-fountain {{ }} syntax (although for other features, such as markers) . I'm not sure what the best approach would be? I can see an advantage to using {{ }} instead, as it avoids ambiguity with notes [[ ]] or boneyard /* */. However, the disadvantage is that text created through betterfountain will then no longer be strictly compatible with other fountain renderers. What do you think?

In regards to JSON, that definitely makes sense, although maybe relaxedjson would be better, as it's a little clearer:

JSON	RJSON
{{"bg":"#ffdece", "fg":"#ffffee"}}	{{bg: #ffdece, fg: #ffffee}}

By setting the text "at runtime", do you mean only changing the color in the editor, or also in the preview/rendered PDF?

[viegasfh]

Hi Piers,

I do understand what you mean. The reason for using the notes [[ ]] is because they are just ignored and you can write a custom script to extract them alone, and it remains valid Fountain. The counterpart of {{ }} is that, as you say it is no longer compatible with other renderers. Taking into account that sooner or latter one has to add custom features, I wouldn't discard the Highland 2 {{}} syntax. In addition, we would add an export feature that strips them out for other Fountain renderers. This way we could keep the Fountain compatibility.

Given that Fountain is an open standard, we could also propose this to them. Highland already supports it and other Fountain based software could also support them as a way to add custom features without resorting to the notes [[ ]]. This way I would stop using [[ ]] for props, camera shots, etc...

As for RelaxedJson, I was unaware of it, but to be honest I prefer it over plain old Json. Less " " to type. :-D

As for setting the text "at runtime" I meant chaning the colour in the editor, but now that you have mentioned the preview/rendered PDF, I guess it could be both if it is possible. I am sure it is possible to render them in the Preview/Rendered PDF, and if this is the only option then it should do the job.

Let me know what you think is better for you.

Thanks!

Fidel H Viegas

[viegasfh]

Hi again!

Just another quick thought. If the {{ }} syntax is chosen, then instead of adding them inline, couldn't we add them before? This way, whatever follows the {{ }} gets those settings applied. And then another {{ }} to reset it back to normal.

For instance,

{{bg:#ff00ee}}

This is a section

=This is a synopsis

INT. SOME PLACE - SOME TIME

This is a paragraph

{{DEFAULT}} /* This is just an example. Doesn't have to be this way */

Do you have any suggestions on this? How would you implement it?

[piersdeseilligny]

I think what you suggested there would definitely make the most sense, ie you start a section with {{bg:#ff00ee, fg:#ffffff}} and reset the style with something such as {{bg:default, fg:default}}. Minor questions which follow are then:

• Which styling options should there be?
• What happens to the syntax highlighting?
• How does one decide if the styling goes across to the rendered PDF too, or is only in the editor?

I have to say though, after thinking about it a little more I'm a little sceptical of adding these sort of styling options, because I feel like it doesn't quite fit with the spirit of Fountain, aka a simple format which simply describes the content of a screenplay in a platform and software agnostic way.
Just how HTML and CSS separate the concerns of content and style, I feel like there should be a similar paradigm for fountain - I'm just not sure what it should be, or if it would be overkill.

[viegasfh]

Hi Piers,

I spent some time analysing the suggestions as well and I came to the conclusion that, given that this is more for outlining and visually knowing which bits belong to which thread, it doesn't make sense apply the styles to every element. Only notes and synopsis, or maybe only synopsis as these are what provide information about sections and scenes. I have looked into Movie Magic Screenwriter and Sophocles, from which I took this idea and that is exactly what those softwares do. Therefore, what occurred to me was configure colours based on threads, setup at the top of the file and then apply them to synopsis that precede with the tag identifying the thread. We could then export each individual thread's set of synopsis or export all synopsys properly coloured in the preview.

I do understand what you mean about having a similar paradigm where you separate content an style, but unfortunately there isn't any, hence the reason Highland uses their own extension. And if one doesn't want to add extra synopsis there is the initial suggestion of using notes, and include the RelaxedJson inside of it.

In theory we would have something like this:

{{threads:[
{thread: thread1, bg:#ff44dd,fg:#ffffff},
[thread: thread2, bg:#ddccee}
]
}}

The above would be configured at the top.

Then before each synopsis:

{{thread:thread1}}
= This is the synopsis that will have the settings for thread1 applied

In terms of precedence, if this is found, then this takes precedence over the default syntax highlighting, and we could have the option to export the threads coloured.

Here is a screenshot of how this looks in Sophocles.

On the left you have the threads, and on the right you have the steps that correspond to the synopsis in Fountain.

I think having only synopsis makes it lighter and more sense as well.

If you want to keep Fountain compatibility, then we can still use the notes syntax [[ ]].

If using the Highland syntax, then an export feature would strip them out and export a clean Fountain.

Maybe you can think of something else. This is the best I came up with. I do outline a lot using synopsis and I'd like to keep track of all the threads visually in the editor and be able to print it as well. I was reverse engineering the Sophocles file format and managed to find the structure of the screenplay part, but sometimes it just spits gibberish, maybe because it was written using MFC Serialization. I will probably need to reverse engineer it using C++ and MFC Serialization. If I manage to reverse engineer the Sophocles file format, then I will be able to outline using Sophocles and then export to Fountain for write up, and vice-versa. On the other hand, it would be nice to have this feature in a Fountain editor, which sort of matches more or less how Sophocles and Movie Magic Screenwriter work.

Anyway... give it some thought and see if it is feasible or not. If it turns overkill in the editor, I think it would be doable in the rendering. Right?

Let me know.

Thanks

[piersdeseilligny]

@viegasfh thanks! so I think I've got a bit of a better grasp on Sophocoles' "thread" concept. Essentially, it's just grouping scenes (especially synopses) together, under a single colour, right?

I've recently added the ability to toggle the visibility in the outline of scenes and sections (in addition to notes and threads), so you can have something like this:

.

What if it were possible to create threads in a separate panel, and then tag synopses with a given thread? (maybe scenes and notes too? although I think it might be better if it were only scenes, maybe even only synopses, in order to avoid potential ambiguities where a scene is tagged with one colour, but it's corresponding synopse is tagged with another).

It could look something like this:

You could link a synopse or scene to a given thread using the {{ }} syntax, so something along the lines of:

INT. CAFE - DAY
= in this scene, alice talks to bob in a cafe {{thread: "The love story"}}

The threads panel would then include a new thread called "The love story" (which could optionally list any synopse/scene tagged with it):

Up until now this is all possible, maybe not event that difficult to implement. The problem we now run into though, is how to change the colour of a given thread once it's been created. The easy way of getting around this would be to use a hashing function to automatically generate a colour from the thread's name, maybe even the same one which is used to highlight character names. However there will unavoidably be repeating colours if there's enough threads.

The other option would be to use what you suggest, and have a configuration area at the top of the document - but I'm worried it would then be too easy to accidentally corrupt it, and would be confusing for new users. Ideally, this part of the document would be hidden and made read-only, with it's values only being editable from the "Threads" panel. However I'm not entirely sure if that's possible with vscode's current APIs, and would actually be surprised if it was. I'd have to look into it more.

Am I missing something here, or do you think this is the right direction? Also I apologize if I'm a little slow to answer these days, I'm very busy with uni work and applying to jobs, etc... :/

[piersdeseilligny]

Oh and also, I think it's probably best if the colors are limited to a set of named options that the user can pick from, rather than requiring a specific hex code. It could be a similar approach to clips in DaVinci Resolve:
.

So the configuration could look something like:

{{threads:{"The love story": {color: navy}, "Obtaining an object": {color: apricot}}}}

(also, the thread names would not be case-sensitive)

Named colors would also make it easier to highlight threads in the background of the editor itself. This could either be done next to the line numbers, or by changing the background altogether:

[viegasfh]

Hi Piers,

You have grasped the concept pretty well. I like your idea of having a separate pannel for the threads, as it reflects how Sophocles works. Sophocles has a different pannel for threads. So, that is a great idea of yours. The same for the restriction in the colours we can choose. Perfect for me!

I think you are doing a great job on this and thank you very much for your effort in trying to make this possible. I have been using Sophocles for outlining as it allows me to keep track of each thread because of its colour. With this implemented in Betterfountain I will switch 100% to working on VS Code.

The way you are implementing it we can do something that allow us to extract reports of the stories seen in chronological order as well as movie order (or the way we write it to happen). By adding an order or position attribute in thread, we can know the sequence of the scenes (here highlighted by the synopsis). Each scene can have as many steps outlined by the synopsis, and they can be written out of order. However, we can always extract some report in chronological order. Here are two pdfs for the movie Casablanca that highlight this:

Step Order

Casablanca Step List.pdf

And Chronological order:

Casablanca Chronological Step List.pdf

But this is something we can do for future export options.

Betterfountain is coming along just fine. You are doing a great job!!!

As for not replying on time, don't worry I know how it is like when we devote our time voluntarily. We have other stuff to pay attention to. Whenever you have time. No rush.

Thanks once again. I'll wait until you have something working so that I can provide you feedback.