Updated with new CSS for print -- (previously 1.92.2 Right hand asterisks slightly off for dialog)

ftolsson commented 2 years ago

Just discovered that right hand asterisks for dialog are a bit off -- am I guessing correctly if I think there might have been some change made to page margins in the last (1.92.2) version? If I fire up 1.91.9 -- for which I made the changes to the CSS -- all asterisks line up nicely. So something is not the same between versions.

I'd love to help fix this -- but unfortunately it seems I'm not allowed to change files inside an AppStore distributed app package. So not sure how to be of help here.

(Also, interestingly, while in 1.91.9 asterisks are aligned the same for both USLetter and A4, I now find that in 1.91.9 they are even more off for USLetter. I suspect this may be related to the incorrect swapping between sizes some versions back, so that in the old version I'm actually looking at an A4 page no matter what size I choose...? Regardless, there probably needs to be a special value for .changed when page size is USLetter -- if there is a way to make the CSS aware of that. Let's talk more about this and see if I can be of help.)

lmparppei commented 2 years ago

I'll supply a development build for fixing this. Thank you for catching it.

lmparppei commented 2 years ago

I've now also added .us-letter body class for exports.

ftolsson commented 2 years ago

Attaching revised (and now updated) PrintCSS.css here:

(file replaced with newer version in post below)

I've done some major changes, so please help me test this. See list of caveats at the bottom.

In my mind, though, these changes open up for a much cleaner and consistent way to define the script page. I have done away with the tweaking of pixels -- which felt wrong dealing with what should be a quite predictable layout of monospaced letters and nothing else -- and also tried to collect all actual indents and widths in variables near the top.

Going forward, I'm wondering if these changes could make their way back into the preview (and edit view?) for maximum consistency. Assuming you like the result, of course.

Most notable changes:

Typography:

