Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #40901 > unrolled thread

Any other screenwriters?

Back to article view | Back to comp.lang.python

Contents

  Any other screenwriters? Rick Dooling <rpdooling@gmail.com> - 2013-03-08 13:07 -0800
    Re: Any other screenwriters? Chris Angelico <rosuav@gmail.com> - 2013-03-09 08:51 +1100
      Re: Any other screenwriters? richarddooling@gmail.com - 2013-03-08 14:42 -0800
      Re: Any other screenwriters? richarddooling@gmail.com - 2013-03-08 14:42 -0800
    Re: Any other screenwriters? Rick Johnson <rantingrickjohnson@gmail.com> - 2013-03-08 19:41 -0800
      Re: Any other screenwriters? richarddooling@gmail.com - 2013-03-08 21:36 -0800
        Re: Any other screenwriters? Rick Johnson <rantingrickjohnson@gmail.com> - 2013-03-09 15:07 -0800
    Trelby (was: Any other screenwriters?) "W. Martin Borgert" <debacle@debian.org> - 2013-03-09 10:42 +0100
    Re: Any other screenwriters? richarddooling@gmail.com - 2013-03-10 07:53 -0700

#40901 — Any other screenwriters?

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 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.

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.

https://github.com/olivertaylor/Textplay

Any pointers?

Thanks a bunch,

Rick Dooling

[toc] | [next] | [standalone]

#40906

On Sat, Mar 9, 2013 at 8:07 AM, Rick Dooling <rpdooling@gmail.com> wrote:
> 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

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

[toc] | [prev] | [next] | [standalone]

#40909

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

THANKS AGAIN

Rick

On Friday, March 8, 2013 3:51:44 PM UTC-6, Chris Angelico wrote:
> On Sat, Mar 9, 2013 at 8:07 AM, Rick Dooling  wrote:
> 
> > 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
> 
> 
> 
> 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

[toc] | [prev] | [next] | [standalone]

#40910

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

THANKS AGAIN

Rick

On Friday, March 8, 2013 3:51:44 PM UTC-6, Chris Angelico wrote:
> On Sat, Mar 9, 2013 at 8:07 AM, Rick Dooling  wrote:
> 
> > 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
> 
> 
> 
> 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

[toc] | [prev] | [next] | [standalone]

#40925

On Friday, March 8, 2013 3:07:59 PM UTC-6, Rick Dooling wrote:
> 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 Fountain solution 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 are speaking 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?

[toc] | [prev] | [next] | [standalone]

#40932

On Friday, March 8, 2013 9:41:57 PM UTC-6, Rick Johnson wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#40984

On Friday, March 8, 2013 11:36:05 PM UTC-6, richard...@gmail.com wrote:
> 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 screen writer (and programmer (hobbyist or not)) giving you valuable insight into what 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)))) 
    
o_O ¡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%27s_more_than_one_way_to_do_it
    
[2] The Python Zen
    http://www.python.org/dev/peps/pep-0020/
   

[toc] | [prev] | [next] | [standalone]

#40939 — Trelby (was: Any other screenwriters?)

On 2013-03-08 13:07, Rick Dooling wrote:
> 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/

[toc] | [prev] | [next] | [standalone]

#41017

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 point is 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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web