Another format that's going to appear in the next Fountain Flow for Vim, one way or another. This one's especially difficult to work out a path to LibreOffice, because of the image handling.
In addition to the main picture, there should be a variety of graphics to draw on within the text areas... arrows and other various symbols.
Of course you'll need some sort of drawing app to produce the actual drawings. The storyboard presented here is an adaptation of a chapter from a manga called Watashi ga Motenai no wa Dō Kangaetemo Omaera ga Warui! or WataMote, for short.
As with the index card format, the syntax isn't yet etched in stone, and in fact would better be described as in the experimental phase.
vimwriter
Creative writing with vim power
Thursday, November 26, 2015
Wednesday, November 25, 2015
Index cards with Fountain Flow for Vim
The next version of Fountain Flow for Vim will accept many additional formats. This index card layout should be useful for writers, although so far I've only worked out a fairly simple layout. Converting plain text markup to HTML, the index board can go forever, horizontally or vertically. Each new section or row is divided by a new header. This could be separate characters, or different acts or chapters.
What this doesn't yet possess is some way of coordinating the rows, or stacking cards. First, how would that more advanced layout be reflected in plain text? Then, how would it be implemented in the visual form?
Until those more advanced issues are addressed, the text markup can be very simple, although I'd say the form shown here is open to change. For instance, the equals sign on the second line is superflous, if the card content always stays on one line -- and this, to me, seems like a very good idea, from an organizational standpoint, because then it will be easier to reorder the "cards" through tools provided by an upcoming supplemental script, particularly one that lets you hit arrow buttons to smoothly move blocks of text through the document.
Friday, November 20, 2015
Expanding Fountain Flow
Basically Fountain Flow is a text markup processor for Vim, and the markup of choice is Fountain syntax for screenplays.
I had an idea to alter this somewhat and make a Fiction Flow processor, for shaking down Markdown-style text into an ebook-ready document. I got as far as testing an early version, when it occurred to me -- why am I doing this all over again? After all, Fountain itself is simply an extension of simpler markup, particularly Markdown. So instead of creating separate scripts that duplicate much of the same code, it seems to make sense to have the Flow script apply extensions conditionally.
By processing the core markup the same, and the extensions conditionally, Fountain Flow could easily support not just traditional screenplays, but teleplays, A/V scripts, and stage plays, as well as short stories and novels. Even storyboards could be supported under this scheme. The advantage of this, of course, is that the core work is done within Vim instead of a bloated word processor.
One way the format could be defined is through the title page block. One line could simply say, for example, "Format: screenplay". Since a given work is either a screenplay or it isn't, hardcoding the format name into the document seems a more sensible option than having to metaphorically pull a lever for screenplay every time you process a revision of a screenplay, while at the same time allowing for easy switching when a different format is required. A story submission and an ebook would both draw from the same basic markup syntax, but changing the line from "Format: short story" to "Format: ebook" would alter the presentation of that same core document.
This will require a little more discipline with the support files. Instead of loose templates and stylesheets, there should be a theme file that contains all the necessary data. Some of these would have to come in different flavors--there is more than one way, for instance, to format an ebook.
I've had too many sick days lately, but hopefully I'll charge forward on the changes now. I hope those folks who have downloaded this and tried it out are happy with it so far.
I had an idea to alter this somewhat and make a Fiction Flow processor, for shaking down Markdown-style text into an ebook-ready document. I got as far as testing an early version, when it occurred to me -- why am I doing this all over again? After all, Fountain itself is simply an extension of simpler markup, particularly Markdown. So instead of creating separate scripts that duplicate much of the same code, it seems to make sense to have the Flow script apply extensions conditionally.
By processing the core markup the same, and the extensions conditionally, Fountain Flow could easily support not just traditional screenplays, but teleplays, A/V scripts, and stage plays, as well as short stories and novels. Even storyboards could be supported under this scheme. The advantage of this, of course, is that the core work is done within Vim instead of a bloated word processor.
One way the format could be defined is through the title page block. One line could simply say, for example, "Format: screenplay". Since a given work is either a screenplay or it isn't, hardcoding the format name into the document seems a more sensible option than having to metaphorically pull a lever for screenplay every time you process a revision of a screenplay, while at the same time allowing for easy switching when a different format is required. A story submission and an ebook would both draw from the same basic markup syntax, but changing the line from "Format: short story" to "Format: ebook" would alter the presentation of that same core document.
This will require a little more discipline with the support files. Instead of loose templates and stylesheets, there should be a theme file that contains all the necessary data. Some of these would have to come in different flavors--there is more than one way, for instance, to format an ebook.
I've had too many sick days lately, but hopefully I'll charge forward on the changes now. I hope those folks who have downloaded this and tried it out are happy with it so far.
Thursday, November 12, 2015
Page numbering with Fountain Flow
In a moment, we're going to take you through the process of setting up proper page numbering for your screenplay. The concept itself is actually pretty easy to grasp, but it's still a pain to have to go through all the steps, which is why Fountain Flow provides you with a couple of handy templates. These templates are NOT for importing styles. They are strictly for setting up the page numbering.
After you've processed your Fountain file to HTML, and hit 'enter' to send it on to LibreOffice, go to Styles and Formatting and click on the paragraph icon in the top right corner to open a few selections. You want Load Styles...
If you've already installed the templates, just select the one that matches your project, and then click the fields shown above: Numbering, Pages, and Overwrite. Click OK and you've got page numbers. Done!
If you haven't bothered loading the templates, click the bottom left button From File... and navigate to the ODF copies that we provided along with the templates. The result will be the same.
Sometimes your project may require a different arrangement, a different number of intro pages. For those circumstances, you'll have to start from scratch, so I'll go through the entire procedure, here. If it's a circumstance that you think you'll repeat, then remember the above instructions on copying over the page numbering.
So here we go.
LibreOffice has an easy solution if you want your page numbering to start after the first page. You simply call the first page "First Page". Headers are page-style dependent, so when you turn the headers on for the rest of the document, your first page, likely your title page, will be left alone.
The "First Page" page style is in LibreOffice's styles by default, and Fountain Flow invokes that for you automatically.
However, most of the time your screenplay will include a title page ahead of your script, and you don't want page numbering on the first page of your script, either. So technically, you want to start page numbers on page three, starting with "2".
If you include another page of material, like a synopsis page, that bumps the page numbering back even further.
But don't despair! The technique for arranging your page numbers in a situation like this is easier than it looks. All you have to remember is to "put one foot in front of the other, and then you'll be walkin' cross the floo--oo--oor! You put one foot in front of the other, and then you'll be walkin' out the door!"
"First Page" is already defined for you. What you want to do about the first page of the actual script--the first page that should not have a page number, is to create a new style called "First Script Page", or something like that.
Don't create it from scratch. First, look for the default style of the rest of the document. Since Fountain Flow began the conversion process with HTML, the default page style will be "HTML". Select that with one click, then move up to the top right corner, and click on the 'paragraph' icon and find the option New Style from Selection.
After you've processed your Fountain file to HTML, and hit 'enter' to send it on to LibreOffice, go to Styles and Formatting and click on the paragraph icon in the top right corner to open a few selections. You want Load Styles...
If you've already installed the templates, just select the one that matches your project, and then click the fields shown above: Numbering, Pages, and Overwrite. Click OK and you've got page numbers. Done!
If you haven't bothered loading the templates, click the bottom left button From File... and navigate to the ODF copies that we provided along with the templates. The result will be the same.
Sometimes your project may require a different arrangement, a different number of intro pages. For those circumstances, you'll have to start from scratch, so I'll go through the entire procedure, here. If it's a circumstance that you think you'll repeat, then remember the above instructions on copying over the page numbering.
So here we go.
LibreOffice has an easy solution if you want your page numbering to start after the first page. You simply call the first page "First Page". Headers are page-style dependent, so when you turn the headers on for the rest of the document, your first page, likely your title page, will be left alone.
The "First Page" page style is in LibreOffice's styles by default, and Fountain Flow invokes that for you automatically.
However, most of the time your screenplay will include a title page ahead of your script, and you don't want page numbering on the first page of your script, either. So technically, you want to start page numbers on page three, starting with "2".
If you include another page of material, like a synopsis page, that bumps the page numbering back even further.
But don't despair! The technique for arranging your page numbers in a situation like this is easier than it looks. All you have to remember is to "put one foot in front of the other, and then you'll be walkin' cross the floo--oo--oor! You put one foot in front of the other, and then you'll be walkin' out the door!"
"First Page" is already defined for you. What you want to do about the first page of the actual script--the first page that should not have a page number, is to create a new style called "First Script Page", or something like that.
Don't create it from scratch. First, look for the default style of the rest of the document. Since Fountain Flow began the conversion process with HTML, the default page style will be "HTML". Select that with one click, then move up to the top right corner, and click on the 'paragraph' icon and find the option New Style from Selection.
Our new formatting goal: 56 lines per page
There is apparently an optimal number of lines per screenplay page. I'm sure we can do it.
Looking at the Fountain Flow output of Big Fish, I count about 50 lines. It just wants a tiny bit of tightening.
Looking at the Fountain Flow output of Big Fish, I count about 50 lines. It just wants a tiny bit of tightening.
Wednesday, November 11, 2015
How title page data works in Fountain Flow
Fountain syntax specifies that title page data is defined optionally at the top of the page, as key: value
For example...
Title: WHAM BAM BOOM!
Credit: Written by
Author: Rodney Faxwallow
Favorite beverage: coffee
Anything can be a key. Also, you don't have to stick to just one line. As the Fountain website shows, key: value can span lines.
Contact:
The Faerie Workshop
Little Tree Stump
Grambling Meadows, MI
Fountain Flow turns all of this data into a list, and keeps track of line breaks within the data so that contact info up there, when it gets inserted, will appear just as intended.
But just because your data becomes part of a list doesn't mean it will automatically join the rest of the data on the title page. Your title page template will have to include a marker for the data you want, where you want it.
If you already have Fountain Flow installed, and pointed to the right folder, you can go to Vim and type the command :FlowDirectory to open up the templates. Open up the title page template, and you'll find lines like these.
<p class="Title">%Title%</p>
<p class="Author">%Credit% %Author%</p>
<p class="Source">%Source%</p>
As you can see, the marker matches the actual key, bracketed by %%. The only thing that drops out are spaces. So a key like Draft date: requires the marker %Draftdate%.
In the sample above, the CSS class styles match, too, but that's not important. That's just meant for precise styling, and will have no impact on the data delivery.
If a marker is orphaned (no data) it will simply be scrubbed.
THOUGHT: This would stray outside Fountain syntax, but perhaps some extra marker could be included to specify the target region of the page for each item. This would simplify the title page template significantly, and eliminate the need to edit the template on a script-by-script basis.
So let's say you have a title page with three regions: region A is the top centered section, while B and C are two columns below, one flush left, and the other flush right.
Instead of just key: value, the source file could specify key: value [[region]], for example. Then Fountain Flow could add that data to the specified region, in the order listed. The title page template would only have to specify the names and positions of the regions.
It's a thought, anyway.
For example...
Title: WHAM BAM BOOM!
Credit: Written by
Author: Rodney Faxwallow
Favorite beverage: coffee
Anything can be a key. Also, you don't have to stick to just one line. As the Fountain website shows, key: value can span lines.
Contact:
The Faerie Workshop
Little Tree Stump
Grambling Meadows, MI
Fountain Flow turns all of this data into a list, and keeps track of line breaks within the data so that contact info up there, when it gets inserted, will appear just as intended.
But just because your data becomes part of a list doesn't mean it will automatically join the rest of the data on the title page. Your title page template will have to include a marker for the data you want, where you want it.
If you already have Fountain Flow installed, and pointed to the right folder, you can go to Vim and type the command :FlowDirectory to open up the templates. Open up the title page template, and you'll find lines like these.
<p class="Title">%Title%</p>
<p class="Author">%Credit% %Author%</p>
<p class="Source">%Source%</p>
As you can see, the marker matches the actual key, bracketed by %%. The only thing that drops out are spaces. So a key like Draft date: requires the marker %Draftdate%.
In the sample above, the CSS class styles match, too, but that's not important. That's just meant for precise styling, and will have no impact on the data delivery.
If a marker is orphaned (no data) it will simply be scrubbed.
THOUGHT: This would stray outside Fountain syntax, but perhaps some extra marker could be included to specify the target region of the page for each item. This would simplify the title page template significantly, and eliminate the need to edit the template on a script-by-script basis.
So let's say you have a title page with three regions: region A is the top centered section, while B and C are two columns below, one flush left, and the other flush right.
Instead of just key: value, the source file could specify key: value [[region]], for example. Then Fountain Flow could add that data to the specified region, in the order listed. The title page template would only have to specify the names and positions of the regions.
It's a thought, anyway.
Changes for the next Fountain Flow
While reviewing the revision of the Fountain syntax file, I caught a small error with Fountain Flow. The title page material that I've treated as mandatory is supposed to be optional, so I need to fix the script so that it will just toss out the title page template altogether if there is no title page requested. Currently, the screenplay will format correctly, but you'll get error messages.
Similarly, I'm updating the syntax so that it will know if the top lines are title page material, or the script. Anything without a colon can be ruled out, of course, and if the top line is a synopsis it might have a colon, but we can disqualify it because it begins with the equal sign. Trying to think of what other situations might cause confusion. Perhaps if the first line is all caps, it can be disqualified. For instance, you might have a title in all caps, but the 'key' would not be:
Title: WHAM BAM BOOM!
So we know that's normal title page data. But if the first line is a character that just happens to include a colon, we'll know it's not title page data.
RE:SCAN
(seething)
What a gimmicky name I've got!
A character line that contains a colon and lowercase letters would have to begin with the 'at' sign, and so that can be automatically disqualified along with the synopsis line.
If the first line is a normal action line that contains a colon, it may be harder for the script to distinguish that from title page data.
As the girl runs: a truck takes a sharp turn and tips over, crashing into the corner building.
Disqualifying it on length would be awkward. Contact data might include a lengthy address. Of course, the writer could simply use a comma, but I'd rather have the script watch out for the user, instead of the user having to watch out for the script.
I'll just have to figure out something.
Anyway, second issue: I find that I still have managed to miss supporting some Fountain syntax, after all. SCENE NUMBERS are not supported, but I'll get that in there ASAP.
Similarly, I'm updating the syntax so that it will know if the top lines are title page material, or the script. Anything without a colon can be ruled out, of course, and if the top line is a synopsis it might have a colon, but we can disqualify it because it begins with the equal sign. Trying to think of what other situations might cause confusion. Perhaps if the first line is all caps, it can be disqualified. For instance, you might have a title in all caps, but the 'key' would not be:
Title: WHAM BAM BOOM!
So we know that's normal title page data. But if the first line is a character that just happens to include a colon, we'll know it's not title page data.
RE:SCAN
(seething)
What a gimmicky name I've got!
A character line that contains a colon and lowercase letters would have to begin with the 'at' sign, and so that can be automatically disqualified along with the synopsis line.
If the first line is a normal action line that contains a colon, it may be harder for the script to distinguish that from title page data.
As the girl runs: a truck takes a sharp turn and tips over, crashing into the corner building.
Disqualifying it on length would be awkward. Contact data might include a lengthy address. Of course, the writer could simply use a comma, but I'd rather have the script watch out for the user, instead of the user having to watch out for the script.
I'll just have to figure out something.
Anyway, second issue: I find that I still have managed to miss supporting some Fountain syntax, after all. SCENE NUMBERS are not supported, but I'll get that in there ASAP.
Subscribe to:
Posts (Atom)