Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: Implement a non breaking way for page locking. #143

Open
exjaynine opened this issue Mar 24, 2024 · 8 comments
Open

Suggestion: Implement a non breaking way for page locking. #143

exjaynine opened this issue Mar 24, 2024 · 8 comments

Comments

@exjaynine
Copy link

I have a proposal. There is no built in means in the spec for page locking, but what if we allowed pages to be 'locked' that won't break things in other editors. Any page that needs to be locked, add a boneyard directly next to the page break === or the scene such as /*Locked*/ literally spelt that, and it can renumber everything following scene 2 as 2A, 2B, 2C.

@rnkn
Copy link
Owner

rnkn commented Mar 25, 2024

Something like this? https://groups.google.com/g/fountain-dev/c/W_cAivCNhIk

@ghost
Copy link

ghost commented May 21, 2024

Something like this? https://groups.google.com/g/fountain-dev/c/W_cAivCNhIk

How would that work with fountain-mode?

@rnkn
Copy link
Owner

rnkn commented May 24, 2024

How would that work with fountain-mode?

At the moment the only implementation is that the page break regular expression allows for the forced page break:

=== 7 ===

So calling fountain-forward-page (C-x ]) will stop at that page page break.

There are two functionalities yet to be implemented:

  1. When the script has forced page breaks we want to be able to navigate to the correct page, e.g. given the above when navigating to page 8, point should go to one page after the forced page break.

  2. Correct page numbering when calling fountain-export. (n.b. I can't control how external programs will handle page breaks with fountain-export-command.)

The reason I haven't implemented this is that although I feel like we reached a consensus for the syntax on the fountain-dev mailing list, the syntax was never officially adopted. And John seems to have moved away from an official spec with Highland. I'm not sure what the story is here and I don't really want to push.

If the response I get from #144 is positive I will try again to get forced page numbering adopted in other Fountain apps.

I've added the original suggestion and relevant feedback here: #145

The question of how this will permit page locking, I think if X- headers are adopted, we simple insert forced page breaks then add one of the following:

X-Locked: yes
X-Fountain-Mode-Locked: yes
Locked: yes

@ghost
Copy link

ghost commented May 24, 2024

How would that work with fountain-mode?

At the moment the only implementation is that the page break regular expression allows for the forced page break:

=== 7 ===

So calling fountain-forward-page (C-x ]) will stop at that page page break.

There are two functionalities yet to be implemented:

  1. When the script has forced page breaks we want to be able to navigate to the correct page, e.g. given the above when navigating to page 8, point should go to one page after the forced page break.
  2. Correct page numbering when calling fountain-export. (n.b. I can't control how external programs will handle page breaks with fountain-export-command.)

The reason I haven't implemented this is that although I feel like we reached a consensus for the syntax on the fountain-dev mailing list, the syntax was never officially adopted. And John seems to have moved away from an official spec with Highland. I'm not sure what the story is here and I don't really want to push.

If the response I get from #144 is positive I will try again to get forced page numbering adopted in other Fountain apps.

I've added the original suggestion and relevant feedback here: #145

The question of how this will permit page locking, I think if X- headers are adopted, we simple insert forced page breaks then add one of the following:

X-Locked: yes
X-Fountain-Mode-Locked: yes
Locked: yes

Interesting, if this does go through, does that mean revision colors are also a possibility?

@rnkn
Copy link
Owner

rnkn commented May 25, 2024

Interesting, if this does go through, does that mean revision colors are also a possibility?

Kinda depends on how you see that working. Do you mean just syntax highlighting or something semantic to the content?

Btw upon a closer read of the spec it turns out the X- header idea is redundant; any unknown header is supposed to be ignored.

@rnkn
Copy link
Owner

rnkn commented Jun 10, 2024

How would that work with fountain-mode?

I realise I didn't really respond to this. The pagination logic is already there, it's how the fountain-export-troff paginates before converting to troff, essentially going through the script and inserting page breaks where appropriate. You can try it yourself with:

(goto-char (point-min))
(while (< (point) (point-max))
        (fountain-move-forward-page)
        (unless (eobp)
          (fountain-insert-page-break)))

It's just a matter of me implementing the user-facing parts.

@ghost
Copy link

ghost commented Jun 25, 2024

If I could add to the revision marks discussion, textplay uses diff files for adding in what to consider a revision mark and when converting to HTML or PDF, it colorizes that.

@rnkn
Copy link
Owner

rnkn commented Jun 27, 2024

@sattelitecr as far as the internal PDF export via Troff goes, Troff has the request .mc which puts a character in the right margin, e.g. *, so it's doable. I think it will be a case of doing a diff between two buffers, stripping out the deleted lines and putting text properties of the added lines, then wrapping these lines in the .mc request on export. I just have to get around to doing it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants