eprovst / wrap

A Fountain export tool with some extras...
GNU General Public License v3.0
62 stars 8 forks source link

Support different page sizes #39

Closed rnkn closed 3 years ago

rnkn commented 4 years ago

First, in case I’ve not mentioned it, I really appreciate you building Wrap and putting your time/energy into the Fountain ecosystem. Thank you.

Is your feature request related to a problem? Please describe.

Not really, except perhaps not being able to specify page size.

Describe the solution you'd like

There are slight variations in how people may like to format their scripts; generally I’d say these are limited to: page size (a4 vs. US letter), whether dialogue breaks across pages, and whether scene headings are double-spaced, bold, and/or underlined. I’d like to be able to configure these via command line switches. There are probably others variations people wish for (e.g. #29 ) but I’d say these are the main ones.

Describe alternatives you've considered

Currently I use afterwriting, but I think multiple implementations are a very positive thing.

Additional context

I maintain an Emacs mode for Fountain editing. Currently it has internal export functionality, but I would prefer to remove this in favour of external CLI tools such as Wrap. Being able to specify export formatting via command switches makes for a pretty seamless user interaction, e.g. here’s a screenshot of how a user configures different export profiles in Emacs:

Screen Shot 2020-11-09 at 5 44 18 pm
eprovst commented 4 years ago

This is something I have been thinking on for a while actually. There are mainly two reasons why this kind of flexibility is not something I am planning to add, at least entirely:

  1. Wrap is intended to be very simple and straightforward tool. The problem that this creates is that every feature should be carefully selected as not to introduce feature creep. The -v option of cat is a great example of something to avoid.

  2. I want to make it easy for users to export industry standard screenplays and hard to shoot oneself in the foot. Underlining of scene headers for instance is a great example, this goes against typographical best practices and is not seen in any style guide.

    Emboldening scene headers without double spacing seems to be a recent trend however so that is something that might be added. That way there are two options: traditional (the default) and contemporary which can even change between versions of Wrap to reflect current usage. However emboldening with double spacing is again something that isn't done by most professionals and thus shouldn't be an option of Wrap in my opinion.

Stopping dialogue from breaking across pages is something that would require an entire rewrite of the PDF export module and that would break "one minute per page" estimates. So it's unlikely this will be added either.

Support for A4 is indeed something that is missing, shouldn't be too hard to add, only needs some margin offsets.

In summary: Wrap tries to complement Afterwriting by being simple and straightforward to install, use and get standard compliant results. So there is no goal of having the same or similar flexibility :slightly_smiling_face:

Putting limits at the functionality of submodules also helps to make other parts a lot more flexible. Supporting languages different from English, multiple output formats...

It's a careful balancing act, combined with limited development time. Of course if you disagree with any of my concerns or are able to provide patches, please do. I'm open to changing my mind and it's Free and Open Source Software after all! :slightly_smiling_face:

Which reminds me to leave some code quality disclaimers in some modules. The parser is fairly ugly for instance...

rnkn commented 4 years ago

Sounds like you’ve got a good handle on it all. I agree that A4 would be the priority, and then whatever scene heading variations you see fit. A dialogue-breaking-across-pages option could safely be ignored.

rnkn commented 4 years ago

I hope you don't mind me chiming in again but what's your take on exporting snippets? e.g. Someone asks for just a couple of new scenes (page numbers don't matter).

This works well with Wrap's ability to read from stdin, and would go nicely with a tittle page flag.

eprovst commented 4 years ago

A snippet mode, where page numbers and title page are disabled, has a clear, common use case. So that's going on the to do list.

Thanks for the suggestion!

corvore commented 4 years ago

Another vote for some formatting. Even just something like --bold-scenes. I feel like maybe just a couple of the most common formatting differences people might have would be helpful.

Again, thank you for such a wonderful tool! The scene numbering is *chef's kiss. Just missing my bold scene headings ;)

sten0 commented 4 years ago

@elecprog, would it be possible to get A4 support and a tagged release before Christmas? I maintain the Debian package for @rnkn's fountain-mode, and I've been deferring updating to the latest version because Debian doesn't have a fountain->PDF export solution yet. Afterwriting looks like a nightmare to package, but I'm optimistic about Wrap! In particular, the multilingual aspect fits well with Debian's ethos :-)

eprovst commented 4 years ago

I was deferring A4 support until I had the time to properly cleanup the PDF export module which is unlikely before Christmas.

I see the urgency though, so I'll instead try to patch it in somewhere in the coming month to have time to collect feedback/bug reports before Debian freezes the next release 🙂

rnkn commented 4 years ago

@sten0 what's the timeline for Debian feature freeze? Also, does pip install 'screenplain[PDF]' not work on Debian?

eprovst commented 4 years ago

Okay, page size should up and working in the latest nightly.

It's a bit hacky, though (and, oh dear, this project's code is messy...) :slightly_smiling_face:

sten0 commented 4 years ago

Hi Evert,

Evert Provoost notifications@github.com writes:

I was deferring A4 support until I had the time to properly cleanup the PDF export module which is unlikely before Christmas.

Mm, I agree, that's the order I prefer to do things do :-)

I see the urgency though, so I'll instead try to patch it in somewhere in the coming month to have time to collect feedback/bug reports before Debian freezes the next release 🙂

Okay, page size should up and working in the latest nightly.

Thank you, much appreciated, I'll get to work on the packaging asap!

It's a bit hacky, though (and, oh dear, this project's code is messy...) :slightly_smiling_face:

