Support different page sizes #39
Comments
|
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:
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 🙂 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! 🙂 Which reminds me to leave some code quality disclaimers in some modules. The parser is fairly ugly for instance... |
|
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. |
|
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. |
|
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! |
|
Another vote for some formatting. Even just something like --bold-scenes. Again, thank you for such a wonderful tool! The scene numbering is *chef's kiss. Just missing my bold scene headings ;) |
|
@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 :-) |
|
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 🙂 |
|
@sten0 what's the timeline for Debian feature freeze? Also, does |
|
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...) 🙂 |
|
Hi Evert,
Evert Provoost <[email protected]> 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...) 🙂
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
|
|
Hi Paul,
"Paul W. Rankin" <[email protected]> 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
|
|
@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. 🙂 |
|
Hi Evert,
Thank for the quick reply, and sorry for the delay in mine.
Evert Provoost <[email protected]> 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 signintech/gopdf#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
0943226 ).
Best,
Nicholas
|
|
@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 🙂 [Edit: v0.3.1 has been released!] |
|
@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'. 🙂 |
eprovst
changed the title
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:
The text was updated successfully, but these errors were encountered: