How the editor works, plus Canvas or HTML/CSS

12 views
Skip to first unread message

Ritchie Wilson

unread,
Feb 11, 2012, 5:54:56 PM2/11/12
to rawsc...@googlegroups.com
Currently the screenplay editor has a couple of pieces -- the data and the rendered. All the text and formatting data for the screenplay is stored in a JS list called 'lines', and each line in 'lines' contains the text and the format, represented by a number. The format number corresponds to a type of text like "character", "dialog", "action", "transition", etc. Here's an example where the format 1 corresponds to a slugline.
{
   text: "Ext. Park Bench - Day",
   format:1
 }

So there is a long list of these JS objects which makes up the the screenplay data. When a user presses a key, that data is directly manipulated. Calculations for things like line wrapping and page breaks are done by looking at these JS objects.

Then, in an animation type way, that data is drawn onto the screen on a <canvas>. So, the screenplay data and the rendering on screen are almost totally separated.

That means that the rendering system could be redone, say, in HTML and CSS. THe bulk of the underlying system wouldn't needed to be changed, just the renderer, with exceptions. There are things to be said for each case.

SWITCHING to HTML/CSS RENDERER:
Developers are probably more used to DOM manipulations than <canvas> drawing methods.
More mature and trusted JS libraries
Would need to rebuild renderer
There is some user interaction with the render, so would need to rebuild things like mouse actions (clicking on text)
Might use less CPU
HTML is rendered differently browser to browser - could mess up consistent screenplay formatting
More conforming to the semantic web (?)

STAYING WITH CANVAS
It's built and works
It gives total control over formatting, pixel for pixel -- important for screenplays
Almost totally avoids differences between browsers - if browser has canvas, it works
Needs optimization -- shouldn't be too hard, but it's needed
Doesn't work with old browsers (Basically IE8 is the problem)
Libraries for <canvas> aren't as developed (maybe easeljs could be good) 
User interaction with renderer (like clicking in text) is built and works.


So, my opinion: I like <canvas>. People (myself included) have tried building screenplay editors in HTML, and they just aren't that good. HTML sucks with things like consistent formatting and pagination. I see there are potential ways to do this in HTML, but I don't see that it's worth it. HTML could have some benefits, but right now the editor is the best part of Rawscripts, and I don't want to rewrite that for some small benefits.

I also see the possible issues with <canvas> being less a problem over time. Canvas support in people's browsers is high and growing. People are switching to Chrome and IE9 and Chrome Frame. There are more and more libraries to help with <canvas>. The code is running a little more efficiently all the time. There's now tons of documentation on <canvas>. Using <canvas> now is much easier then when I started a ~2 years ago.

The renderer could be redone if there are some large benefits I'm missing, but I like how it is now.

Any thought, please share
Cheers
Ritchie

--
Ritchie
Reply all
Reply to author
Forward
0 new messages