instead of measuring fonts in em, now measure fonts in pt (more specifically 12pt because that's what we want in the end anyway)
changed previous character-to-lineheight ratio of 0.95em/1.05em to 12pt/13pt
some elements even had top margins (empty lines) of 1.1em, they too were set to 13pt for consistency
now measuring all relevant widths in ch, thus able to exactly set an element width to arbitrary number of characters

Page layout

fit active layout inside page size minus left and right margins of 50pts respectively, so as not to shrink page
then fooled WebKit (don't tell anyone) by moving section tag 20pt left, allowing for some overflow to the right of the content (for positioning of asterisks outside of section but still inside printable area). Phew.
Also widened scene header to align page number with right margin of action etc

Element formatting

added box-sizing: border-box to make sure padding stays inside elements' width instead of adding to them
made all elements take up full width of page -- thus allowing asterisks to always go on right: -32px regardless of element type
thanks to the above, changed to defining indents for element types through padding instead of margins
ditched the traditions in one case: for dual dialog, asterisks appear to the left in case changes were made to the left hand dialogue. Made sense to me, but reasonably easy to change to standards if we don't like.

Possible caveats:

I have been careful to compare the editing window line breaks with the produced print/pdf, and even if I have found no anomalies we should test this thoroughly
One important exception: dual dialogue. Since the left dialog does not re-format at all on-screen (and the right dialog takes up more than half of the screen) I have had to simply assign half of the available area (minus some small space for margins) to each. I am afraid this may cause pages with dual dialog to overflow into almost-blank, un-numbered pages with an orphan line of text or two.
While I have not been able to see it, we should also make sure my 13pt line height does not mean that some printed pages can't fit all the lines the paginator throws onto them (although it should probably rather mean the opposite given the old values)
With revision marks on, if a scene heading is marked as changed, the asterisk will somehow cancel out the right-hand scene number
And, finally, of course: Let's make sure you like the result.

ftolsson commented 2 years ago

New version:

PrintCSS.css.zip

After some quite thorough testing, I settled for a line height of 12.5pt throughout. Weirdly, if importing the resulting pdf to Affinity Publisher, this corresponds to a line height of 12.2pt, but so be it — the result closely matches Beat's previous versions (as well as Final Draft, for what it's worth).
I have not made changes to the title page part, so that still uses percentages and em — didn't want to start mending anything that wasn't really broken.
Would love to update the CSS for the preview (ScriptCSS.css, right?) -- can I just transfer the affected classes over there or does that css need special treatment?

lmparppei commented 2 years ago

Thank you!

Would love to update the CSS for the preview (ScriptCSS.css, right?) -- can I just transfer the affected classes over there or does that css need special treatment?

That CSS is a bit different and everything is a mess. You can try, but the values are a bit different, because of reasons I won't permit myself going into right now.

ftolsson commented 2 years ago

And reasons, who can argue with them!

Followup question then — when paginating, does Beat take into account any css, or will it just line/page break based on the maximum permitted amount of characters each element is allowed to have?

I'm hoping it's the latter, and thinking that if so I could probably move over most of the stuff and get quite a reliable preview.

Having ditched all the percentages and other relative stuff, I feel quite confident things are going to be a whole lot easier now. But we'll see -- I'll get going and see where I end up.

ftolsson commented 2 years ago

That CSS is a bit different and everything is a mess.

Well, only slightly different if you ask me. It was not perfectly mess-free, I'll give you that, but I think I got most of it. And what I couldn't figure out what it was for, I left alone.

Anyway, here's a first version to try out! I'm almost certain there's something I've missed, but on first look I must say I think this works pretty well.

ScriptCSS.css.zip

AND ON THAT NOTE, may I propose the following?

Seeing how similar the two are, and how I've re-used most of my code from PrintCSS, would it be all bad to base both on the same CSS? Like, when opening the Preview Pane, we would

first apply the PrintCSS.css to the preview pane, and
then apply a minimal ScriptCSS (or rather a PreviewPaneExtrasCSS.css) on top of it -- with only the changes necessary

That way, any fix to the printCSS would immediately reflect in the preview without having to hunt differences down in both places (and vice versa).

ALSO, as a side note:

To make my preview roughly the same size as your old one, I used the non-standard (but supported by webkit) zoom: 70% inside the body tag. That got me thinking: As far as I can tell, we've never been able to zoom in the preview pane -- but this opens up for that. If you were to add zoom classes to the body tag in the preview pane (like .zoom100, .zoom120, .zoom140 etc) and allowed us to cycle them with cmd + and cmd - then we could easily just add a bunch of body.zoom100 {zoom: 100%} to the additional css for the preview pane.

Not super-super-important, but a little quality-of-life improvement. Just a thought.

lmparppei commented 2 years ago

Seeing how similar the two are, and how I've re-used most of my code from PrintCSS, would it be all bad to base both on the same CSS? Like, when opening the Preview Pane, we would

This is a very sensible suggestion, and I've thought about it, have never had the willpower to do so. Every day there is food to be cooked, TV series to be watched and sleep to be slept — and fixing my previous mistakes while learning from them is often not something I like to do. Thank you for looking into this.

To make my preview roughly the same size as your old one, I used the non-standard (but supported by webkit) zoom: 70% inside the body tag. That got me thinking: As far as I can tell, we've never been able to zoom in the preview pane -- but this opens up for that. If you were to add zoom classes to the body tag in the preview pane (like .zoom100, .zoom120, .zoom140 etc) and allowed us to cycle them with cmd + and cmd - then we could easily just add a bunch of body.zoom100 {zoom: 100%} to the additional css for the preview pane.

A good idea. I tried something like that, but never got it working. I'd just need to make the close button a native one, rather than being inside the HTML.

Basically:

const zoomLevels = [".zoom-60", ".zoom-70", ".zoom-80", ".zoom-90", ".zoom-100"]

function zoomIn() {
    const classes = document.body.classList
    let currentZoom = ""
    let defaultZoom = "zoom-70"

    for (let class of classes) {
        if (class.indexOf("zoom-") {
            currentZoom = class
            break
        }
    }

    if (currentZoom = "") currentZoom = defaultZoom
    document.body.classList.remove(currentZoom)

    const i = zoomLevels.indexOf(currentZoom)
    if (i + 1 < zoomLevels.count) document.body.classList.add(zoomLevels[i+1])
}

lmparppei commented 2 years ago

As for PrintCSS.css there are some issues.

For one, title page doesn't show up correctly:

Original:

New:

It drops Version field completely, and the page contents seem to have been shifted a bit right, not being centered anymore.

lmparppei commented 2 years ago

OH! And I just read your comments on top of the file, and would just like to add that Beat adds the print margins, because of historical reasons. Crypto-historical. The whole system is very complicated, and I've always tiptoed on the brink of destruction and end of Beat as we know it. Your trick to overcome the issue is clever, but probably causes the issues with title page.

However, I fixed the title page now. See the latest commit 029e30aa6810447b4136e21250130db2dd13b611.

ftolsson commented 2 years ago

You are right, I never touched the title page and didn't think about how that would shift it incorrectly.

Also (5 minutes later) -- You beat me to it, I was just sitting with the title page stuff right now! Out of curiosity -- what did you do to fix it? (everything in that changed file is green so hard to track... :)

My thinking, anyway, is that the less use we make of margins, the better -- I get a feeling that margins and paddings have been sort of used interchangeably. With box-sizing: border-box in one of the css-files (the non-printing one, if I recall correctly) but not the other, I can see how some changes may have led to frustration as they don't have the same effect in one file as in the other. Correct me if I'm assuming stuff.

But anyways, I think that would be one of the big advantages of using the same css and then just add some overriding code that needs to be different in the preview pane.

ftolsson commented 2 years ago

Beat adds the print margins, because of historical reasons.

OH: so the 50pt + 50pt margins are not Apple's fault?

lmparppei commented 2 years ago

This is what was changed, with some cleanup vs. the actually committed css:

#script-title * { white-space: pre-wrap; padding-left: 0;  }
#script-title {
    overflow: hidden;
    position: relative;

    margin: 0;
    padding: 0 0 2cm 0;
    height: 23.5cm;

    display: flex;
    flex-direction: column;
    justify-content: center;
    align-items: center;

    position: relative;
}

.a4 #script-title {
    height: 26.0cm;
}

Margins are probably not Apple's fault, but rather mine. BeatPaperSizing adds those to be consistent with some other stuff.

ftolsson commented 2 years ago

Got it -- so it seems you canceled some inherited left padding, which is what I was doing too.

Well, if you DO feel like balancing on the brink of Beat-armageddon, maybe narrowing those margins wouldn't be all bad (assuming that doesn't cause other problems).

Below behold some massive geekery:

Black is the current, new css
Red is previous css (no stars added, since they go to the left anyway)
Blue is Final Draft.

My conclusion is then: If you could reduce the shrinkage-begins-here margin on the right side only by 12pt (to 38pt rather than 50pt) then we could move the entire content accordingly and land on the exact same "industry standard" (sigh) margins and indents. (Not that I think anyone will object, but we are after all 7mm closer to left edge than stipulated.)

lmparppei commented 2 years ago

I will post a dev build with reduced margins to Discord.

ftolsson commented 2 years ago

Cool! By how much?

If I did my homework correctly, we will now only need to change one or two variables in the body tag (and the margin-left in section).

Looking forward!

lmparppei commented 2 years ago

Or I could of course make the left margin be 50+12?

ftolsson commented 2 years ago

Oh. Maybe. Might that cause other problems? I need to think now... which doesn't come naturally for me...

lmparppei commented 2 years ago

Let's start with 50 then!

ftolsson commented 2 years ago

Let's. It doesn't matter all that much I think. The only thing that springs to mind: We need to be vigilant about the title page, and the centered text there, now that there are different margins on either side.

lmparppei commented 2 years ago

Padding on the right-hand side should do it, though.

#script-title * { white-space: pre-wrap; padding-left: 0;  }
#script-title {
    overflow: hidden;
    position: relative;

    margin: 0;
    padding: 0 12pt 2cm 0;
    height: 23.5cm;

    display: flex;
    flex-direction: column;
    justify-content: center;
    align-items: center;

    position: relative;
}

ftolsson commented 2 years ago

Hey, you moved the CSS for the stars, right?

Actually, I think everything looks brilliant -- except MAYBE if we may want to move the left margin of screenplay elements some 75pt to make it line up with Final Draft. MAYBE.

Blue: Final Draft Red: Current developer build of Beat Black: My proposed 75pt move rightwards of screenplay text. (Leaving stars and scene numbers in their current red position).

This is reaaaally nitpicking and pixel peeping now, if it were down to me I'd say the current look is pretty darn great too. (And there will still be differences between the two -- Final Draft squishes in two extra characters into the same space, so that's ugly -- but we're getting closer. As close as we want to, I'd add.)

lmparppei commented 2 years ago

I didn't do anything else, I guess the stars just moved along with the margin. We can have zero margin, too, if needed. The main question here is if the line length has changed since the previous CSS, but maybe not?

ftolsson commented 2 years ago

