More zoom settings
I'm betting you want to see the visible screen filled by your script, rather than more zoom settings - am I wrong? <<
Actually ... I have 30" monitor, and to have the entire thing fill the screen is horrid.
But your point is valid, 'fill screen width' is a good idea.
I'd like to see some smaller zooming sizes so I can get more (readable) text on the page, but I can probably fiddle with fonts to do this.
Having multiple windows on the same script, or docking panes so that I could see multiple tabs at the same time would be ideal.
I'd think with 1080p screens becoming more and more common, this will soon be a problem for a lot of people.
== John ==
21:39, 19 June 2008 (PDT)~~
Scene Locking now implemented
- The discussion of scene locking here doesn't make sense. Anyone working on an evolving project prefers unambiguous referents. The continual renumbering of the scenes makes it mandatory that ANOTHER referent is found to refer to a scene without confusion. Just for a quick example, let's say scene 10 is cut. Is it really a good thing that everyone has to be aware of that before they can correctly refer to the number of the fifth scene following the scene that's cut? It's really quite obvious how useless that convention is.
- I'd like someone in development to explain which department prefers that it be impossible to refer to the scenes in the script without ambiguity.
- Cinemaring 21:25, 20 April 2009 (PDT)
- "The development team aren't convinced that scene locking is the right solution to the problem of scripts changing after publication."
- But, development team, this is a complete misdiagnosis of the main reason for scene locking. It's not used after publication; it's used during drafting in collaboration and to respond to notes and coverage. Again, just to make it completely obvious: if someone says, "Cut scene 12" I shouldn't have to ask them anything else about the referent of "scene 12." For some reason, the development team thinks it's a good idea that it's hard to figure out what is meant by such a simple sentence?
- That's wrong, development team. You're wrong. Recognize your error.
- Cinemaring 21:25, 20 April 2009 (PDT)
Leaving out Scene Locking is wrong headed
- The current developer response to scene locking is classic non-user/developers trying to second guess the needs of the users and being ignorant of human nature. This is a big deal with lack of scene locking being a significant barrier to usage in a real production environment. Even if the logic behind the decision is accurate (and I don't believe it is, I agree with everything Cinemaring said) it will never work in the real world.
- Think about it for just two seconds: right or wrong, the developers are saying that the way the film industry, a billion dollar industry with thousands of people already following a long running standard, are wrong and that they should switch to this new way that a non-industry dominant software package proposes without any formal description of how it would work.
- Not only that but it is proposing that for their version of the solution to work everyone on the production has to change their ways, often after decades of using a way that they are familiar with and works, and not only adopt this new, untested method but switch software and/or possible buy a computer and adopt the software to make it work.
- Do they really think that all these old guys in the industry are going to drop their old ways and learn new ones just because? Not everyone uses a computer on set for their jobs (even if they have them) and you can't force them to. Not only that, it assumes that everyone who does willingly switch will be able to learn the new program and use it without fail, the first time out, and if they do have problems to stick with it. No one bigger than a student film shoot would even bother to try, not with millions on the line.
- Here's a personal example of reality. I used to collect data for VFX on set for years and I developed a Filemaker database for organizing these notes and other media. I even set up a Palm using Handbase to do the data entry. Of the various other data people I had to integrate with on various films I could only get about half of them to try it and only one to fully adopt it. I'm talking about convincing just one other person on the crew to change and adopt my way of doing things and I was even providing the hardware and software! This is on films like The Chronicles of Narnia, Garfield, The Cat in the Hat, Daredevil, The Fast and The Furious 3, etc. People don't change easily (if ever) and computers and software present a level of complexity that is very intimidating to the experienced and the old schoolers in the industry. You can't even get the industry to adopt a different font for scripts and that wouldn't change anything (assuming it was for a similarly spaced font) and we're stuck with an old and ugly typewriter font.
- Hand in hand with this is the lack of a revision mode which I assume is for the same reasons. Again, it isn't just for on the set, during production. When I am collaborating with another writer I use it all the time. If someone gives me new pages to a script I've already read of am working with, my first question is "what did you change?" Am I really expected to go though the whole script again (at least two hours of my valuable time) to see that there are new lines in a handful of scenes and then guess or try and compare them to the old script to figure out specifically what they are? Come on, guys. We need this badly.
- Please, please, please reconsider this very wrong headed decision. People like me are desperate for an alternative to the crappy industry standards of Final Draft and EP's Breakdown and Scheduler. These are unreasonable expectations and by not even including the old methods as a backup option the developers are inadvertently marginalizing the software.
- --Lezone 15:14, 5 September 2009 (PDT)