At this stage, I'm ok with that. Perfect is the enemy of the good, premature optimisation is a pitfall, and all that ;-)

In terms of roadmap and deadlines from a Debian-release perspective:

It's undefined how long it takes a "NEW" package to be accepted, so I need to work fast to get the Wrap package into a working and Debian Policy-compliant state. BTW, I haven't yet investigated Wraparound/css. I'm assuming that their tagged releases are synchronised, but please let me know.

To get into Debian 11 (bullseye), a package must clear the "NEW" queue by early January. Intrusive changes such as large refactorings, and big new features should also be completed by this time.

Small targeted fixes of any severity (via cherry picked commits) can be added between earlier January and early March.

After that, only release-critical fixes (data loss, crashes, broken core functionality, etc.) are accepted, and someone on the release team will have to approve the proposed patch[es]. Smaller fixes are more likely to be approved. At this time, it's hypothetically possible that 1) only a large patch solves the RC issue 2) the release team doesn't approve of the patch 3) the package gets dropped from the next release.

This release's freeze policy is available here, and I've added a bit of time to the deadlines to give myself time to react:

https://release.debian.org/bullseye/freeze_policy.html

At any rate, I'm excited to package Wrap, and hope that lots of people will find it useful :-)

Cheers! Nicholas

sten0 commented 4 years ago

Hi Paul,

"Paul W. Rankin" notifications@github.com writes:

@sten0 what's the timeline for Debian feature freeze? Also, does pip install 'screenplain[PDF]' not work on Debian?

See previous message in this thread for the bullseye release policy. Of course pip works, as does MELPA ;-) Screenplain isn't a good fit for a system-level package, imho. Also, all Debian packages must build and run their tests without network access, so I will never be able to depend on a pip or npm (Afterwriting) solution. Finally, in Debian we have the old-school ideal of providing everything a user needs on physical media, so they can do upgrades and get work done even without internet access. Having worked or vacationed in remote locations remote locations, or places with metered bandwidth or dial-up level connections, this is something I appreciate :-) It's part of that whole "universal operating system [even for those without internet access]" ideal.

Cheers, Nicholas

eprovst commented 4 years ago

@sten0 see the latest comment in #33, HTML output currently uses a CDN to get the CSS, I'm planning on embedding it in the output before the next release.

Most likely I'll archive Wraparound/css. At any rate, no need to package that one 😉

Under scripts, there is a .go source file that generates shell completions. Could be useful for packaging.

If you have any suggestions for reorganisation of the repo structure that might aide packaging, please let me know, preferably in a separate issue. The code is a mess and so is the repo. I started this project three years back, the summer before uni, it shows...

To clarify, you're not packaging rubish. The parser is backed by unit tests so although it's messy that part is pretty stable. I might write a more detailed report of code quality.

At any rate, thank you for wanting to package Wrap. Having your code being packaged in Debian is quite the honour. 🙂

sten0 commented 3 years ago

Hi Evert,

Thank for the quick reply, and sorry for the delay in mine.

Evert Provoost notifications@github.com writes:

@sten0 see the latest comment in #33, HTML output currently uses a CDN to get the CSS, I'm planning on embedding it in the output before the next release.

Thank you for prioritising this, it seems like I'll need to wait for the next release.

Most likely I'll archive Wraparound/css. At any rate, no need to package that one 😉

This tip is much appreciated!

Under scripts, there is a .go source file that generates shell completions. Could be useful for packaging.

Yes, that's a feature users often request :-) Thank you for the tip.

If you have any suggestions for reorganisation of the repo structure that might aide packaging, please let me know, preferably in a separate issue. The code is a mess and so is the repo. I started this project three years back, the summer before uni, it shows...

Ok, I'll let you know as soon as I think of something. I'm still very new to Golang so unfortunately can't offer an example of a repo to model yours on.

To clarify, you're not packaging rubish. The parser is backed by unit tests so although it's messy that part is pretty stable. I might write a more detailed report of code quality.

At any rate, thank you for wanting to package Wrap. Having your code being packaged in Debian is quite the honour. 🙂

You're welcome :-) I'm sorry it took me so long to find Wrap, because it don't want to stress you with Debian deadlines. If it Wrap doesn't make it into buster (Debian 11), there's always the next release. BTW, currently I'm blocked by https://github.com/signintech/gopdf/issues/154

Other than that gopdf issue, and the CSS via CDN issue, I'm not aware of any other blockers at this time ( as of 0943226b1f78a61a39d44134f40c15356192f1be ).

Best, Nicholas

eprovst commented 3 years ago

@sten0 CSS is now embedded.

I'll wait a couple of days to see if any issues pop up and will then make a release. There are some other features (see the roadmap) that might or might not land before Christmas but the bare minimum has been reached :slightly_smiling_face:

[Edit: v0.3.1 has been released!]

eprovst commented 3 years ago

@rnkn Could you split up the other feature requests in this thread to separate issues? That makes tracking them a bit easier.

Mainly 'modern scene headers' and 'snippets mode' remain I think, I'll consider this one as 'page sizes'. :slightly_smiling_face: