First, Causality is awesome. I use it exclusively to build content and structure. It’s the best tool out there. But… once I’m at first draft, I’ve got to export into other formats for review, etc.
When exporting to HTML, the output could really benefit from style sheets (CSS). Much cleaner, and it allows us to easily change styles and format. (And, this change is easy to code on your side.)
When exporting to Final Draft, it would be excellent if beat titles could carry across to FD scene titles. It’s a hassle to cut and paste all those over to FD. And, if it could bring the beat color over to the scene, that would be handy also.
About the HTML export, if I remember, the goal was for this to be able to become an email, for which using CSS is typically on thin ice, because email client support is spotty, so all the formatting was put inline. Every formatted email you receive has the formatting inline. And this also allowed it to be imported to Word keeping formatting. I think I would still vote for having the formatting inline, but possibly also tagged well enough for CSS classes that CSS could be done in parallel.
About the Final Draft beat titles, a core concept of Causality is that beats are not scenes, and a scene can contain multiple beats. So while it’s possible for you to use Causality in a way where one beat is exactly on scene, it wouldn’t be good to impose that limitation on all users by coding for it. At best, the beat titles for the beats in the scene could be merged into one combo beat title, which is then exported. My problem with that is that it’s lossy, and irreversible, and is likely to be a surprise for someone.
If this is purely about review, wouldn’t it be better to export a PDF? This has elaborate configuration for how to include all the elements. Beat titles even have their own font formatting, so that they are mixed in with the text in the scene.
On HTML, it would be cool to make CSS an option on save. For now, I can write a script that replaces the inline formatting with CSS.
On Final Draft import, I guessed your answer in advance! Beats != Scenes. But, even if it just used the first beat title, that would be decent. Concatenating the beat titles also works because (in my case) nearly all scenes are single beats. (Yeah, I know, but that’s how I work.)
I ultimately solved my problem by exporting to FD, then exporting from FD into the format I needed. Not optimal, but hey, it got the job done.
If you’re wondering the rationale behind all this, it’s that my review distribution is in HTML to allow immediate viewing across all devices. On many devices, PDF requires a file download. With HTML, that step is eliminated.
I’m glad to see someone using the HTML feature for review, because it was made for it, but we weren’t sure if it was useful to anyone.
I’ll put it on the list to make a CSS export. We’d probably have to make a selector for whether to use CSS or inline formatting, because the inline formatting would override the CSS unless you strip it out. It’s obviously not a difficult feature to do (you could whip up a converter quickly), so the only thing holding it back is that 100 of such features still take significant time away from bigger initiatives.
About your converter, are you simply moving the inline styling over the CSS? Or are you making different styling? Since this feature isn’t for me, it’s better to ask someone who’s going to use it.
We have a strong bias against manual formatting such as forced line breaks, because it doesn’t work when the text is formatted differently. For starters, it doesn’t work for using differently sized margins (Squeezed and Super-Squeezed), where text will start wrapping poorly.
We’re very keen on line breaks coming from text wrapping and nothing else. Other things that depend on that are Kindle output, emailed script snippets, switching A4/Letter paper size, subtitles over animation, and more. Basically, the app becomes handcuffed when it has to expect that text can’t be reformatted. We really want it to work like responsive web design where the text automatically formats to whatever device it’s viewed on.
The way to mostly get what you want is to edit the Action paragraph style and not have space before/after. Then Action becomes single-line, and then every Enter makes a new line on the very next line.
Completely agree. Content and formatting should be kept independent, similar to good web page design (as you pointed out.) Control over formatting is done with style sheets.
Unfortunately, many people don’t know this because products like MS Word have been used improperly for decades. And, even editors like the one in this forum do it wrong. (The paragraph breaks require blank lines.)
Regarding your HTML CSS question: I use a simple script to search and replace the tags containing the inline styles with tags using CSS style names. Then I drop a style sheet in at the top. That way I have complete control over the format.
BTW: I’m a bit puzzled by your HTML choices for font (not san-serif like a typewriter) and line spacing (hard coded 12.87px making lines too tight). Unfortunately, the end result (viewing in Chrome on Mac) doesn’t look anything like a standard screenplay. I’d venture to guess nobody really uses the HTML export feature (due to that.)
It has been ages since I visited the HTML feature, so I’ve completely forgotten how it works. It’s possible that it’s just converting the QTextDocument of the Qt framework to HTML without care, so that way of getting text out of the app at least exist.
We definitely did not code an HTML exporter line by line and made the choices that are made. But I think I remember that we kept the inline styling in favor of trying to rig style sheets, because the primary goal was import into Word, and it didn’t honor them or something. In the meanwhile, we now have an actual Word importer/exporter, so that use case fell away.
I’ll put it on the list. Any implementation depends on the use-case you’re imagining while coding it. As I remember, this was actually designed for Word export, so its time has come and gone.