lichendust / meander Goto Github PK

This is a feature that's regularly claimed to be difficult to implement in Fountain.

I envision this as follows:

Meander would have a new pre-processor command step which would expand all scene numbers, counters and other variable values, then reconstruct the screenplay post-pagination, enforcing split paragraphs and (more)/(cont'd) continuation. It would manually insert page breaks and declare new, static headers and footers for each of the "pages" it has now created in the text file.

The writer can then manually adjust the header sections, scene numbers and other values that now increment differently in a page-locked scenario. Writing between the page-breaks will extend that "page" with its new, enforced values.

Using a custom variant of the page-break syntax (perhaps five equals ===== instead of three), Meander will recognise these as being locked-page breaks and not increment values like page numbers when passing them. The writer can then modify the now hard-coded headers with a new counter, such as #PAGE-#SUBPAGE:A (3-A, 3-B, etc.) to increment any alphabetical sub-pages they're adding.

One of the main limitations of this right now is guaranteeing that everything will play ball and reconstruct perfectly again after being manually split. There's certainly zero guarantee of any proper rendering in any other Fountain tool, assuming you were only writing with core Fountain syntax, and there's no guarantee of internal consistency between versions of Meander if we tweaked a template later on, which is... annoying.

Not every screenplay software, nor writer for that matter, uses the same page formatting. So it would be great to have parameters to override the margins when rendering to PDF. As an example, I am converting from FDX to Fountain and then to PDF. Compared to the original FDX, the margins are slightly off which results in an extra 6 pages.

This is a pretty cool little doodad you got here. I may donate in the future, but one confusion I have is that: why does it underline scene headings like from (for example) the Big Fish one from https://www.fountain.io/syntax website.

BigFishy.pdf

I used your program to render the Big-Fish.fountain file to BigFishy.pdf, but I'm puzzled why the scene headings are underlined. Never seen any other converter or render program do that. So I'm more puzzled and confused if anything. Additionally, I want to comment on the fdx converter support, I didn't think this warranted a new issue thread, so I'll mention it here:

You can use writersolo.com to convert fountain files to fdx to see how the syntax changes in the xml markup. If I could make a suggestion, you could just have the converter completely omit stuff that would be only for final draft users only like page locking and stuff like that. Just ignore it and focus on the elements that would be practical for plain text editing like fountain in vim or emacs.

Every other Fountain editor that supports starred revisions does so by switching the container format to some arbitrary binary or zipping the text file alongside some other blobs of diff data.

Meander won't ever do that. No binaries, only plain text. The zip is somewhat acceptable, but once you've opened the Pandora's box of adding extended syntax... you may as well just continue. Looking at you, John August.

I've experimented with starred revisions to a surprising degree of success by having Meander simply read Git and Mercurial diffs as a switching mode in the parser. I based the target historical versions on tags rather than commits, so that tags could be moved around to provide the writer's preferred historical commit (in case they thought to add something new to the pink revision and now needed to bump it).

As a simplification, the working copy (whatever was on disk at that moment) was always compared to a historical target. You couldn't compare two arbitrary historical points unless you checked the newer one out and compared it to the older.

The issue was that in semi-rare cases, Git would take it upon itself to do it's job very very efficiently, which is storing the diff in the smallest possible form. This meant that some changes were not localised to the site of the writer's actual changes and would result in a big stripe of green or red in the diff — now half the page is starred unnecessarily.

The other issue with this is that asking the average non-technical writer to interface with Meander is already a bit of a stretch, let alone asking them to also deal with Git. The hurried writer making amendments in their trailer on a break is hardly going to want to deal with Git's utterly maddening CLI interface to move a tag around.

Instead, it seems like it might be a better idea to provide a tag in syntax that writers can use to mark changed paragraphs. If they want to version their screenplay, they can do so with whatever tools they like externally. As mentioned before, working copy is always the canonical one in this paradigm.

Anyway, here's a pseudo-syntactic example of what this might look like:

        DANIEL @pink
    (rage consuming him)
_I DRINK YOUR MILKSHAKE!_

The writer can then export the screenplay with the -r pink flag and all items tagged as pink will be marked with stars.

It could also be combined with the page-locking feature, where pages with headers featuring these tags would be considered the only pages in the output: a -r pink build would then create a PDF with only those pages ready for printing.

I want some feedback on this idea before I implement it natively, but it's otherwise a relatively easy addition to the project.

A flag for the merge command called --archive, which would expand and bake all syntax features into the text:

• includes
• scene numbers
• counters

It would also sanitise Meander of any other Meander-flavoured syntaxes, such as wrapping header: updates in note syntax to obfuscate them. It's essentially a command modifier that "un-Meanderises" any document, suitable for importing into Final Draft or simply archiving the file long-term at the end of a production.

Current limitation: the parser kinda sucks and is desctructive, so it makes writing this kind of feature require a lot of duplicated logic and code. A proper tokenising parser that can bi-directionally reconstruct all of the original text would enable this feature handily and fix a bunch of edge programming that's currently in other parts of Meander right now.

Using meander on Apple M2.

meander convert file.fdx - works fine and creates a .fountain file.

Then when running meander against the newly created .fountain file using either render or data option, gives the following error:

meander render file.fountain or..
meander data file.fountain

panic: runtime error: index out of range [3891] with length 3891

goroutine 1 [running]:
main.syntax_parser(0x140000940a0, 0x140000ebdc8, {0x14000154000, 0x1b813})
	github.com/qxoko/meander/source/parser.go:692 +0x21f8
main.command_render(0x140000940a0)
	github.com/qxoko/meander/source/command_render.go:57 +0x90
main.main()
	github.com/qxoko/meander/source/meander.go:35 +0x40

For reference, there are 3894 lines in the converted .fountain file.

If I add an extra line at the end with any character such as ".", then it works fine.