Minor FORMATTING issues (Better Fountain PDF generator)

[porosz23]

After installing Better Fountain and creating some test PDFs with its own PDF generator I found some minor formatting issues.

Then I opened Story Architect (Starc), imported the .fountain file (originally created in Visual Studio Code, with Better Fountain), and realised there may be even more differences, depending on the application used for generating the PDF.

Whenever a story is sold, it is very likely to be transferred into Final Draft at some stage of production, so I think the PDF generator of Better Fountain should neither be LESS permissive nor MORE permissive than that of Final Draft.

E.g. if this line is NOT centered in Final Draft:

A<UTHORIZED PERSONNEL ONLY!
...it should NOT be centered in Better Fountain, either (“<” should only work at the very end of a line).

Better Fountain should stick to the rules set forth by the creators of Fountain language itself, as specified at
https://fountain.io/syntax/

The differences I found are as follows:

Title page > Contact:

If I generate a PDF view, using the „Show PDF preview” button in Better Fountain, the VALUE of Contacts field is automatically placed to the bottom RIGHT but the industry standard is bottom LEFT.

---

According to
https://fountain.io/syntax/#transition

“...Power user: If a line matches the rules for Transition, but you want in interpreted as something else, you have two options:

1. Precede it with a period to force a Scene Heading,
   or
2. Add one or more spaces after the colon to cause the line to be interpreted as Action (since the line no longer ends with a colon)...”

OPTION 2 does not seem to work.

---

According to
https://fountain.io/syntax/#transition

“...The requirements for Transition elements are:

• Uppercase
• Preceded by and followed by an empty line
• Ending in TO:...”

Better Fountain’s PDF generator considers a line as a TRANSITION even if:

• only “TO:” is uppercase (e.g.: “Mike is going TO:”)
• NO empty line before / after it

---

In the PDF file, generated by Better Fountain, ALL the lines below are ALL CAPS and CENTERED.

AUTHORIZED PERSONNEL ONLY!<
AUTHORIZED PERSONNEL ONLY!<  (i.e. some spaces after ">")
AUTHORIZED PERSONNEL ONLY! < (i.e. some spaces before "<")
AUTHORIZED< PERSONNEL ONLY!
A<UTHORIZED PERSONNEL ONLY!

The last two are NOT centered in STARC, so should NOT be centered in Better Fountain, either.
(Unfortunately, currently I can’t afford to buy Final Draft to check the result there, the basic version of STARC is free.)

---

I’ve tested ALL possible combinations of INT. and EXT., i.e.:

1. est Los Angeles - NIGHT
2. est. Los Angeles - NIGHT
3. EST Los Angeles - NIGHT
4. EST. Los Angeles - NIGHT
5. int Los Angeles - NIGHT
6. int. Los Angeles - NIGHT
7. INT Los Angeles - NIGHT
8. INT. Los Angeles - NIGHT
9. ext Los Angeles - NIGHT
10. ext. Los Angeles - NIGHT
11. EXT Los Angeles - NIGHT
12. EXT. Los Angeles - NIGHT
13. int/ext Los Angeles - NIGHT
14. int./ext. Los Angeles - NIGHT
15. INT/EXT Los Angeles - NIGHT
16. INT./EXT. Los Angeles - NIGHT
17. i/e Los Angeles - NIGHT
18. i./e. Los Angeles - NIGHT
19. I/E Los Angeles - NIGHT
20. I./E. Los Angeles - NIGHT
21. ext/int Los Angeles - NIGHT
22. ext./int. Los Angeles - NIGHT
23. EXT/INT Los Angeles - NIGHT
24. EXT./INT. Los Angeles - NIGHT
25. e/i Los Angeles - NIGHT
26. e./i. Los Angeles - NIGHT
27. E/I Los Angeles - NIGHT
28. E./I. Los Angeles - NIGHT

(Okay, I know, 21-28 are not really used in practice)

According to https://fountain.io/syntax/#scene-headings (...and we just know it):
“.A Scene Heading is any line that has a blank line following it, and ... always has at least one blank line preceding it.”

At first I tested the above lines WITHOUT blank lines around them:

The ones that are NOT considered as a SCENE HEADING (i.e. NOT aligned LEFT, with ALL CAPS) are:

• In a PDF generated by BETTER FOUNTAIN: 21, 23, 25, 26, 27, 28 (NONE of them should be, as there are NO blank lines!)
• In a PDF generated by STARC: all (= none of them are regarded a SCENE HEADING)

Then I tested the above lines WITH blank lines around them:

The ones that are NOT considered as a SCENE HEADING (i.e. NOT aligned LEFT, with ALL CAPS) are:

• In a PDF generated by BETTER FOUNTAIN: 21, 23, 25, 26, 27, 28
• In a PDF generated by STARC: 1, 2, 5, 6, 9, 10, 13, 14, 17, 18, 20, 21, 22, 25, 26, 27, 28

Maybe Better Fountain should

• either stick to the rules mentioned at https://fountain.io/syntax/#scene-headings,
• or should accept all formats that are also accepted by Final Draft.

---

According to the CHARACTER chapter of https://fountain.io/syntax :
A Character element is any line entirely in uppercase, >>>with one empty line before it<<<…

At first I tested the lines below with NO blank line before “JOHN”:

INT. NEW YORK - NIGHT
JOHN
Wait, please!

• In a PDF generated by BETTER FOUNTAIN:
  These lines are considered a SCENE HEADING + a CHARACTER HEADING + a DIALOGUE

• In a PDF generated by STARC:
  The first line is considered a CHARACTER HEADING, the rest is DIALOGUE

Then I tested the above lines WITH a blank line before “JOHN”, and the formatting in STARC was fine.
Conclusion:
Again, Better Fountain should stick to the rules of Fountain, i.e. require a blank line.
Without one, it should not colour the first two line as CHARACTER HEADING + a DIALOGUE.

---

According to https://fountain.io/syntax/#emphasis :

“...the spaces around the emphasis characters are meaningful. In this example, the asterisks would >>>not<<< trigger italics between them, because both have a space to the left:

He dialed *69 and then *23, and then hung up...”

In a PDF generated by BETTER FOUNTAIN this is still italicized (anything written after the OPENING * is italicized).
The same applies to BOLD and UNDERSCORE.

---

ESCAPING special characters:

Example:
If we want italicized text, we need an OPENING * and a CLOSING *

According to https://fountain.io/syntax/#emphasis , if we DO NOT WANT the text to be italicized, but want to include the asterisks in the text instead, escaping ONE OF THEM is enough:

“...The writer would need to escape >>>one<<< or both of the asterisks to avoid the accidental italics:

He dialed *69 and then 23*, and then hung up...”

In a PDF generated by BETTER FOUNTAIN this is still italicized (anything written after the OPENING * is italicized).
The same applies to BOLD and UNDERSCORE.

---

According to https://fountain.io/syntax/#emphasis :

“...emphasis is >>>not<<< carried across line breaks. So there are no italics in the formatted output of this example–just asterisks:

As he rattles off the long list, Brick and Steel *share a look.

This is going to be BAD.*…”

In a PDF generated by BETTER FOUNTAIN this is still italicized (anything written after the OPENING * is italicized).
The same applies to BOLD and UNDERSCORE.

---

Issue Nr. “10” is only here to please Adrian Monk.

[porosz23]

...please note all the lines that read ">A<UTHORIZED PERSONNEL ONLY!" start with a ">" character, but github made them disappear from the above report.

[porosz23]

...I found one more thing:
When I use the "boneyard" function (https://fountain.io/syntax/#boneyard), there's a blank section on the PDF, i.e. a lot of blank lines represent the hidden lines.
I don't think that's how boneyard should work.
If I temporarily omit, say, SCENE 2, it should mean SCENE 1 is followed directly by SCENE 3, with no empty space between them.

[porosz23]

...and two more:

According to https://fountain.io/syntax/#notes , notes that should be VISIBLE on the PDF version, e.g.:
[NOTE - from here out Roberto speaks Italian.]
...are written this way:
[[NOTE - from here out Roberto speaks Italian.]]

That does not work that way.

• if I use SINGLE brackets, it creates a VISIBLE note on the PDF (it should not)
• if I use DOUBLE brackets, it creates an INVISIBLE note on the PDF (it should be visible)

---

According to https://fountain.io/syntax/#line-breaks
if I want something like this:

DEALER
Ten.
Four.
Dealer gets a seven.

Hit or stand sir?

...i.e. an EMPTY LINE inside a dialogue (unconventional but may be useful), I have to do this:

"...if you want to do the unconventional thing of leaving white space in dialogue ... You would need to type two spaces..."

Well, it ALMOST works properly:
adding two spaces DOES mean the line that follows is still considered part of the dialogue, but THE EMPTY LINE IS NOT KEPT (it should be, otherwise I have no reason to "fight for it").

[porosz23]

One more thing:

I've installed a Lakota dictionary app:
Google Play
https://play.google.com/store/apps/details?id=com.lingea.handylex.lkenh1&hl=en
Apple store:
https://apps.apple.com/us/app/new-lakota-dictionary-mobile/id959701704

They use eleven special characters: ǧ-ž-č-š-ŋ-ȟ-á-é-í-ó-ú
...see a screenshot of the app here:
https://play-lh.googleusercontent.com/XPEIrIuSzSSqxzHIW5LzG3vlrTC-kN2HhGm-1bG9dib3bd7kj-s41DbhFuQLtYndQ9yy=w2560-h1440-rw
...and they can also be copied from here:
https://en.wikipedia.org/wiki/Lakota_language

I created a test file in Better Fountain, using all of the above characters.

• The PDF generator of Better Fountain displays a SPACE on the PDF file where I see “ǧ“, “ȟ” or “ŋ” in Visual Studio Code.

After importing the .fountain file into Story Architect and WriterSolo:

• The PDF generator of Story Architect, as well as that of and WriterSolo IS ABLE TO display those special characters.

So Fountain language can handle / keep them, but the PDF generator of Better Fountain loses them.

Okay, I know, there are just too many languages in the world, with a bunch of “weird” characters, and making Better Fountain available for Lakota screenwriters may not be Priority #1, but if other applications can handle such special characters, adding “ǧ“, “ȟ” and “ŋ” may be useful.

[piersdeseilligny]

Thanks for all of this feedback! There's some really useful points in there.

Few things to note: the language/font issue has come up a few times, unfortunately it has to do with the library that's used for generating the PDFs and not a lot can be done about it, other than use a different font: #133

Some of these bugs/discrepancies are probably best to leave as-is, as to not disrupt the formatting of people who've already written scripts while unintentionally relying on them, but others should 100% be fixed.

You've highlighted quite a few issues which is really helpful, but i'il have a proper look through all of this when i've got a bit more time (which may not be for a while, but please feel free to submit any PRs too!).