Any other screenwriters?

[Rick Dooling]

Hello all,

I am an amateur Python person, and I usually learn just enough to make one writing tool or another as I go, because mainly I'm a writer, not a programmer.

Recently, I've been exploring a markdown syntax called Fountain for screenwriters

http://fountain.io/syntax

https://github.com/nyousefi/Fountain

There are several apps that purportedly will allow screenwriters to convertplain text files to PDFs that follow screenwriting format. They cannot replace the $250 programs we use once production begins, but they are good enough for working drafts until production begins.

However, most of these programs are "apps" with closed GUIs, and of course I'm looking for a way to do the same thing with Python and call it from thecommand-line or from within Vim

To that end, I would like to take this Ruby script (which works pretty well, but throws errors in Mac OS X; some Ruby ones and some Prince ones) and convert it to Python so I can fix it myself, because I don't know Ruby at all, and would rather work in Python.

https://github.com/olivertaylor/Textplay

Any pointers?

Thanks a bunch,

Rick Dooling

 

[Chris Angelico]

To that end, I would like to take this Ruby script (which works pretty well, but throws errors in Mac OS X; some Ruby ones and some Prince ones) andconvert it to Python so I can fix it myself, because I don't know Ruby at all, and would rather work in Python.

https://github.com/olivertaylor/Textplay

Hmm. You're looking at a fairly detailed markup language, and a
potentially buggy third-party implementation of it. Are you able to go
from the https://github.com/nyousefi/Fountain code instead? Given that
you don't know Ruby at all, you'd be no worse off there, and it seems
to be the "reference implementation".

Porting either version to Python is going to be a big job,
unfortunately. However, given that the reference implementation seems
to have been written for a Mac, you have a reasonable chance of being
able to execute the code, run the tests, and play with it, while you
develop your own version. That's a *huge* help in porting - you can
implement piece by piece, comparing in detail both the code and the
output of each subsection.

Alternatively, can you get the xcode version to run directly? (I'm not
a Mac person and have no idea whether this is at all possible.) Can
you call on it, in some way, and thus write just a wrapper around the
outside? Might be a smaller job.

Ultimately, you're working with a markup format. That means it's all
text in, fiddle fiddle, text out... a workflow that Python's pretty
good at handling. But you may be letting yourself in for a fairly big
job

ChrisA

 

[richarddooling]

Thank you, Chris. I was trying to avoid the xcode since I know didley aboutthat too, but I'll download it and see if I can get it to run.

THANKS AGAIN

Rick

 

[richarddooling]

Thank you, Chris. I was trying to avoid the xcode since I know didley aboutthat too, but I'll download it and see if I can get it to run.

THANKS AGAIN

Rick

 

[Rick Johnson]

I am an amateur Python person, and I usually learn just
enough to make one writing tool or another as I go,
because mainly I'm a writer, not a programmer. Recently,
I've been exploring a markdown syntax called Fountain for
screenwriters

First impression of Fountain: TOTAL CRAP!

I surly hope this "Fountain" markup is a joke and people are not actually using it to write anything. Fountain's feeble attempts to solve the "plain text" markup problem are an abomination at best, and an insidious evil at worse!

============================================================
Problem 1
============================================================

Take for example their redefining of the simple and ubiquitous "emphasis markups" of:

/italic/
*bold*
*/bold italic/*
_underline_

To this crap:

*italics*
**bold**
***bold italics***
_underline_

....are they joking?

============================================================
Problem 2
============================================================

Their "dual dialog" structure is another folly. "Dual dialog" is so rare that it /hardly/ requires a unique syntactical element. Consider the Fountainsolution via this small short story:

ACTOR_1
Hey, check out that hot chick over there!

ACTOR_2
Where?

(ACTOR_1 slaps ACTOR_2 on the head and points)

ACTOR_1
Over there you idiot!

(feeling a bit hot from all the walking, hot chick
opens the top two buttons on her blouse to allow
some fresh air in; revealing her ample cleavage)

ACTOR_1
Whoa!

ACTOR_2 ^
Whoa!

Two glaring problems with this syntax: A) i don't know that both actors arespeaking simultaneously until *AFTER* i read _both_ lines B) a simple ampersand would have sufficed:

ACTOR_1 & ACTOR_2
Whoa!

There are so many more absurdities that i do not have time to list. If i were you, i would consider a ground-up project that focused on consistency and a very, *VERY* intuitive markdown structure. I could pull a better structure and syntax out of my arse. A simple ASCII text editor with a few "custom modes" is all you need to produce intuitive raw text screen plays that *almost* mimic the real thing.

There are several apps that purportedly will allow
screenwriters to convert plain text files to PDFs that
follow screenwriting format. They cannot replace the $250
programs we use once production begins, but they are good
enough for working drafts until production begins.

Well, $250 dollars is not a lot of money you know, especially if you are using the software for professionally.

However, most of these programs are "apps" with closed
GUIs, and of course I'm looking for a way to do the same
thing with Python and call it from the command-line or
from within Vim

To that end, I would like to take this Ruby script (which
works pretty well, but throws errors in Mac OS X; some
Ruby ones and some Prince ones) and convert it to Python
so I can fix it myself, because I don't know Ruby at all,
and would rather work in Python.

Ruby and Python are very similar. Have you made any attempts to translate (any portions of) the code yet?

 

[richarddooling]

First impression of Fountain: TOTAL CRAP!

Noted. But it seems to be the syntax the screenwriters and their programmers have settled on for now. It's all working pretty well. Just no Python or command-line implementations yet. I didn't post seeking help to make a new markdown system for screenwriters. That would surely be out of my league.

Well, $250 dollars is not a lot of money you know, especially if you are using the software for professionally.

Sorry if I was unclear. Sure. I have several programs like this and yes we use them once production starts, but it's nice to be able to work in your text editor for as long as possible. Faster. More versatility. So everybody is looking for a fast way to make PDFs in screenplay format from simple markdown text.

Ruby and Python are very similar. Have you made any attempts to translate(any portions of) the code yet?

No, but I may. Especially if those regexes in the Ruby script will work in Python. I'll try.

Thanks,

Rick

 

[W. Martin Borgert]

However, most of these programs are "apps" with closed GUIs, and of course I'm looking for a way to do the same thing with Python and call it from the command-line or from within Vim

You should consider taking a look at Trelby. It is free software
(GPL2) and written in Python. While it is a GUI program, you can
import (txt, fdx, celtx, astx, fountain, fadein) and export (pdf,
rtf, fdx, html, foutain, txt), so using vi for editing should
just work. I have no practical experience with the program,
however. If you try it, you should probably take a snapshot from
github, not the latest release 2.2, because it seems, they fixed
some installation issues. While I have no experience in
screenwriting yet, the program seems to run fine for me on
Debian Linux. Find Trelby here: http://www.trelby.org/

 

[Rick Johnson]

Noted. But it seems to be the syntax the screenwriters and
their programmers have settled on for now. It's all
working pretty well. Just no Python or command-line
implementations yet. I didn't post seeking help to make a
new markdown system for screenwriters. That would surely
be out of my league.

Well *everything* will perpetually be "out of your league" until you start challenging yourself to learn new things.

Sorry if I was unclear. Sure. I have several programs like
this and yes we use them once production starts, but it's
nice to be able to work in your text editor for as long as
possible. Faster. More versatility.

I agree.

So everybody is looking for a fast way to make PDFs in
screenplay format from simple markdown text.

Well, well.

This is your golden opportunity Rick. You seem to have found a niche problem that needs solving, but more importantly, you have experience as a screenwriter (and programmer (hobbyist or not)) giving you valuable insight intowhat features can improve the workflow of a simple ASCII markdown syntax.

And, lucky for you, making the translation from Ruby to Python does not require you to become highly proficient with Ruby, NO, once you understand a few key differences you can start translating code into something usable.

I think the greatest barrier to learning Ruby is that it has too many ways to achieve the same result[1], which is opposite of Python's philosophy[2].A few aspects that can trip you up are:

* White-space is NOT significant

* String literals delimited by using single quote chars
are raw, and string literals delimited by double quote
chars are not.

* Module encapsulation is NOT automatic like in Python,
instead, it must be explicitly declared using "module
[code here] end" syntax! Another side effect of this is
if you write (what you think is a function) in global
namespace, you are actually writing a method for
"Object", and since "Object" is inherited by almost
everything in Ruby, now ALL those subclasses contain your
new so-called "function"; Ha! Talk about an introspection
nightmare! So be sure to encapsulate that code fella.

* Ruby uses the "if-elsif-else" progression, whereas Python
uses "if-elif-else". There is also a "case" statement
available in Ruby.

============================================================
* Object Oriented Programming
============================================================
Ruby is more Object oriented than Python (which can be a good thing!), for instance, no more global function nightmare! Objects have methods and methods exist where they should!

RUBY: sequence.map{|item| item+1}

PYTHON_1: map(lambda item:item+1, sequence)

# via list comprehension:
PYTHON_2: [item+1 for item in sequence]

# via generator expressions!
PYTHON_3: (item+1 for item in sequence)

Hmm, seems old Tim Toady is like a plague of, well... toads!

Another side effect of Rubys strong OOP is that you can intelligently chain:

sequence.map{|x| x+1}.uniq.sort.length

....if you tried that in Python, it would be a mess only a devoted lisper could appreciate:

len(set(map(lambda x:x+1, sorted(sequence))))

¡Ay, caramba!

============================================================
* Ruby Blocks can be written many *MANY* ways
============================================================

Blocks in ruby will "most likely" use curly braces like this:

sequence.each{|item| do_something_with(item)}

....but they could also legally use the "do..end" delimiters like this:

sequence.each do |item| do_something_with(item) end

....or even look exactly like Python code!:

for item in sequence
do_something_with(item)
end

Mama-Mia! That's three ways of accomplishing the exact same thing, and the worse part is, these could even be intermixed in the same script file!

============================================================
REFERENCES
============================================================

[1] ThereIsMoreThanOneWayToDoIt (affectionately referred to as: "Tim Toady")
http://en.wikipedia.org/wiki/There's_more_than_one_way_to_do_it

[2] The Python Zen
http://www.python.org/dev/peps/pep-0020/

 

[richarddooling]

Thanks all!

I have the ruby script working pretty well and may indeed just tamper with that and perhaps learn a little ruby along the way.

The goal is a command-line converter, hence Trelby would be nice as a converter of last resort, but I would never use it as an editor. The whole pointis to stay in Vim as long as possible.

Writers are just like programmers. We write, we run it (and then read the PDF) and then we debug (edit). It's this cycle that is so nice in, say, LaTeX or markdown where you can turn the file you are working on into a PDF, read a few paragraphs, edit, turn it into a new PDF, repeat forever.

Thanks for all of the good advice.

Rick