Huh. This is interesting though -- just removing the margin-left: -20pt for section made the content shrink again. That surprised me.

So, I've tweaked a little!

I'm not changing number of characters that go into a line, of course, that's fixed so that the paginator can do its work.

What I have done stops at two things:

moved stars 20pt left (so .changed::after now has right: -12pt;
moved left scene numbers 20px (okay, so shoot me for using pixels now) left (so .scene-number-left now has -70px)

This works great (and now looks exactly like "industry standard") until...

...until I decided to make a test print without stars -- because then the right-hand scene-numbers turn on and cause the page to... yes, wait for it: SHRINK.

Is that shrinkage because of the margin you imposed, or because of webkit itself? If it's your margin, then some more space would be great in order not to have right-hand numbers collide with the scene heading text for long headings...

lmparppei commented 2 years ago

I think it's caused by this:

.scene-number-right {
    position: absolute;
    right: -4ch; 
    top: 0;
}

Because the heading is not limited in any way (maybe it should have margin-left: 4ch;?) WebKit extends the page 4 characters and fits it on paper. So, either the scene headings have to be a bit less wide, or just set right: 0; and we'll just make it work somehow.

ftolsson commented 2 years ago

But the actual scene number is flush right, so when it grows it grows left-wards.

So it really feels counter-intuitive that the scene number should be causing more problems than the asterisk, seeing as they overflow equally much...

ftolsson commented 2 years ago

Scrap that. I'm being stupid inside my head. Wait a sec. I'll be back.

ftolsson commented 2 years ago

You're right -- let's keep the scene number inside the margin.

Two problems that we may not be able to shake:

Scene heading with changes will not get a right hand number (can't seem to fix that with css, down't know why)
Loooong scene headings will overwrite the right hand scene number (because of css, number now moved more to left).

But outside of that, I think this is looking quite splendid.

lmparppei commented 2 years ago

At the moment, right-side scene number is removed in code, if line.changed = true. I'm a bit worried about the fact that it gets overimposed. Maybe set padding-right: 4ch; for headings? It will require some minor tweaks to pagination engine, though, but nothing too dramatic.

ftolsson commented 2 years ago

Ah, well that explains it!

Well, sure, if you tell the paginator to stop sceneheadings sooner (at least if scene numbers are multi-digits?) then that sounds like a good thing.

Also, let's not forget that I don't think the paginator knows the current status of dual dialog -- my worries are more about that pages with dual dialog will spill over to an un-numbered page because it doesn't fit.

Anyways. These are my four changed values for now:

section {
    margin-left: 0pt;   /* so yes, my hack is no more. */
}

.scene-number-left {
    margin-left: -70px;  /*was 50, now has same spacing as industry standard*/
}

.scene-number-right {
    right: 0ch;  /* was -4, but this was the last thing we discussed*/
}

.changed::after {
    right: -12pt;  /* was -32, but moved it back to correspond to removed 20pt hack in section.
}

ftolsson commented 2 years ago

And add to that

.scene-heading{
    padding-right: 4ch; /*was nil, but added not to collide with scene numbers*/
}

ftolsson commented 2 years ago

If you're happy with that, here's the file.

PrintCSS.css.zip

The only thing we need to do with the ScriptCSS.css at this point would be to add the section with padding for scene heading, the rest is just about moving stuff around on the page.

And if at some point you'd load PrintCSS.css + fileWithOverrides.css for the preview pane, I'll be happy to jump in and help with the overrides.

ftolsson commented 2 years ago

Also, on a completely unrelated noted: YAY with the tabs! That works just great, and with the outline switching alongside -- that's perfectly wonderful!

That's a keeper if you ask me! (or an option in settings for the less happy? In the event there will be any.)

lmparppei commented 2 years ago

SOS, have you encountered problems with pagination and dual dialogue? Could you post an example?

ftolsson commented 2 years ago

Have not. But I also could not make heads or tails of the old rules, so I'm sure that I have broken them.

Let me fiddle some.

lmparppei commented 2 years ago

Ah. Well, you shouldn't break anything if you are not making the dual-dialogue paragraphs less wide.

And if at some point you'd load PrintCSS.css + fileWithOverrides.css for the preview pane, I'll be happy to jump in and help with the overrides.

This is pretty much in place already, I moved HTML into two separate files (header & footer): https://github.com/lmparppei/Beat/blob/master/Beat/Export/HTML/HeaderTemplate.html https://github.com/lmparppei/Beat/blob/master/Beat/Export/HTML/FooterTemplate.html

I just need to figure out some minor things about UI-side. Let's look into it in the next version.

ftolsson commented 2 years ago

So my thinking is that if we're really unfortunate, at some point it wouldn't surprise me if the paginator made mistake on dual dialogue (depending of course on if perhaps you've been really clever in advance).

See the dialogues below -- the way they look in the editor window and the print preview -- same number of lines in print but not in the editor. Might that lead to bad things in the long run?

lmparppei commented 2 years ago

Ah, I see. Well, the paginator doesn't care about the editor at all — it doesn't actually care about anything in this materialistic and visible realm. It only sees the lines, and figures out how much stuff can theoretically be put on a page. And what's worse, there is no actual page it puts stuff on, it operates solely based on digital imagination. And what's worst, it's all calculated using very hazy modifiers, and the actual pixel/point values between CSS and paginator don't match up at all.

This could all perhaps be fixed now that you've made some alterations to the CSS, as I'm guessing the zoom style is the modifier now.

ftolsson commented 2 years ago

Well, that's what it tells you now, but at some point the paginator will find the taste for fame and money and move to Hollywood and leave you behind with debts and mortgages and all the other things it dismissed as unimportant back then.

Um... Anyway.

So actually, what I was hoping to do was to put as firmly into the css as possible that everything (if you and the paginator agree) is based on number of characters and nothing else. If we all agree on the width in number of characters for each element and what number of lines can go on a page, then pixels and measurements and layout are obviously nothing but some worldly construction for us to obsess over.

But that's where I worry that I have back-engineered (a very un-engineery feat, but still) most of the widths -- clearly readable in the variables, so easy for you to check if I'm wrong -- with the exception for dual dialog.

(My assumption was that the editor window somehow took hints from the paginator -- especially now that the editor and the print window quite consistently seem to wrap lines the same way. But if not -- perhaps the easiest way to make sure we don't break anything is if I go back to some previous version and just check the numbers of characters for dual dialog there, pre- my dipping my fingers into the css. Right?)

lmparppei commented 2 years ago

Dialogue character counts are correct, as far as I can see. I'll post a dev build.

ftolsson commented 2 years ago

And to keep stuff reasonably much in one place, here is the ScriptCSS.css file too.

ScriptCSS.css.zip

includes the changes we made to PrintCSS, plus three things making the text better vertically aligned in the preview:

section {

...

height: var(--page-height);     /* for consistent page size */
/* padding-bottom: 6em; */      /* commented out because gave crazy much white at the bottom */
padding-top: 4em;               /* increased from 2em to center text a little bit better */
}

lmparppei commented 2 years ago

This CSS has been included in the latest build too. In 1.92.4 I'll streamline styling, so if you could already create a separate file with isolated preview styles, that would be great!

ftolsson commented 2 years ago

(You're really increasing fractions of fractions now to avoid the expectations of a 2.0, don't you...) :)

Sure thing, I'll take a look!

lmparppei commented 2 years ago

(You're really increasing fractions of fractions now to avoid the expectations of a 2.0, don't you...) :)

You caught me here.

lmparppei commented 2 years ago

So, I've changed the thing so that there are two files:

ScreenplayStyles.css PreviewStyles.css

The former gets loaded in every case, while the latter is only appended for print preview.

ftolsson commented 2 years ago

In the current App Store version already? Or in next one?

ftolsson commented 2 years ago

Here's one to try out then -- renamed and all...:

PreviewStyles.css.zip

I removed everything that wasn't unique to the ScriptCSS file (i.e. that was doubled) but there were some question marks that made me insecure... Some things were unique (so I left them in) but I really felt unsure whether they really should be. Primarily for dual dialogue, but there ware also some more things that I forget now.

Anyways, and bottom line, it needs some testing before going live.

lmparppei commented 2 years ago

Something isn't working. This might happen on code-level, too, but I'm not sure.

ftolsson commented 2 years ago

What are we looking at?

Is this the preview thing I sent yesterday?

lmparppei commented 2 years ago

Yes, that's with the screenplay CSS + preview CSS loaded.

lmparppei / Beat

Updated with new CSS for print -- (previously 1.92.2 Right hand asterisks slightly off for dialog) #88

Most notable changes:

Possible caveats: