eprovst/wrap

A Fountain export tool with some extras...

Wrap

NOTE: This program is currently not actively maintained, it seems to work fine, but use at your own risk.

A Fountain/Wrap export tool, with some extras...

Overview

Wrap is an open source command line tool that is able to convert Fountain and Wrap files into a correctly formatted screen- or stageplay as an HTML or a PDF.

Fountain is an awesome format to write screenplays in English, Wrap builds upon this to add support for different languages and stageplays whilst still fully supporting normal Fountain files.

All this in a FOSS package that you can use straight from the commandline.

Installation

NOTE: This program is currently not actively maintained, it seems to work fine, but use at your own risk.

Wrap is available on Windows, macOS and most major Linux distributions.
Download the latest release.

Experience any issues?

Most common issues are listed in the FAQ and on the wiki.

If you suspect it's a bug or have any suggestions: visit the issues page.

wrap's Issues

Replace %/ with %!

Description

Currently one can force End of act using %/, selecting this sequence has been done without much thought. Looking at other elements of this type in the Fountain and Feltix specs it would be more elegant to use %!. As the project hasn't yet been released for a long time we can make this change with an extraordinary low chance of braking anything.

Do note that this is best hotfixed, the next release might take some time...

newline-indented keys support in title page

The following title page layout format works:
Title: "TITLE"

This doesn't:

Title:
  "TITLE"

--where there are either space or tab indents for "TITLE."

Notes produce newlines when they shouldn't

Notes on their own line...

[[foo]]

...are invisible in the output (as expected), but produce a newline. This leads to inconsistent formating and is very likely not the way this was meant to work.

To Reproduce

Steps to reproduce the behavior:

1. Create a scene Header
2. Write ten lines of [[ foo ]]
3. Write some normal scene text
4. Convert to pdf via wrap pdf -p --use-courier-prime {infile} -o {outfile}

INT. OFFICE - DAY #1#
= Scene summary

[[foo]]
[[foo]]
[[foo]]
[[foo]]
[[foo]]
[[foo]]
[[foo]]
[[foo]]
[[foo]]
[[foo]]

Something weird happened

Expected behavior

Notes shouldn't produce newlines if they are not visible

Screenshots

Resulting PDF looks like this ↓

↑ These newlines are gone if you remove the lines with [[foo]] and correspond to the number of notes

Version

• Wrap: v0.2.3
• OS: Ubuntu 18.04

Additional Info
A quickfix for me is to preprocess the fountain and remove all lines that only contain a note, but it would be better to have it fixed in wrap.
Edit: Here is what I used:

wrap pdf -p --use-courier-prime <(sed -n '/^\[\[.*\]\]$/!p' ./script.fountain) -o script.pdf

Add a test suite for the parser

There have been too many bugs found in the parser and most of this can be attributed to a lack of thorough testing. The parser is the foundation of everything Wrap does, getting this as close to correct as possible is vital to the usability of Wrap.

Courier New fallback only works for bold font

When using Courier New fallback on Windows (and possibly macOS) the resullt is mostly transparent...

panic: index out of range error with underscore, full stop, eol

Describe the bug

Wrap will error trying to generate a PDF if the input Fountain file contains a line ending with _.

To Reproduce

Steps to reproduce the behavior:

1. wrap pdf INPUT.fountain
2. See error

Given the following example:

Clark's other hand. He loosens his grip. _Lets go of the rope_.

Command wrap pdf INPUT.fountain results in the following:

panic: runtime error: index out of range [-1]

goroutine 1 [running]:
github.com/Wraparound/wrap/pdf.wordwrap(0xc00005c4e0, 0x3, 0x4, 0x2, 0x11e3f
6b, 0xc000020240, 0x128a33d)
        /home/elecprog/Development/wrap/pdf/wordwrap.go:53 +0xb16
github.com/Wraparound/wrap/pdf.cellify(0xc00000c380, 0x1, 0x1, 0xc000020502,
 0x128a33d, 0x7, 0x3)
        /home/elecprog/Development/wrap/pdf/cellifying.go:44 +0xc9
github.com/Wraparound/wrap/pdf.sectionize(0x12d8880, 0xc00000c3a0, 0x0, 0x0,
 0x0, 0x0, 0x0)
        /home/elecprog/Development/wrap/pdf/sectionize.go:27 +0x1a7f
github.com/Wraparound/wrap/pdf.buildPDF(0xc000010bd0, 0x10a9f66, 0x5e1ada94,
 0xc02c6280c8)
        /home/elecprog/Development/wrap/pdf/pdf.go:104 +0x53a
github.com/Wraparound/wrap/pdf.WritePDF(0xc000010bd0, 0x12d8140, 0xc00002020
0, 0xc0000da000, 0xc00000e0d8)
        /home/elecprog/Development/wrap/pdf/files.go:35 +0x2b
github.com/Wraparound/wrap/cli.export(0xc0000508e0, 0x1, 0x1, 0x1289937, 0x3
, 0x12999b0)
        /home/elecprog/Development/wrap/cli/export.go:62 +0x276
github.com/Wraparound/wrap/cli.pdfRun(0x1466cc0, 0xc0000508e0, 0x1, 0x1)
        /home/elecprog/Development/wrap/cli/pdf.go:88 +0x3c5
github.com/spf13/cobra.(*Command).execute(0x1466cc0, 0xc0000508b0, 0x1, 0x1,
 0x1466cc0, 0xc0000508b0)
        /home/elecprog/go/pkg/mod/github.com/spf13/[email protected]/command.go:7
66 +0x2aa
github.com/spf13/cobra.(*Command).ExecuteC(0x1466f20, 0xc000042750, 0xc00007
af50, 0x100535f)
        /home/elecprog/go/pkg/mod/github.com/spf13/[email protected]/command.go:8
52 +0x2ea
github.com/spf13/cobra.(*Command).Execute(...)
        /home/elecprog/go/pkg/mod/github.com/spf13/[email protected]/command.go:8
00
main.main()
        /home/elecprog/Development/wrap/wrap.go:15 +0x31

Expected behavior

PDF output generated.

Version

• Wrap: Wrap v0.3.0 on Darwin
• OS: macOS 10.15.2 (19C57)

Additional context

The error can be worked around by switching the underscore and full stop, i.e.

_Lets go of the rope._

However, I tend to write it the other way around, for aesthetic considerations.

Request option: turn off PDF hyphenation

Is your feature request related to a problem? Please describe.

Hyphenations are usually undesirable in a screenplay (as near as I can determine), and seem to be applied to monosyllabic words.

Describe the solution you'd like

Command line flag for PDF to disable word breaking/hyphenation

Describe alternatives you've considered

I can't debug the code myself.

Additional context

none

Update the wiki's instructions to install with Go

Is your feature request related to a problem? Please describe.

The wiki page Installing elsewhere has outdated instructions for installing Wrap with go get or go install. These either silently fail or complain that there are no go files in the directory.

Describe the solution you'd like

After some fiddling - I have no experience with Go - I found that the following works:

go get -u github.com/Wraparound/wrap/cmd/wrap

or in a local copy of the repository:

go install ./cmd/wrap

Either will install Wrap in GOPATH, which usually means $HOME/go/bin.

Describe alternatives you've considered

Obviously, Snap also works, but some distros ship with flatpak instead, and it feels wasteful to have both. Many Linux users like to build from source, and these commands do the trick really quickly (if you don't count the hour I spent wondering why go install didn't work :D)

Change project name to Wraparound

Description

Although never intended, Feltix as a name is rather similar to Celtx and might cause confusion...
Wraparound (a play on "that's a wrap" a common phrase at the end of the last production day) is neutral, unused by other software.

This also allows us to keep the name of the tool and organisation separate. The tool and file format will become "Wrap".

• Rework assets and site
• Restructure code and distribution

Arbitrary font support

I would like to load and use arbitrary fonts (and I'd like a switch to do that).

There are courier variant fonts I would use other than those supplied.

Compare Drafts

Fountain is great for first drafts, but struggles when producers ask for additional drafts with revision marks.

I’d love a feature which allows you to compare two fountain files and export a PDF with revision marks (asterisks) to highlight the differences.

Add file type icons

We support two file types: Wrap and Fountain, however once file types are useful a user expects it to have an icon.

Note: It is currently rather difficult to add file type icons to a snap package, file type icons on Linux are thus currently postponed.

• Design icons for Wrap and Fountain, done thanks to the amazing work of @jschopplich.
• Add the icons to the install process on macOS.
• Add the icons to the install process on Windows.

Improve word wrap

The current word wrap algorithm works for most cases, however it's fairly clunky code and in some very rare cases it inserts a hyphen where it probably shouldn't or does something else weird.

Pdf generation

I have a website where I want to generate a pdf based on fountain data.

Is there an easy way to port the pdf generation to JavaScript i.e understand the logic?

Alternatively, is it easy to make a web assembly version of the pdf package?

Avoid breaking "--" across lines

Is your feature request related to a problem? Please describe.

This is not a problem, more of an ideal-world feature. I like to frequently use -- in my scripts for an em dash, e.g.

McGarnagle pulls open the safe door -- draws his revolver --

Empty.

Every so often, this gets split across a line, which I find unattractive. This is not an issue specific to Wrap; I've found this happens with most/all screenplay programs.

Describe the solution you'd like

The string -- could be treated as word-constituent, that is, not break across lines.

Describe alternatives you've considered

Using a non-breaking hyphen (U+2011) for the first character. This requires a fair bit of fiddling when writing and is not ideal.

Additional context

If you were to accept this feature, it may prove more complex than just what I've suggested, e.g. an edge-case I can think of is what if some weirdo likes to write:

McGarnagle pulls open the safe door--draws his revolver--

In this case, I'm not sure if it means door--draws should be treated as three separate words.

One approach would be to just treat the hyphen - character as word-constituent, but then this would mean hyphenated words would cease to break across lines, which is probably not ideal.

Rework website

Description

The website's internals are a mess, as it is hosted on Github Pages we could think about using Jekyll.
The website should also highlight more of the unique features of Wrap (eg. multilanguage) and the speed (eg. Big Fish to HTML in about 18 ms).

Work to do

• Move to Jekyll
• Rework content

Font fall back

When no Courier Prime available we should fall back on Courier New on Windows and macOS.

Add Notes.

First of all, I've just discovered your program, really like it. I wanted to give a suggestion though. When I write I like to add a lot of notes to my scenes (how it's shot since fountain does not include syntax for shots, the music I use, ...). Any plans on adding note support in the future?

Limit bash autocompletion to valid file types

Description

Currently bash autocompletion on Linux doesn't know the difference between output and input.

Better language support

Description

One of the main reasons the Wrap extensions came to be was to better support scripts in different languages. However this has little effect when only three are supported: English, French and Dutch.

Of course different languages have different cultures and have different needs, however those where the screen- and stageplay tradition isn't too different from the Anglo-Saxon and Western-European world should be as much as possible be supported by the software.

Current translations and languages can be found here.

How can I help?

If you're able to provide translations of the following, you may comment them here and they (when correct) can be added to the program:

• Scene tag: 'Scene'

• Transition tag: 'TO:'

• Act tag: 'ACT'

• End of act tag: 'END OF ACT'
   

• More tag: '(MORE)'

• cont'd tag: '(CONT'D)'
   

• Scene headings: 'INT.', 'EXT.', 'INT./EXT.', 'I/E' and 'EST.' (establishing).

If you are able to provide any extra notes on any peculiarities of your language, errors in current translations and/or possible aliases for the language metadata (eg. the name of your language in the language itself, etc.) these would also be most welcome.

Languages to be/already added

Note: these reflect the state of the Wrap Languages module, not the current release of Wrap.

• English
• French (might need correcting, slightly incomplete)
• Dutch
• German
• Italian
• More to come...

Improve distribution

This would greatly improve user experience:

• Distribute on Linux using snap
• Basic Windows installer
• Windows MSI (blocked upstream)
• Distribute as application bundle for macOS
• macOS DMG file

Support different page sizes

First, in case I’ve not mentioned it, I really appreciate you building Wrap and putting your time/energy into the Fountain ecosystem. Thank you.

Is your feature request related to a problem? Please describe.

Not really, except perhaps not being able to specify page size.

Describe the solution you'd like

There are slight variations in how people may like to format their scripts; generally I’d say these are limited to: page size (a4 vs. US letter), whether dialogue breaks across pages, and whether scene headings are double-spaced, bold, and/or underlined. I’d like to be able to configure these via command line switches. There are probably others variations people wish for (e.g. #29 ) but I’d say these are the main ones.

Describe alternatives you've considered

Currently I use afterwriting, but I think multiple implementations are a very positive thing.

Additional context

I maintain an Emacs mode for Fountain editing. Currently it has internal export functionality, but I would prefer to remove this in favour of external CLI tools such as Wrap. Being able to specify export formatting via command switches makes for a pretty seamless user interaction, e.g. here’s a screenshot of how a user configures different export profiles in Emacs:

If one title page element doesn't render, subsequent ones don't either

Re: #27
With the following fountain title page keys and values, "by" doesn't render, and neither does "Keaton Patti:"

Title: "OLIVE GARDEN FAKE AD"
Credit: by
Author: Keaton Patti

Command line flag to toggle page numbers

Is your feature request related to a problem? Please describe.

There are scenarios where it may be preferable not to include page numbers in the PDF instead of including incorrect page numbers, e.g. when exporting a subset of scenes/pages to replace outdated pages.

Describe the solution you'd like

The addition of a command line boolean flag to toggle page numbers e.g.

$ wrap pdf My-Screenplay.fountain --no-page-numbers

Describe alternatives you've considered

I think the main alternative is afterwriting CLI , which uses the format:

$ afterwriting [FLAGS] --setting show_page_numbers=false

Additional context

The prospect of exporting replacement pages from Fountain implies the notion of page-locking, something which Fountain is supposedly incapable of achieving. Some years ago I suggested a small extension of the page break specification to enable "forced page numbers", which, in theory, would allow page locking. The thread is here: https://groups.google.com/g/fountain-dev/c/W_cAivCNhIk

Although the suggestion was well received, it was never implemented, and the development of the Fountain specification seems to have then fragmented between Fountain 1.1 and the (now quite separate) Highland format.

So page-locking remains in a kind of limbo.

Bash autocompletion

Description

For the Linux build bash autocompletion for subcommands should be included.
This is unfortunately not supported on macOS and Windows.

Work to be done

• Switch to CLI library that supports autogeneration of bashcompletion.
• (Auto)generate completion files on build.
• Include in snapcraft build config.

Title page values that are two or less characters do not render

If I set up the title page this way:

Title: "OLIVE GARDEN FAKE AD"
Credit: by
Author: Keaton Patti

-- it does not render the "Credit:" value, "by." Any other three-character word renders. It seems that if I provide any value of two or less characters for any key, it skips render.

I would prefer if null values (no characters) caused it to skip rendering the key value instead.

Generating a PDF on macOS: "Warning: no Courier Prime installed"

Describe the bug

I installed Wrap and it is working to generate PDFs from Fountain files. I also have Courier Prime installed. However, when I generate the PDF, I get "Warning: no Courier Prime installed"

Does Courier Prime need to be added to the contents of the Mac app? I didn't see this mentioned in the installation Wiki, but I might have missed it.

To Reproduce

Steps to reproduce the behavior:

1. Run wrap pdf test.fountain
2. Get PDF produced using Courier New, and "Warning: no Courier Prime installed"

Expected behavior

Courier Prime is used to generate the PDF.

Screenshots

Version

• Wrap: v0.3.1
• OS: macOS 11.5.2

Add piping support

The CLI has been put together quite hastily early on in development and it could use some redesign, removing the out flag in favour of using redirection of the standard output is more elegant and fits in with the added support of piping planned for v0.1.6.

Improve user interaction

Description

However useful cli tools are they are sometimes a little strange to users and slightly hard to reach from a normal file explorer, we could do the following to make interaction easier:

Add a drag and drop interface to eliminate the need for a terminal, however keep the CLI for those who prefer it. - As suggested by @jschopplich

This will require different solutions on different platforms.

Any element following a note element will be parsed as action

Describe the bug

It appears that any element following a note element will be parsed and exported as an action element.

To Reproduce
Steps to reproduce the behavior:

$ cat > mwe.fountain
Bruce browses Amazon for new socks.

[[ Bruce needs to be sympathetic ]]

INT. BATCAVE -- DAY

ALFED
Tea sir?

[[ something noteworthy indeed ]]

BRUCE
Bring me the bat tea.

[[ emphasise Bruce does not drink tea made from bats ]]

CUT TO:

$ wrap pdf < mwe.fountain > mwe.pdf

Expected behavior

Our elements should be:

1. action
2. scene heading
3. character
4. dialogue
5. character
6. dialogue
7. transition

...but the scene heading, Bruce's dialogue and the transition elements all appear parsed as action.

Screenshots

Version

• Wrap: Wrap v0.3.1 on Darwin
• OS:

ProductName:	Mac OS X
ProductVersion:	10.13.6
BuildVersion:	17G14042

Potential improvement

Is your feature request related to a problem? Please describe.

No

Describe the solution you'd like

I think the code would be a lot cleaner if you used some generics

Roadmap

Things I'm planning to work on:

• Major code cleanups and improvements to stay sane. See #43.
• Improve PDF output.
  • Support multiple page sizes.
  • Better page breaks (including better support for dual dialogue) which should do a better job in more cases than the current system. See #38.
  • Slightly better word wrap. See #37.
  • Add support for notes. See #29.
• Rework HTML output.
  • Some CSS improvements. Including: support for notes. See #29.
  • Title page. See #1.
  • Embed CSS.

Future goals:

• Better font loading for PDF.
• Other/more output types?
  • eg. Text.
• A script analysis tool.

Sometime in a very far future:

• GUI

Upstreams:

• Bookmarks in PDF.
• Base Courier (makes super tiny PDFs possible).

Embed icon as resource for Windows build

Even for command line tools I would embed icons, especially if you already created it. 👍 (By the way I like it very much.)

Contact info spills off title page

Description
On my title page, I have the following:

Title: Keeping Pace
Author: Kyle Dent
Draft date: December 2018
Contact:
    address line 1
    address line 2
    phone
    email address

The contact is not added to the title page.

If I move 'address line 1' up to the same line as the Contact: key, that one line is printed on the title page and the rest of the contact info is printed at the top of the next page.

Title: Keeping Pace
Author: Kyle Dent
Draft date: December 2018
Contact: address line 1
    address line 2
    phone
    email address

Expected behavior

I would expect all of the contact info to be printed at the bottom of the title page.

Screenshot

Version

• Wrap v0.2.1 on Darwin
• OS: macOS High Sierra

Thanks for a great tool!

Additional flags

Big thanks to the creators of this project for creating this program.

It would grateful for more control when outputting to PDF.

I used to use Atom and the Fountain Package offers many output options, although you have to go into package settings to tinker.

Print title page
Show page numbers
Embolden scene headers
Print actions
Print dialogue
Print headers
Print notes
Print sections
Print synopsis
Double space between scenes
Each scene on new page
Dual dialogue
Font family
Head
Footer
Watermark

I'm not a programmer so I don't know what this would entail but just wanted to make the suggestion for future features.

Thank you

Redesign stageplay

Description

Unlike screenplays we have quite some freedom when dealing with stageplays, the current design was rather hastily put together early in development and hasn't received much attention since.

Provide option to use base PDF courier

Description

Every PDF reader comes with 14 fonts preinstalled, Courier is one of them. When you export a PDF using Courier Prime or Courier New the font has to be embedded in the file, resulting is larger files. If you use the base Courier no font is stored in the PDF resulting in a potentially much smaller file size.

Adding this isn't too much work, however the PDF library we're using doesn't support the base 14 fonts (yet) so it's blocked upstream.

Extra blank line above scene slug in PDF output (maybe in HTML too?)

Send the same screenplay through Wrap vs. 'afterwriting CLI (or examine the PDF output of any professional screenwriting package). Wrap produces an extra blank line worth of space before all scene slugs. I don't know whether this is the case in HTML also.

Certain names trigger wrong results

Describe the bug

Using the name Estella (or ESTHER or INTIMA, whether capitalized or lower case) produces odd results.

For example, type ...
ESTELLA ROBERTS, 30, is sitting on the couch watching TV.
or...
Estella Roberts, 30, is sitting on the couch watching TV.
or even...
estella roberts, 30, is sitting on the couch watching TV.

When you run Wrap, all three variations will result in the following (with an extra space)...

ESTELLA ROBERTS, 30, IS SITTING ON THE COUCH WATCHING TV.

In other words, it treats the line as a header. We (me and others on the Done Deals Forum) are trying to figure out why and guessed that (maybe) Wrap sees EST (in Estella) and thinks that it is EXT.

However ... when using ESTELLA (or the other names) as a Character name, Wrap doesn't change it into a header, but it doesn't indent it either. It just leaves it flush left, as in...

ESTELLA
Turn down the volume.

When it should be (something like) ...

                       ESTELLA
        Turn down the volume.

To Reproduce

To reproduce, just cut and paste these lines into a text document and run Wrap.

Type Action and Character/Dialogue lines using "ESTELLA" and type another set using "ELLA" and you'll see the difference.

Expected behavior
As described above.

Screenshots

Fountain text file ...

PDF results after running Wrap ...

Version
Wrap v0.2.2 on Linux

Improve code quality

As anyone who has skimmed through the code will attest: the code is a mess and so is the repo. I started this project three years back, the summer before uni, it shows...

To clarify, it's not rubish. The parser, the most important part, is backed by tests so although it's messy that part is pretty stable.

At the interface between the parser and other modules things are okay. The ast is a good representation. Adding some utility functions there might reduce some complexity elsewhere, though.

That's a general problem, a lot of functionality is duplicated or concentrated in enormous functions. A lot of refactoring will be needed and even more software design (in the extend Go allows for it).

When functions are smaller it'll also be easier to add tests, which make bugs easier to catch and the software easier to maintain, as we can detect regressions. Adding tests for closed bugs (starting with historic ones) for instance is a good start.

In general I think it's best to first start cleanup at the repo level, figuring out which files belong where. This should be done as soon as possible to prevent future packaging headaches. Fixing the CI is also a minor point of action that can happen at this point.

Afterwards the focus is code. The interface between the cli and the export modules should be looked at first as it's currently one of the biggest messes in the program, if needed by adding temporary functions that abstract away the old uglyness. When that is done, a little bit of polishing can be done to the ast to prepare for the next step. Which is reworking the export modules, as these are the main places where features are added. The cli should get some love after that but probably has already mostly been alright after the first step. Finally it's time to basically throw out the old parser and rework it from scratch as the current design frankly allows for no code reuse whatsoever at that time the languages module can also receive some minor improvements.

In the meantime it's probably pretty safe to hack some features into the export modules. When possible by already partially refactoring the module, of course.

This is a lot of work with little visible external effect, but it's necessary for the health of the project and will greatly improve the ability to add feature in the future.

Change --no-scene-numbers to --scene-numbers

The majority of uses for screenplays (in that most of them are spec and not in production) is to not use scene numbers. I suggest that instead of a --no-scene-numbers flag to disable this feature, there be a --scene-numbers flag to enable it. Or have a --scene-numbers flag which expects a True or False or 1 or 0 value, with the default 0 if the flag is omitted (I don't know whether Go and/or CLI conventions, uh, go for that kind of thing).

Bookmarks in PDF

It would be most useful to have bookmarks to scenes and acts in the PDF, this is however not yet supported by the PDF library we use...

Command line flags for scene heading format

Is your feature request related to a problem? Please describe.

Some screenwriters may prefer their scene headings to be double-spaced, bold, underlined, or a combination thereof.

Describe the solution you'd like

The addition of command line boolean flags for scene heading formatting, e.g.

$ wrap pdf My-Screenplay.fountain --double-space-scene-headings --bold-scene-headings

Or you could choose something less verbose/more fancy...

$ wrap pdf My-Screenplay.fountain --scene-headings=bold,underlined

Describe alternatives you've considered

I think the main alternative is afterwriting CLI , which uses the format:

$ afterwriting [FLAGS] --setting double_space_between_scenes=true --setting embolden_scene_headers=true

Clarify `Type: stageplay` instruction

Greetings,

I created a fork and made a tiny edit to the wiki/Title-Page.md file:

https://github.com/calligraffiti/wrap/wiki/Title-Page

Not exactly sure the best way to submit a pull request from a wiki, so created this Issue. Hope this is helpful!

ツ

Include Courier Prime fonts by default

Error: no Courier Prime installed

Wordwrap doesn't utilize all available space

Description

Whilst not making PDF export unacceptable, the algorithm doesn't fully utilize the provided line length (which becomes noticeable when comparing Feltix and other software, Feltix often cuts the line short earlier).

Command line flag to toggle title page

Is your feature request related to a problem? Please describe.

There are scenarios where it is preferable not to include a title page in the PDF, e.g. when exporting a subset of scenes/pages to replace outdated pages.

Describe the solution you'd like

The addition of a command line boolean flag to toggle title page e.g.

$ wrap pdf My-Screenplay.fountain --no-title-page

Describe alternatives you've considered

I think the main alternative is afterwriting CLI , which uses the format:

$ afterwriting [FLAGS] --setting print_title_page=true

Additional context

The flag --no-title-page probably implies the existence of its opposite --title-page, which in theory would default to true.

Improve page breaks

Although we don't do anything wrong here (generally speaking), there are better selection criteria which would try harder to avoid page breaks which break within an element, etc.

One important part is page breaks within dual-dialogue, currently we don't even insert a (MORE). However I'm yet to find an example of a script where they have had to break within dual-dialogue as a reference.

HTML output should contain title page

The start of the script in HTML should contain a basic title page.

Emphasis is not compliant

Describe the bug

Any linebreak ens emphasis, however thys should be an empty line...

To Reproduce

*Hello dear,
I'm writing...*

Expected behavior

Hello dear,
I'm writing...

Result

*Hello dear,
I'm writing...*

Version

• Wrap: v0.1.5
• OS: all