John August

Fountain

How to convert a PDF to Final Draft

Formatting, Fountain, Geek Alert, Highland, How-To, Scriptcast, Software

Screenwriters often find themselves with PDF of a screenplay when what they actually need a Final Draft (.fdx) file that they can edit.

Some common scenarios:

* Your hard drive crashed, and the only copy of your screenplay is an old PDF you sent to a friend.
* You’ve been hired to rewrite a project, but the producers only have a PDF of the script.
* The script only exists on paper. Now it’s been scanned to a PDF — but that still doesn’t get you a script you can edit.

However it happens, it happens a lot. Among my working screenwriter friends, it’s one of the questions I get most.

There are basically three ways to convert from a PDF to Final Draft:

1. Retype it.
2. Copy and Paste and Reformat every line.
3. Use Highland.

**Update:** The folks at Final Draft emailed me to suggest an additional workflow, which I’ll detail after the section on copy-and-paste.

###Retyping it

This is the worst option, but back in the days of paper scripts, it was the only option. It’s as awful as it sounds. If you do it yourself, it’s exhausting. If you pay someone to do it, it’s expensive.

Retyping inevitably introduces mistakes. Spellcheck will catch some typos, but words will get omitted.

The only scenario in which I can envision retyping a script is if it’s so bad you really do want to rewrite it scene by scene. But in these cases, I think you’re better off putting the old script aside and starting at page one.

###Copy and Paste and Reformat every line

PDFs come in two basic types. Some PDFs are essentially photos of pages. You see the text, but it’s really an image. Other PDFs include the text itself. In Acrobat or Preview, you can select the text.

Most PDFs these days have selectable text, so there’s a good chance you’ll be able to copy the text out. If you paste it into Final Draft, you’ll end up with a mess that will take quite a bit of work (and time) to sort out. But it’s doable.

Here’s a [screencast](http://youtu.be/dElQe8_xf9E) to show you this workflow:

As you can see, reformatting a script this way sucks. It’s better than retyping, but there are many ways things can go wrong. Final Draft is not well-suited to this kind of brute force. You will learn to despise the Reformat box.

But if you only have a PC, this may be your best option, because the next solution only exists on the Mac.

###Use Adobe Reader to save as text, then open in Final Draft

After I posted this entry, the folks Final Draft pointed me to an alternate workflow. Here’s what they [recommend](http://kb.finaldraft.com/article.aspx?cid=1001&aid=519):

> If you have a recent version of the Adobe Acrobat Reader you can go to File > Save As > Text and save the document as a text file.

> Import this text file into Final Draft (File > Open) as a script but you may need to do some reformatting.

Here’s a [screencast](https://www.youtube.com/watch?v=opOsTknLZJ4):

In my testing, it’s only a little better than copy-and-paste. Elements were more likely to be recognized correctly, but line breaks and spacing glitches were daunting. The script also swelled from 114 to 343 pages. I had similar results with all the PDFs I tried.

So while it’s generally an improvement over copy-and-paste, you’d still need to spend quite a bit of time getting a useful script out of this workflow

###Use Highland

If you have a Mac, or a friend who has a Mac, this is your best choice. Hell, if you have a mortal enemy who has a Mac, it’s worth kissing up to him for the five minutes this will take.

[Highland](http://highland.quoteunquoteapps.com/screencast-pdf-fdx) is a paid app in the Mac App Store. It’s actually a full-on screenwriting app, but its ability to melt down PDFs was its original claim to fame, and is still unrivaled.

With Highland, you just drag in the PDF. Highland sucks out the text and does all the reformating. From there, you can edit it right there in Highland, or export it to Final Draft.

Here’s a [screencast](http://youtu.be/4ECADQtAvUg) showing the process:

Can Highland convert every PDF to Final Draft? No.

If a PDF is really just a stack of images, there’s no text to suck out. You may come across these kinds of PDFs when dealing with scanned paper scripts. However, many screenwriters report success running PDFs through optical character recognition software like [Prizmo 2](https://itunes.apple.com/us/app/prizmo-2-scanning-ocr-speech/id546392952?mt=12) first. That’s certainly an option.

PDFs created by Fade In don’t convert well. It’s because of the odd PDF-building code Fade In uses. It’s not something Highland is going to be able to fix.

### Built to be used

My company created Highland because I needed it. While it’s not a huge moneymaker, ((Highland revenues could probably support a single coder with a love of ramen noodles and penchant for tent living.)) it serves a crucial need for screenwriters.

We used to offer a free demo version of Highland, but it confused users more than it helped. (Support emails like, “How do I get rid of the watermark that says ‘Highland Demo?'”)

Also, the demo version was always lagging behind. We update Highland frequently, often twice a month. Maintaining both the paid and demo versions was slowing down development, and the feature sets kept getting out of sync. It’s not easy or rewarding to build deliberately crippled versions of your apps.

So rather than a demo version, I’m planning more screencasts like these to show features and workflows. In the meantime, if you find yourself with a PDF to convert, head over to the Mac App Store and [grab Highland](http://highland.quoteunquoteapps.com/screencast-pdf-fdx). For $30, it will save you untold hours of frustration.

Highland updated to 1.03

Apps, Fountain, Highland

Highland, our multi-purpose screenwriting app, has a free update in the Mac App Store. It’s [available now](https://itunes.apple.com/us/app/highland/id499329572?mt=12).

Version 1.0.3 fixes several bugs, including one involving dual dialogue that made a mess on the page.

Something new: When bringing in a PDF or Final Draft file, Highland now appends (converted) to the title until you save the document with its own name. The goal is to make it clear to users that they’re creating a new document, not editing the old one itself.

If you’ve been enjoying Highland and haven’t [left a review](https://itunes.apple.com/us/app/highland/id499329572?mt=12) on the Mac App Store, we’d certainly appreciate it. Thanks.

Building shotlists from Fountain screenplays

Fountain

Responding to a lazyweb request, Matthew McCowan built a handy little script/app for building shotlists from screenplays written in Fountain. Stu Maschwitz [explains](http://slugline.co/blog/shotlists):

> Fountain’s Notes [[like this one]] can contain any text you like, including multiple paragraphs. Since Notes don’t print, you can use them to store all kinds of useful information, such as notes on revisions, character bios, or even text that can have special, nerdy powers.

In this case, McCowan’s script is looking for notes that start with SHOT: and gathering them with the scene header to form a tidy shotlist. But you could easily generalize this to gather all notes, or tweak it to look for another criteria such as the name of the person giving the note.

One of the huge advantages of Fountain is its easy extensibility. Any tool that can work on plain text can work with Fountain.

Topping the charts and racing to the bottom

Apps, Bronson, FDX Reader, Fountain, Highland

Next week is WWDC, the annual developers’ conference at which Apple reveals all the shiny new goodness they have planned for app makers. Like everyone, I’m anticipating new looks and new APIs. What I’m not expecting is what I’d really like to see: some major changes to the App Store.

As someone who sells apps, I’d love near-real-time sales reports, link tracking and better management of promo codes.

But what I want most is for Apple to get rid of the charts.

The App Store’s best-sellers lists hurt shoppers, developers and Apple. The charts create a vicious circle that encourages shitty business models and system-gaming. They’re a relic of a time when data was scarce. They should go away.

Marco Arment [thinks so too](http://www.marco.org/2013/05/10/tire-kickers):

> Abolishing the “top” lists from all App Store interfaces and exclusively showing editorially selected apps in browsing screens would do a hell of a lot more than trials to promote healthy app economics and the creation of high-quality software.

Having been through the App Store experience with [Bronson Watermarker](http://quoteunquoteapps.com/bronson/), [Highland](http://quoteunquoteapps.com/highland/), [FDX Reader](https://itunes.apple.com/us/app/fdx-reader/id437362569?mt=8) and [two](https://itunes.apple.com/us/app/karateka/id560927460?mt=8) [variations](https://itunes.apple.com/us/app/karateka-classic/id636777828?mt=8) of Karateka, I think Arment’s on the right track. But editorial curation is only part of the solution. Apple can and should use sales data to help steer buyers towards apps they’ll like. It just has to be smarter about it.

##How charts hurt consumers

Since most people are app-buyers, let’s start there.

These lists — a sidebar in iTunes, a tab on the App Store — show what’s downloaded the most. But let’s not mistake downloads for popularity. These are apps that people may have downloaded, used once, then deleted. What you really want is a list that shows what apps that *people like you* are using and enjoying. That’s the kind of information that companies like Amazon and Netflix are terrific at leveraging.

Apple makes some attempt at this in their Genius tab, which tries to find correlations based on what other apps you have installed, but I’ve never found it useful. Just because I have one to-do app doesn’t mean I’m looking for five more. (In fact, I’m probably less likely to buy another to-do app if I have one I’m using regularly.)

Consider Netflix. Netflix will show you “What’s Popular,” but it’s not a ranked list. Rather, it shows you things you might be interested in, either because of overall popularity or its own internal algorithms that calculate your preferences. Search for flashlights on Amazon and it will show you flashlights sorted based on whatever formula their data suggests will most likely result in you buying a flashlight.

That’s not how the App Store does it. Apple shows you a list of what freemium games teenagers downloaded. It’s not showing you the best games, or the most-liked games. It’s showing you what’s at the top of the charts — and because these games are at the top of the charts, they’re likely to stay there.

##How charts hurt developers

The most popular paid apps are almost always the cheapest apps, which fosters a race to the bottom. Yes, you can set your price higher — and [maybe should](http://www.tuaw.com/2013/04/01/detailed-look-at-pricing-an-app-for-the-mac-app-store/) — but since the charts are one of the only ways to get visibility on the App Store, there’s a strong incentive to go low for exposure.

Let’s say your app is priced at $10, and you sell 100 per week. Cutting your price to $5, you discover that you sell 200 per week. Cutting your price to $1, you sell 1000 per week. ((I’m making up these numbers. In reality, I’ve found price elasticity to be all over the place with the apps I’ve sold.)) In each case, you’ve made $1000. You’re making just as much money at each price point, but the $1 app would chart much, much higher in the App Store.

For that reason alone, you might pick that price even though you now have ten times the customers to support. By pricing it for the masses, you’re dealing with the masses.

Apple has tried to address the situation by adding a third list, Top Grossing, which should in theory reward the apps that sold fewer copies at a higher price. In reality, the Top Grossing iOS apps are the games with lots of consumable in-app purchases. ((On the Mac, Top Grossing does favor more-expensive apps, although Apple’s own software dominates the top of the list.))

Partly because the top-sellers lists are public information, developers feel themselves pushed to keep lowering their prices for fear of a competitor undercutting them.

That happened to us with Bronson Watermarker. We started out priced at $9.99. Three weeks later, a near-clone entered the App Store at $4.99. Does that mean we were priced too high? Or were they priced too low?

We ultimately raised our price to $14.99, while they’ve essentially abandoned their app, so my hunch is they discovered there wasn’t enough money to be made at their price.

But what if cutting the price isn’t enough to climb the charts? Developers can use [outside services like Chartboost](http://blog.chartboost.com/post/4345825883/powerful-strategy-appstore-charts):

> However, when you combine **volume with time**, then that’s where you start cracking the secret formula. If you can get high volume of installs over a short period of time, your app gets noticed and starts climbing the charts.

Most people don’t realize there’s a whole parallel industry devoted to the App Store charts. Apple could get rid of it by removing one button.

What would go in place of that “Top Charts” button? Maybe “Favorites,” with a custom-generated list of popular and well-liked apps tailored to the user. Maybe promote the “Staff Picks” section to its own spot. Hell, let’s dump “Genius” and put in both.

Should developers get to see the best-sellers chart? I think not.

I know it sounds weird to argue for less transparency, but I’d rather have more data about how my own apps are selling than a ranked list of everyone else’s. Charts encourage developers to focus on competitors rather than customers. So get rid of ’em.

I doubt Apple will announce anything like this at next week’s WWDC. But I think developers would get more out of this change than anything Apple will introduce at the conference.