stylesheet for screenplays - @page example ?

[David J Patrick]

I'm trying to rewrite the CSS used in
http://s92415866.onlinehome.us/files...playCSSv2.html.
using the w3.org paged media standards as described at
http://www.w3.org/TR/REC-CSS2/page.html

The ScreenplayCSS is flawed, for several reasons;
-overuse of <div id= tags
-doesn't scale screen resolutions (convert from px to in, pt ?)
-no media="print" (how much coule be shared between "screen" & "print")
-no automatic page breaks (with automatic numbering ?)

The "hollywood" screenplay format is well defined
(http://www.online-communicator.com/faq20_5.html)
Is it possible to drive a consistant printout, from html, with CSS ?
Does anyone have suggestions for improvement of the above ScreenplayCSS ?
How about an example of a page that uses the @page definition ?
thanks !
djp

[David J Patrick]

I would also appreciate any pointers to existing screenplay stylesheet/
schema. I have seen hints of screenplay XML structures, but, as yet, no
implimentation.

[Tim]

On Sat, 19 Jun 2004 12:36:29 -0400,
David J Patrick <da***********@sympatico.ca> posted:

I'm trying to rewrite the CSS used in
http://s92415866.onlinehome.us/files...playCSSv2.html.
using the w3.org paged media standards as described at
http://www.w3.org/TR/REC-CSS2/page.html

The ScreenplayCSS is flawed, for several reasons;
-overuse of <div id= tags
-doesn't scale screen resolutions (convert from px to in, pt ?)
-no media="print" (how much coule be shared between "screen" & "print")
Pt should be fine for printing, but not for the screen. You're probably
best not to make font specifications in the screen styling (that's normal
advice, but I'd say even more so if you want to submit something long for
someone to read that might earn you a job - remove all obstacles that make
browser reading a pain).
-no automatic page breaks (with automatic numbering ?)

Is it possible to drive a consistant printout, from html, with CSS ?

This sort of thing, and what browsers typically do when printing (add their
own footers and headers) are some of the reasons that you'd probably not
want to print such things from a web browser.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

[David J Patrick]

On Sun, 20 Jun 2004 21:42:06 +0930, Tim wrote:

Pt should be fine for printing, but not for the screen.
would "in" be the most portable ? that's what the screenplay format is
usually describe in, anyhow.

You're probably best not to make font specifications in the screen
styling... remove all obstacles that make browser reading a pain).

It's important to mimic the look, and especially page count, of a script.
I see the more rigid screen definition as a colaborative/ preview tool.
A reader who can give your project the "green light" will be reading
a printout, and it had better adhere to specs. I agree that there should
be a style-free mode though. another CSS definition; media="screen-free" ?

-no automatic page breaks (with automatic numbering ?)
Any clues how to use @page, break rules and numbering ?
Can you see a better way to define the ScreenplayCSS page ?
Is it possible to drive a consistant printout, from html, with CSS ?

...you'd probably not want to print such things from a web browser.

That makes sense, I have noticed, however a distinct lack of "html2pdf"
avalable for linux. If I can "force" a reliable printout, from html,
that would be great.

[Christoph Paeper]

*David J Patrick* <da***********@sympatico.ca>:

On Sun, 20 Jun 2004 21:42:06 +0930, Tim wrote:

Pt should be fine for printing, but not for the screen.
would "in" be the most portable ? that's what the screenplay format is
usually describe in, anyhow.

Maybe I confused you with my reply to your previous thread. If you want to
follow the format as close as possible, use the units it uses. ('pt', 'pc',
'in', 'cm' and 'mm' are all convertible into each other, though.) But that's
only useful if done for a specific medium like IIRC 8½" × 11" paper in this
particular case, media="print" that is. For all other media including
'screen' relative units ('em', 'ex' or '%') are the way to go.

You're probably best not to make font specifications in the screen
styling... remove all obstacles that make browser reading a pain).

It's important to mimic the look,

The look is mainly determined by a monospaced font, some uppercasing,
indentation and centering. Do you really want to resemble the ugly layout on
screen, too? You know, the format is not well readable, it's just what
Hollywood is used to.
and especially page count, of a script.
The example you presented had each page in a separate 'div', so that would
be trivial. Otherwise paged CSS is far from perfect.
I see the more rigid screen definition as a colaborative/ preview tool.
That's what Print Preview is for. You're missing the opportunities the
technology gives you, just as Hollywood did by sticking to typewriter layout
(not to mention that horrid paper sizes and hole positions).
A reader who can give your project the "green light" will be reading
a printout, and it had better adhere to specs. I agree that there should
be a style-free mode though. another CSS definition; media="screen-free" ?
That would be accomplished (somehow) by providing differing 'title'
attributes to the 'link' elements:

<link rel="stylesheet" type="text/css" media="print, screen"
href="hollywood.css" title="Hollywood">
<link rel="stylesheet" type="text/css" media="screen"
href="readable.css" title="readable">

-no automatic page breaks (with automatic numbering ?)
Any clues how to use @page, break rules and numbering ?

Sadly the spec has no definite solution for that and most browsers don't
even support the bits the spec does have (correctly).

Is it possible to drive a consistant printout, from html, with CSS ?

...you'd probably not want to print such things from a web browser.

I know people who only use HTML+CSS for all their printed correspondence,
but they are of course in control of everything from source code to printer
settings.
If I can "force" a reliable printout, from html, that would be great.

There are specialised programs like YesLogic Prince
(<http://yeslogic.com/prince/>), but I doubt that is what you want. There
are also projects to generate many different outputs (HTML, PDF, ...) from a
single source document, e.g. XML based tbook
(<http://tbookdtd.sourceforge.net/>).

--
"I didn't have the time to write a short letter, so I wrote a long one instead."
Mark Twain

[David J Patrick]

On Sun, 20 Jun 2004 18:46:27 +0200, Christoph Paeper wrote:

If you want to
follow the format as close as possible, use the units it uses. ('pt', 'pc',
'in', 'cm' and 'mm' are all convertible into each other, though.) For all other media including
'screen' relative units ('em', 'ex' or '%') are the way to go.

Do you really want to resemble the ugly layout on
screen, too? You know, the format is not well readable, it's just what
Hollywood is used to.
I think it's very important to cough up that ugly look as accurately as
possible. At the same time an alternative, more readable, stylesheet would
be great.
The example you presented had each page in a separate 'div', so that
would be trivial. Otherwise paged CSS is far from perfect.
The example requires fully manual paginatio, which IMHO is out of the
question.

I see the more rigid screen definition as a colaborative/ preview tool.
That's what Print Preview is for.

That's an interesting point.
You're missing the opportunities the technology gives you,
Do you think offering an alternative would be a big deal ?

I agree that there should
be a style-free mode though. another CSS definition;
media="screen-free" ?

That would be accomplished (somehow) by providing differing 'title'
attributes to the 'link' elements:

<link rel="stylesheet" type="text/css" media="print, screen"
href="hollywood.css" title="Hollywood">
<link rel="stylesheet" type="text/css" media="screen"
href="readable.css" title="readable">

Interesting.. I'm trying to imagine exactly how I would apply the above
example.

Any clues how to use @page, break rules and numbering ?

Sadly the spec has no definite solution for that and most browsers don't
even support the bits the spec does have (correctly).

I'm not completely whacked in thinking that this is the standard for this
sort of application, though, even if it's marginally supported. ?
What if it was decided that proper printout were a Mozilla 1.7+ only
thing, for example ?
I know people who only use HTML+CSS for all their printed
correspondence, but they are of course in control of everything from
source code to printer settings.

Something we can't presume. I'm also looking into XML, as an intermediary
file format and/or parsing the source file to LyX, for printout.
I'll follow up on the links you provided, thanks fer the feedback !
djp

[David J Patrick]

On Sun, 20 Jun 2004 18:46:27 +0200, Christoph Paeper wrote:

There are specialised programs like YesLogic Prince
(<http://yeslogic.com/prince/>), but I doubt that is what you want. Interesting but expensive .. not at all what I had in mind.

There are also projects to generate many different outputs (HTML, PDF, ...) from a
single source document, e.g. XML based tbook
(<http://tbookdtd.sourceforge.net/>).

Now this has some potential !
My instincts tell me that if the first step were to conform to a
ScreenplayXML (if such a thing existed) the next steps would be universal.
That is to say that the process would be more widely useful and allow
divergent development.

OTOH, If I could just cook up a decent CSS for the screenplay HTML I've
got going It would do the trick. I really should be writing my big movie,
instead of screwing around.. oh well .. can't help it ..

[David J Patrick]

here it is (for those who won't www)

<style type="text/css">
body{
/* body elements create a green field that's easy on the eyes.*/
margin:0px;
padding:0px;
background:#9BA882;
/* Note: Courier 10 Pitch BT is the "official" screenplay font. It MUST be installed on the computer used to view the pages made with this template. */
font:12pt "Courier 10 Pitch BT","Courier New";letter-spacing:-1px;line-height:1; /* Letter spacing corrects kerning (mostly) for Courier font family.
The line-height tag provides proper line spacing for the Courier font family. Courier 10 Pitch BT is free from Bitstream. */
}
/* the #header & #main divs butt together to create the whole page */
#header{ /* page number holder*/
text-align:right;
width:530px; /* 8.5 inch page */
height:45px; /* 11 inch page including #main */
padding:50px 100px 0px 100px; /* top,right,bottom,left internal margins */
margin:30px 100px 0px 130px; /* placement of #main on green field */
border-left:none; /* border elements create edges */
border-right:solid 2px #485235;
border-bottom:none;
border-top:none;
background:#ffffff; /* creates a white #header */
}
#main{ /* where all the text goes */
width:530px; /* 8.5 inch page */
height:850px; /* 11 inch page including #header */
padding:18px 100px 80px 100px; /* top,right,bottom,left internal margins */
margin:-19px 100px 30px 130px; /* placement of #main on green body, butts up to #header */
border-left:none; /* border elements create edges*/
border-right:solid 2px #485235;
border-bottom:solid 2px #485235;
border-top:none;
background:#ffffff; /* creates a white page */
}
#character{ /* sets the indent for the characteracter name in uppercase */
padding:10px 0px 0px 0px;
text-transform:uppercase;
text-indent:180px;
}
#dialog{ /* sets the dialog margins */
margin:0px 110px 0px 85px;
}
#paren{ /* sets the parenthetical margins, text in lowercase*/
text-transform:lowercase;
margin:0px 150px 0px 130px;
}
#action{ /* description text */
padding:10px 0px 0px 0px;
}
#slug{ /* used for scene sluglines */
text-transform:uppercase;
padding:23px 0px 0px 0px; /* provides proper line spacing */
}
/* The Latinized text below is used for demostration purposes only */
</style>

[Neal]

On Sun, 20 Jun 2004 18:16:25 -0400, David J Patrick
<da***********@sympatico.ca> wrote:

#character{ /* sets the indent for the characteracter name in uppercase
*/

An id? Will there only be one character-id'd element per document? An id
value can't be used more than once in a document...

[David J Patrick]

On Sun, 20 Jun 2004 17:37:33 -0400, Neal wrote:

On Sun, 20 Jun 2004 18:16:25 -0400, David J Patrick
<da***********@sympatico.ca> wrote:

#character{ /* sets the indent for the characteracter name in uppercase
*/

An id? Will there only be one character-id'd element per document? An id
value can't be used more than once in a document...

So I've been told.
The original author used id= for every element.
I'll be changing those to paragraph styles.

[Wolfgang Wildeblood]

David J Patrick <da***********@sympatico.ca> wrote:

The ScreenplayCSS is flawed, for several reasons;
-overuse of <div id= tags
Damn right, all those IDs should be classes. This won't bother the
CSS, but it's very broken HTML.

-doesn't scale screen resolutions (convert from px to in, pt ?)
-no media="print" (how much could be shared between "screen" & "print")

Not much. You go about it (screen and print formatting) two different
ways.

Take MyNovel.txt, for example. To print this as a "manuscript" to send
to a publisher you'd want a specific format:-

- A monospaced font giving exactly:
- 60 characters per line,
- 25 lines per page,
- 1500 characters (250 words) per page.

To achieve this in print you measure the size of the paper, deduct the
margins, then divide by 60 to get the font-size that results in 60
characters per line. Then set a line-height that results in 25 lines
per page.

But to get the same formatting on screen (i.e. line breaks in the same
places), you simply specify directly that you want 60 characters per
line.

p {
width: 60em !important;
margin: auto;
}

That's all there is to it; as usual for screen, no mention of
font-size at all. So the stylesheet just looks something like:

@media print, projection, screen {
* {
font-family: "Courier New", monospace !important;
line-height: 2;
}
}

@media print {
* { font-size: 12pt /* or whatever */ !important;
}

@media projection, screen {
p {
width: 60em !important;
margin: auto;
}
}

--
"He's a kind of super-criminal, he can travel through time and space."

[Neal]

On 20 Jun 2004 22:51:41 -0700, Wolfgang Wildeblood
<wo****************@yahoo.com.au> wrote:

But to get the same formatting on screen (i.e. line breaks in the same
places), you simply specify directly that you want 60 characters per
line.

p {
width: 60em !important;
margin: auto;
}

If only 1em = 1 character!

[David J Patrick]

On Sun, 20 Jun 2004 22:51:41 -0700, Wolfgang Wildeblood wrote:

You go about it (screen and print formatting) two different
ways.

To achieve this in print you measure the size of the paper, deduct the
margins, then divide by 60 to get the font-size that results in 60
characters per line. Then set a line-height that results in 25 lines
per page.
The cardinal rule of screenplay output is Courier 12pt. Knowing this,
would the page not be best defined in points ?
But to get the same formatting on screen (i.e. line breaks in the same
places), you simply specify directly that you want 60 characters per
line.
...or whatever each element definition calls for.. which is most often
described in inches from a margin.

p {
width: 60em !important;
margin: auto;
}
}
That's all there is to it; as usual for screen, no mention of font-size
at all. So the stylesheet just looks something like:

@media print, projection, screen {
* {
font-family: "Courier New", monospace !important; line-height: 2;
}
}
}
@media print {
* { font-size: 12pt /* or whatever */ !important;
}
}
@media projection, screen {
p {
width: 60em !important;
margin: auto;
}
}

And if I wanted to have TWO screen layouts (one rigid and one readable)
could I add

@media screen rigid {
* {font size: 12/1 !important;
}

Do you agree that the @page spec (and associated break & number rules) are
too unsupported to use ?

thanks Wolfgang,
djp

[David J Patrick]

On Sun, 20 Jun 2004 22:51:41 -0700, Wolfgang Wildeblood wrote:

David J Patrick <da***********@sympatico.ca> wrote:

The ScreenplayCSS is flawed, for several reasons;
-overuse of <div id= tags

Damn right, all those IDs should be classes. This won't bother the
CSS, but it's very broken HTML.

I know I'm exibiting my ignorance here, but in replacing those <div id=
tags I simply use;

..dialog{ /* . instead of # */
margin:0pt 110pt 0pt 85pt: /* actual pixel to point conversion to be
worked out */
}

and in the html
<p class="dialog">Words words words</p>

That simple ?

[Wolfgang Wildeblood]

Neal <ne*****@yahoo.com> wrote:

On 20 Jun 2004 22:51:41 -0700, Wolfgang Wildeblood
<wo****************@yahoo.com.au> wrote:

But to get the same formatting on screen (i.e. line breaks in the same
places), you simply specify directly that you want 60 characters per
line.

p {
width: 60em !important;
margin: auto;
}

If only 1em = 1 character!

That's the whole point of using monospaced fonts, Neal.

Just send your grovelling retraction on good quality paper suitable
for framing, okay?

--
"Join me, Doctor? We could rule together."

[Steve Pugh]

wo****************@yahoo.com.au (Wolfgang Wildeblood) wrote:

Neal <ne*****@yahoo.com> wrote:

On 20 Jun 2004 22:51:41 -0700, Wolfgang Wildeblood
<wo****************@yahoo.com.au> wrote:

> But to get the same formatting on screen (i.e. line breaks in the same
> places), you simply specify directly that you want 60 characters per
> line.
>
> p {
> width: 60em !important;
> margin: auto;
> }

If only 1em = 1 character!

That's the whole point of using monospaced fonts, Neal.

But 1em is still the height of the font, not the width of a character.

Try it for yourself.
<div style="width: 10em; font-family: monospace; padding: 0; border:
1px solid red;">1234567890</div>
See how much wider the div is than the text?
Just send your grovelling retraction on good quality paper suitable
for framing, okay?

I'm sure Neal looks forward to receiving that from you.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>

[Tim]

Tim wrote:

Pt should be fine for printing, but not for the screen.

David J Patrick <da***********@sympatico.ca> posted:

would "in" be the most portable ? that's what the screenplay format is
usually describe in, anyhow.

You're probably best not to make font specifications in the screen
styling... remove all obstacles that make browser reading a pain).

It's important to mimic the look, and especially page count, of a script.
I see the more rigid screen definition as a colaborative/ preview tool.
A reader who can give your project the "green light" will be reading
a printout, and it had better adhere to specs. I agree that there should
be a style-free mode though. another CSS definition; media="screen-free" ?
The problems stems from 12 point text on paper having a defined meaning
(it'll be the same size, no matter who printed it), but 12 pt text on a
screen doesn't have any standard rendering: It'll be different sizes on
different screens, and rarely the same size as 12 pt printed on paper.

There's that (difference in size), plus that 12 pt text (for instance) may
well be a completely unsuitable size for on-screen reading (it certainly is
here, even 14 pt is just acceptable, yet that'd be huge on paper).

Hence, why I said don't specify a font on screen. It's dead easy for most
browsers to adjust the display of text to suit the person reading it,
providing you haven't fixed the text to a specific size. Some browsers
will allow you to modify fixed font sizes, but many don't.

For the screen styling, stick to *simplistic* indenting, centering,
bolding, etc., as required by their expectations, and little more.

You can't mimic the page count on screen, as you don't have pages on the
screen. You have something analagous to a continuous roll of paper.

-no automatic page breaks (with automatic numbering ?)

Any clues how to use @page, break rules and numbering ?
You'll have to wait for browsers to be improved. Few have any decent sort
of support for those things. It's generally only the experimental ones
(e.g. Mozilla) that have any support for page media effects.
Can you see a better way to define the ScreenplayCSS page ?
Only as I'd already said before: Very little style rules for the screen
media, no absolute sizes or dimensions for anything. Use appropriate
typing rules for the print media. Though you're still going to be facing a
battle to find a browser that will carve a long HTML file into pages as you
want when you print it. Even worse, is hoping that anything you publish
can be handled as you want by someone else's browser (most people are using
crap browsers - if you believe the stats about MSIE being predominant,
which are probably true).
That makes sense, I have noticed, however a distinct lack of "html2pdf"
avalable for linux. If I can "force" a reliable printout, from html,
that would be great.

You probably want to look into a program designed for text manipulation (a
real word processor, not a desk top publisher). Probably something like
Tex or Latex (note I've never used them, merely read about them). In the
past, I've written programs for custom handling of text. It was easier,
for me then, than trying to find something ready made, and I had my source
material in a manageable format too (that's important).

There's no ability to "force" anything in WWW authoring...

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

[Tim]

Wolfgang Wildeblood <wo****************@yahoo.com.au> wrote:

But to get the same formatting on screen (i.e. line breaks in the same
places), you simply specify directly that you want 60 characters per
line.

p {
width: 60em !important;
margin: auto;
}

Neal <ne*****@yahoo.com> wrote:
If only 1em = 1 character!

Wolfgang Wildeblood wrote:
That's the whole point of using monospaced fonts, Neal.

Steve Pugh <st***@pugh.net> posted:
But 1em is still the height of the font, not the width of a character.

And... It's only a *width*, it doesn't mean 60 characters across the page,
it means fill the page with text to the width of 60 ems. You could well
have 70 characters across the page. Even with a monospaced font, each
character is still smaller than the width of an em (which has various vague
and contradictory definitions).

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

[Alan J. Flavell]

On Mon, 21 Jun 2004, Tim wrote:

The problems stems from 12 point text on paper having a defined meaning
CSS-specified 12 point text has that "defined meaning" *everywhere*.
The fact is, though, that typical browsers don't implement it.
(it'll be the same size, no matter who printed it), but 12 pt text on a
screen doesn't have any standard rendering: It'll be different sizes on
different screens, and rarely the same size as 12 pt printed on paper.

That's no fault of the pt unit as such. But even if all computer
displays were properly calibrated, it *still* wouldn't be the best
choice in a WWW context for a screen display.

So, to summarise: it's inappropriate for two reasons: 1. it mostly
doesn't work to specification, and 2. even if it -did- work to
specification, it wouldn't be the best choice, as a means of
communicating content to web readers.

However, in this special case it seems the author is trying to
visually reproduce the appearance of a paper document. That's a
special (and in some sense perverse - no offence intended) way of
using HTML, with or without CSS. I'm not sure what to suggest - *any*
choice is going to be a compromise. Possibly a reasonable choice
would be to provide a visual-reproduction in PDF, and an alternative
HTML-based version designed for accessibility to the content.

cheers

[Neal]

On 21 Jun 2004 02:12:17 -0700, Wolfgang Wildeblood
<wo****************@yahoo.com.au> wrote:

Just send your grovelling retraction on good quality paper suitable
for framing, okay?

Sorry it's been flushed ;)

[PeterMcC]

David J Patrick wrote in
<pa****************************@sympatico.ca>

I'm trying to rewrite the CSS used in
http://s92415866.onlinehome.us/files...playCSSv2.html.
using the w3.org paged media standards as described at
http://www.w3.org/TR/REC-CSS2/page.html

The ScreenplayCSS is flawed, for several reasons;
-overuse of <div id= tags
-doesn't scale screen resolutions (convert from px to in, pt ?)
-no media="print" (how much coule be shared between "screen" &
"print")
-no automatic page breaks (with automatic numbering ?)

The "hollywood" screenplay format is well defined
(http://www.online-communicator.com/faq20_5.html)
Is it possible to drive a consistant printout, from html, with CSS ?
Does anyone have suggestions for improvement of the above
ScreenplayCSS ? How about an example of a page that uses the @page
definition ? thanks !

Apologies if this is on the wrong track but Final Draft - which is pretty
much accepted in the industry - works to the "Hollywood" format and has a
"Save as html option" which I've never used until your post. So, I just
tried it - confidently expecting Word-style bloat. Because of the
constraints of the screenplay format, FD is able to simply output the entire
thing in <pre>. Perhaps that might point in a useful direction.

BTW, FD is available as a demo at http://www.finaldraft.com/

--
PeterMcC
If you feel that any of the above is incorrect,
inappropriate or offensive in any way,
please ignore it and accept my apologies.

[David J Patrick]

On Mon, 21 Jun 2004 12:32:27 +0100, Alan J. Flavell wrote:

However, in this special case it seems the author is trying to
visually reproduce the appearance of a paper document. That's a
special (and in some sense perverse - no offence intended) way of
using HTML, with or without CSS.
None taken ! Your absolutely right !
I'm not sure what to suggest - *any*
choice is going to be a compromise.

Yeah, as I see it now (and it's a moving target) I'd like to create a CSS
with three profiles;

1. (media="screen") a smooth flowing, readable version, with light
formatting and the users choice of font/ size. This (least formal) could
also feature a pure CSS menu to navigate the script, etc. If possible,
page breaks will be indicated, but not forced, based on a rigid layout.

2. (media="screen-rigid") this layout gives a visual page field (like
ScreenplayCSSv2) and adheres strictly print formatting
conventions even so far as to put shadows where the tree-hole-punch goes.

3. (media="print") same as 2. .. only more so !

If this can only be done consistently using one browser (Mozilla) SO BE IT !
It's freely available for you platform!
I realize that a lot of this flies in the face of conventional web wisdom,
perhaps that's why it's never been done. That doesn't mean it CAN'T be
done !

I would also like to develop a reliable method of converting to PDF, but
that it outside of the CSS mission.

Thanks for your interest and insight,
djp

[Chris Morris]

David J Patrick <da***********@sympatico.ca> writes:

On Mon, 21 Jun 2004 12:32:27 +0100, Alan J. Flavell wrote:

However, in this special case it seems the author is trying to
visually reproduce the appearance of a paper document. That's a
special (and in some sense perverse - no offence intended) way of
using HTML, with or without CSS.

I'm not sure what to suggest - *any* choice is going to be a
compromise.

Yeah, as I see it now (and it's a moving target) I'd like to create a CSS
with three profiles;

1. (media="screen") a smooth flowing, readable version, with light
formatting and the users choice of font/ size. This (least formal) could
also feature a pure CSS menu to navigate the script, etc. If possible,
page breaks will be indicated, but not forced, based on a rigid layout.

Okay.
2. (media="screen-rigid") this layout gives a visual page field (like
ScreenplayCSSv2) and adheres strictly print formatting
conventions even so far as to put shadows where the tree-hole-punch goes.
"screen-rigid" isn't a recognised media type, though. So browser
support will be non-existent, I think.
3. (media="print") same as 2. .. only more so !
Okay.
If this can only be done consistently using one browser (Mozilla) SO BE IT !
It's freely available for you platform!
I realize that a lot of this flies in the face of conventional web wisdom,
perhaps that's why it's never been done. That doesn't mean it CAN'T be
done !

Possibly what I'd suggest is:
Stylesheet 1: Media="screen"
Alternate Stylesheet 2: Media="screen"
Stylesheet 3: Media="print"

The alternate stylesheet implementation fails on page changes in every
browser I've seen that does it at all. But my impression of this is
that you intend it to be a single long file anyway, where that isn't a
problem.

Alternatively (and with more support in browsers) you could switch
between 1 and 2 using server-side scripting, which would be a better
solution, if you have server-side scripting available.

--
Chris

[David J Patrick]

On Mon, 21 Jun 2004 20:34:51 +0930, Tim wrote:

Tim wrote:

You can't mimic the page count on screen, as you don't have pages on the
screen. You have something analagous to a continuous roll of paper.
Yet it should be possible to represent pages, one after another (as in
http://s92415866.onlinehome.us/files...playCSSv2.html) and if layout
and size were !important and imposed, break-before and break-after rules
could do a reasonable job, couldn't they ?

Any clues how to use @page, break rules and numbering ?
You'll have to wait for browsers to be improved. Few have any decent
sort of support for those things. It's generally only the experimental
ones (e.g. Mozilla) that have any support for page media effects.

Well then, for this application (and I can't believe I'm saying this)
perhaps a "best viewed with Mozilla" flag is in order.
You probably want to look into a program designed for text manipulation
(a real word processor, not a desk top publisher). Probably something
like Tex or Latex
LyX is pretty good and has both existing screenplay templates and crisp
output. The challenge, in this case though, is to start with a
super lightweight txt markup, and click-click get a formally formatted
representation of that screenplay.
In the past, I've written programs for custom handling of text. It was
easier, for me then, than trying to find something ready made, and I had
my source material in a manageable format too (that's important).
So you know where I'm coming from !
There's no ability to "force" anything in WWW authoring...

grrrrrr ... ;-)

thanks, Tim,
djp

[David J Patrick]

On Mon, 21 Jun 2004 16:57:49 +0100, Chris Morris wrote:

Possibly what I'd suggest is:
Stylesheet 1: Media="screen"
Alternate Stylesheet 2: Media="screen"
Stylesheet 3: Media="print"
yeah, /that's/ what I meant !
What I don't know (yet) is the mechanism to call that Alternate Sheet.
The alternate stylesheet implementation fails on page changes in every
browser I've seen that does it at all. But my impression of this is
that you intend it to be a single long file anyway, where that isn't a
problem.
Your impression is correct. Perhaps Stylesheet2 is invoked from a CSSmenu
in Stylesheet1.
Alternatively (and with more support in browsers) you could switch
between 1 and 2 using server-side scripting, which would be a better
solution, if you have server-side scripting available.

I would avoid that, as there will be no host established, only the
wholesome goodness of CSS.
djp

[David J Patrick]

On Mon, 21 Jun 2004 16:31:52 +0100, PeterMcC wrote:

Apologies if this is on the wrong track but Final Draft - which is pretty
much accepted in the industry - works to the "Hollywood" format and has a
"Save as html option" which I've never used until your post.

No appology required and yes, you are on the wrong track ! ;-)
I've used FD, and it's the "standard for a good reason, but what I'm
trying to do is to bring it on home at a lower level. The spark that got
me going on this was a desire for the tools to create a screenplay
starting with a simple txt editor, (in my case SiEd, on the palm pilot)
and to allow portable acceptable formatting using tools that anyone can
use, at no cost.
Can FD import is's own html ? Could you email me a sample output ?
thanks !

[Darin McGrew]

David J Patrick <da***********@sympatico.ca> wrote:

Yeah, as I see it now (and it's a moving target) I'd like to create a CSS
with three profiles;

1. (media="screen") a smooth flowing, readable version, with light
formatting and the users choice of font/ size. This (least formal) could
also feature a pure CSS menu to navigate the script, etc. If possible,
page breaks will be indicated, but not forced, based on a rigid layout.

2. (media="screen-rigid") this layout gives a visual page field (like
ScreenplayCSSv2) and adheres strictly print formatting
conventions even so far as to put shadows where the tree-hole-punch goes.

3. (media="print") same as 2. .. only more so !

It seems to me that the second case might just be an on-screen preview of
the third (media="print") case. If so, then current browsers can give you a
print preview, using the media="print" style sheet.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"Shin: a device for finding furniture in the dark." - Steven Wright

[David J Patrick]

On Mon, 21 Jun 2004 17:57:59 +0000, Darin McGrew wrote:

It seems to me that the second case might just be an on-screen preview of
the third (media="print") case. If so, then current browsers can give you a
print preview, using the media="print" style sheet.

Almost the same thing, but the "browsing" in a print preview is invariably
clunkier. The two should ve very similar, though.

[John M. Gamble]

In article <pa****************************@sympatico.ca>,
David J Patrick <da***********@sympatico.ca> wrote:

On Mon, 21 Jun 2004 16:57:49 +0100, Chris Morris wrote:

Possibly what I'd suggest is:
Stylesheet 1: Media="screen"
Alternate Stylesheet 2: Media="screen"
Stylesheet 3: Media="print"

yeah, /that's/ what I meant !
What I don't know (yet) is the mechanism to call that Alternate Sheet.

Doesn't the Css Zen Garden <http://www.csszengarden.com> do that to
extreme? They may be using javascript to achieve that though (i
can't post and use WWW at the same time, or i'd *clickety* over
there and check for you).

--
-john

February 28 1997: Last day libraries could order catalogue cards
from the Library of Congress.

[BenOne©]

Neal wrote:

On 20 Jun 2004 22:51:41 -0700, Wolfgang Wildeblood
<wo****************@yahoo.com.au> wrote:

But to get the same formatting on screen (i.e. line breaks in the same
places), you simply specify directly that you want 60 characters per
line.

p {
width: 60em !important;
margin: auto;
}

If only 1em = 1 character!

I learned that the hard way. It's a pity there isn't a standard measurement for
a character.

Is it true that IE sets the height of a container based on the contents, when
you use em to specify the height, or is IE just confusing me by automatically
resizing the div even if I explictly set the height?

--
Ben Thomas
Opinions, conclusions, and other information in this message that do not
relate to the official business of my firm shall be understood as neither
given nor endorsed by it.

[Christoph Paeper]

*BenOne©* <no**@m.thanks.mate>:

Neal wrote:

If only 1em = 1 character!

I learned that the hard way. It's a pity there isn't a standard measurement
for a character.

Well, Mozilla uses the proprietary 'ch', but for what it's worth, 'ex' comes
much closer to the average character width than 'em', even if it's
implemented in its simplest form ("0.5em").

--
"Anyone who slaps a 'this page is best viewed with Browser X' label on a
Web page appears to be yearning for the bad old days, before the Web, when
you had very little chance of reading a document written on another computer,
another word processor, or another network." Tim Berners-Lee, 1996

[David J Patrick]

On Mon, 21 Jun 2004 19:16:20 +0000, John M. Gamble wrote:

Doesn't the Css Zen Garden <http://www.csszengarden.com> do that to
extreme?

They sure do !
They may be using javascript to achieve that though
Nope ! all css. They are using <a href="#"
onclick="setFixedStyle('default.css');">Chosen Style</a>

Can the all 3 styles, including the alternate, be within the same
stylesheet ? (I will set up 3 externals, but I can see a case for internal.)

[Wolfgang Wildeblood]

Steve Pugh <st***@pugh.net> wrote:

wo****************@yahoo.com.au (Wolfgang Wildeblood) wrote:

Neal <ne*****@yahoo.com> wrote:

On 20 Jun 2004 22:51:41 -0700, Wolfgang Wildeblood
<wo****************@yahoo.com.au> wrote:

> But to get the same formatting on screen (i.e. line breaks in the same
> places), you simply specify directly that you want 60 characters per
> line.
>
> p {
> width: 60em !important;
> margin: auto;
> }
If only 1em = 1 character!

That's the whole point of using monospaced fonts, Neal.

But 1em is still the height of the font, not the width of a character.

Try it for yourself.
<div style="width: 10em; font-family: monospace; padding: 0; border:
1px solid red;">1234567890</div>
See how much wider the div is than the text?

I thought Neal was waffling about how not all lines will have the
same number of characters. (And I still suspect he might have been.)
Don't be so vague Neal.

But even my dog knows characters in Courier fonts are 3/5 of an em
wide (How do they fit the capital M in, he wonders idly?). So my 60em
stated above gives 100 characters. I ommitted an important step:
multiply the required number of characters by 3/5 to get the width.

Just send your grovelling retraction on good quality paper suitable
for framing, okay?

I'm sure Neal looks forward to receiving that from you.

Sorry, Neal. (So how come you didn't give the correct number?)
--
"Really, Jo. Don't tell me you failed Latin as well as science?"

[Wolfgang Wildeblood]

Christoph Paeper <ch**************@nurfuerspam.de> wrote:

*BenOne©* <no**@m.thanks.mate>:

Neal wrote:

If only 1em = 1 character!

I learned that the hard way. It's a pity there isn't a standard measurement
for a character.

Well, Mozilla uses the proprietary 'ch', but for what it's worth, 'ex' comes
much closer to the average character width than 'em', even if it's
implemented in its simplest form ("0.5em").

Well Mozilla supposedly implements ex properly (i.e. independently of
em) but yes other browsers just substitute 0.5em, which is as good as
useless. That might be closer to the average character width than em
is, but it's not nearly close enough to use as a direct substitute
without correction. In their defence, it shouldn't be up to browsers
to perform low-level OS functions like dealing with fonts, anyway.

It's just another example of how misguided CSS is.

My theory is that ex is most useful in setting the leading between
lines, which should be some preferred multiple of 1ex, causing the
leading to adjust appropriately with different typefaces.
Unfortunately, CSS doesn't use "leading" but the misguided
"line-height". So it would need mathematical functions, something
like:-

* { line-height: 1em + 0.67ex }

Which it also doesn't have. So CSS as it stands is pretty damn broken.

--
Stephen Poley has a page about "ex" on his site,
but I can't recall the URL OTTOMH.

[Wolfgang Wildeblood]

David J Patrick wrote:

On Sun, 20 Jun 2004 22:51:41 -0700, Wolfgang Wildeblood wrote:

Damn right, all those IDs should be classes. This won't bother the
CSS, but it's very broken HTML.

I know I'm exibiting my ignorance here, but in replacing those <div id=
tags I simply use;

.dialog{ /* . instead of # */
margin:0pt 110pt 0pt 85pt: /* actual pixel to point conversion to be
worked out */
}

and in the html
<p class="dialog">Words words words</p>

That simple ?

Yes.

[Wolfgang Wildeblood]

wo****************@yahoo.com.au (Wolfgang Wildeblood) wrote:

Well some smart-alec people have pointed out that I missed a step, but
they didn't look that closely or they would have seen that I also
missed a crucial bracket. Here's the corrected post:-

David J Patrick <da***********@sympatico.ca> wrote:

The ScreenplayCSS is flawed, for several reasons;
-overuse of <div id= tags
Damn right, all those IDs should be classes. This won't bother the
CSS, but it's very broken HTML.

-doesn't scale screen resolutions (convert from px to in, pt ?)
-no media="print" (how much could be shared between "screen" & "print")

Not much. You go about it (screen and print formatting) two different
ways.

Take MyNovel.txt, for example. To print this as a "manuscript" to send
to a publisher you'd want a specific format:-

- A monospaced font giving exactly:
- 60 characters per line,
- 25 lines per page,
- 1500 characters (250 words) per page.

To achieve this in print you measure the size of the paper, deduct the
margins, then divide by 60 to get the font-size that results in 60
characters per line. Then set a line-height that results in 25 lines
per page.

But to get the same formatting on screen (i.e. line breaks in the same
places), you simply specify directly that you want 60 characters per
line.

By multiplying 60 times the width of 1 character (3/5em) for a total
of 36em.

p {
width: 60em !important; <-- spot the mistake?
margin: auto;
}

That's all there is to it; as usual for screen, no mention of
font-size at all. So the stylesheet just looks something like:

@media print, projection, screen {
* {
font-family: "Courier New", monospace !important;
line-height: 2;
}
}

@media print {
* { font-size: 12pt /* or whatever */ !important;
}
Anyone who copy/pasted this example would have quickly discovered a
missing bracket here :-( the @media print block was never closed. Ooh
look, there it is:

}

@media projection, screen {
p {
width: 36em !important; /* 36em = 60 characters */
margin: auto;
}
}

--
Don't Ebay and newsgroup at the same time, it's too distracting.

[Wolfgang Wildeblood]

David J Patrick <da***********@sympatico.ca> wrote:

On Mon, 21 Jun 2004 20:34:51 +0930, Tim wrote:

Tim wrote:

You can't mimic the page count on screen, as you don't have pages on the
screen. You have something analagous to a continuous roll of paper.

Yet it should be possible to represent pages, one after another (as in
http://s92415866.onlinehome.us/files...playCSSv2.html) and if layout
and size were !important and imposed, break-before and break-after rules
could do a reasonable job, couldn't they ?

The page break properties simply don't apply to screens, that's all
there is to it. Get Opera, if you don't already have it, the page
break properties are applied (somewhat unreliably) in full screen
("@media projection") mode.

If it's a situation of a limited number of users and you can say, "Hey
guys you need this software," Opera is going to be more suitable for
this application than Mozilla would.

Then you should be able to concoct a screen format based on characters
as I wrote previously (just ignore the smart-alecs), that by simply
pressing F11 will look more like the printed format.

You don't need to mess about with multiple stylesheets or switching
menus - killfile anyone who says you do.

Any clues how to use @page, break rules and numbering ?

You'll have to wait for browsers to be improved. Few have any decent
sort of support for those things. It's generally only the experimental
ones (e.g. Mozilla) that have any support for page media effects.

Well then, for this application (and I can't believe I'm saying this)
perhaps a "best viewed with Mozilla" flag is in order.

[Chris Morris]

David J Patrick <da***********@sympatico.ca> writes:

On Mon, 21 Jun 2004 16:57:49 +0100, Chris Morris wrote:

Possibly what I'd suggest is:
Stylesheet 1: Media="screen"
Alternate Stylesheet 2: Media="screen"
Stylesheet 3: Media="print"
yeah, /that's/ what I meant !
What I don't know (yet) is the mechanism to call that Alternate Sheet.

<link rel="stylesheet" type="text/css" href="css/main.css"
title="{description}" media="screen">

<link rel="alternate stylesheet" type="text/css" href="css/alt.css"
title="{description}" media="screen">

<link rel="stylesheet" type="text/css" href="css/print.css"
title="{description}" media="print">

The alternate stylesheet implementation fails on page changes in every
browser I've seen that does it at all. But my impression of this is
that you intend it to be a single long file anyway, where that isn't a
problem.

Your impression is correct. Perhaps Stylesheet2 is invoked from a CSSmenu
in Stylesheet1.

How to get at them varies from browser to browser - IE doesn't support
it, modern Mozilla variants tend to and Opera does. Can't remember
about Konqueror.

[From other post] Can the all 3 styles, including the alternate, be within the same
stylesheet ? (I will set up 3 externals, but I can see a case for internal.)

The alternate can't. The print one could be:

<link rel="stylesheet" type="text/css" href="css/main.css"
title="{description}">
<link rel="alternate stylesheet" type="text/css" href="css/alt.css"
title="{description}">

css/main.css
@media screen {
....
}
@media print {
....
}

css/alt.css
@media screen {
....
}
@media print {
....
}

Though to avoid duplication, better would be to keep the three files
separate and have:

css/main.css
@import "print.css";
@media screen {
....
}

css/alt.css
@import "print.css";
@media screen {
....
}

css/print.css
@media print {
....
}

--
Chris

[Wolfgang Wildeblood]

David J Patrick <da***********@sympatico.ca> wrote:

On Sun, 20 Jun 2004 22:51:41 -0700, Wolfgang Wildeblood wrote:

You go about it (screen and print formatting) two different
ways.

To achieve this in print you measure the size of the paper, deduct the
margins, then divide by 60 to get the font-size that results in 60
characters per line. Then set a line-height that results in 25 lines
per page.
The cardinal rule of screenplay output is Courier 12pt. Knowing this,
would the page not be best defined in points ?

I was using an example I was familiar with - the manuscript format
uses 1500 characters per page. That's neither here nor there, the
process is the same. You set your stylesheet for print by the
traditional required parameters, whatever they may be. Then you print
out a page and count the number of characters in a line.

For the screen stylesheet you work in character widths, which as we
have now established are 3/5em. The result will be the line breaks in
the same place on screen as they are when printed.

But to get the same formatting on screen (i.e. line breaks in the same
places), you simply specify directly that you want 60 characters per
line.

..or whatever each element definition calls for.. which is most often
described in inches from a margin.

Not on screen. Do your margin in inches for print, then count how many
characters across the page that results in. For screen use "padding"
not "margin" or "text-indent", and set in ems. The result will be the
same layout on screen as the printed page.

p {
width: 60em !important;
margin: auto;
}
}
That's all there is to it; as usual for screen, no mention of font-size
at all. So the stylesheet just looks something like:

@media print, projection, screen {
* {
font-family: "Courier New", monospace !important; line-height: 2;
}
}
@media print {
* { font-size: 12pt /* or whatever */ !important;
}
}
@media projection, screen {
p {
width: 60em !important;
/* That should have said 36em for my example */
margin: auto;
}
}

And if I wanted to have TWO screen layouts (one rigid and one readable)
could I add

@media screen rigid {
* {font size: 12/1 !important;
}

No. That's what the projection media type is for. Read my other post,
and quit messing with the subject line will ya?

Do you agree that the @page spec (and associated break & number rules) are
too unsupported to use ?
Yes, no, maybe. Forget about numbering. Page break is useful but not
reliable.

thanks Wolfgang,

Hmm.

[PeterMcC]

David J Patrick wrote in
<pa****************************@sympatico.ca>

On Mon, 21 Jun 2004 16:31:52 +0100, PeterMcC wrote:

Apologies if this is on the wrong track but Final Draft - which is
pretty much accepted in the industry - works to the "Hollywood"
format and has a "Save as html option" which I've never used until
your post.

No appology required and yes, you are on the wrong track ! ;-)
I've used FD, and it's the "standard for a good reason, but what I'm
trying to do is to bring it on home at a lower level. The spark that
got me going on this was a desire for the tools to create a screenplay
starting with a simple txt editor, (in my case SiEd, on the palm
pilot) and to allow portable acceptable formatting using tools that
anyone can use, at no cost.
Can FD import is's own html ? Could you email me a sample output ?
thanks !

Just tried it - attempting to open an FD-generated html file gives a
"Unexpected file error" :(

The html file output is:

<html>
<body>
<title>Whatever</title>
<A NAME="top"> </A>
<center> Script created with <a href = "http://www.finaldraft.com">Final
Draft</a> by Final Draft, Inc. </center>
<hr>
<pre>

The work of genius goes in here without markup since it's <pre>

</pre>
<A NAME="bottom"> </A>
<hr>
<center> Script created with <a href = "http://www.finaldraft.com">Final
Draft</a> by Final Draft, Inc. </center>
</body>
</html>

In the event of the script being lengthy, FD offers the option of splitting
the script into shorter html pages. If you take that option, FD inserts
links to the previous and subsequent pages at both the top and bottom of the
page where their URL is shown.

Best of luck

--
PeterMcC
If you feel that any of the above is incorrect,
inappropriate or offensive in any way,
please ignore it and accept my apologies.

[David J Patrick]

On Tue, 22 Jun 2004 13:59:06 +0100, PeterMcC wrote:

Just tried it - attempting to open an FD-generated html file gives a
"Unexpected file error" :(

Did you enter any action, sluglines, dialog, characters ? etc ?
could you ? I was hoping to see if there was an html formatting that FD
would eat, and if so, it might be worth conforming to that. If not, ta
hell wit' 'em !.. ;-)
Could you try it again ? thanks
djp

[David J Patrick]

On Tue, 22 Jun 2004 02:41:57 -0700, Wolfgang Wildeblood wrote:

For the screen stylesheet you work in character widths, which as we
have now established are 3/5em. The result will be the line breaks in
the same place on screen as they are when printed.[ [snip] Do your margin in inches for print, then count how many characters across the page that results in. For screen use "padding"
not "margin" or "text-indent", and set in ems. The result will be the
same layout on screen as the printed page.

> p {
> width: 60em !important;

/* That should have said 36em for my example */

[snip] Read my other post, and quit messing with the subject line will ya?
whaaa?? messin' ? I'm helping differentiate what would otherwise be a sea
of similarity ..
.... you're serious, aren't you ...
Forget about numbering. Page break is useful but not
reliable.
but number of pages (and hence numbering) is the carrot for the
scriptwriter, and an essential reference for reviewers.

Hmm.

Ahhhhh !

[PeterMcC]

David J Patrick wrote in
<pa****************************@sympatico.ca>

On Tue, 22 Jun 2004 13:59:06 +0100, PeterMcC wrote:

Just tried it - attempting to open an FD-generated html file gives a
"Unexpected file error" :(

Did you enter any action, sluglines, dialog, characters ? etc ?
could you ? I was hoping to see if there was an html formatting that
FD would eat, and if so, it might be worth conforming to that. If
not, ta hell wit' 'em !.. ;-)
Could you try it again ? thanks
djp

It was a full hour TV script complete with all the formatting - and a
brilliant plot and characters - the entire content of the script was within
in the <pre></pre> section. I opened the resulting file in notepad, deleted
the html stuff so that I was left with just the contents of the <pre> and
pasted that back into FD and it was just as the original FD file though FD
wouldn't accept the notepad file as a legitimate file when I changed the
extension to .fdr

BTW - I think I'm just confusing the issue with a red herring here. You
don't have to keep on being polite, a recommendation to stuff Final Draft
and stop making stupid suggestions will suffice :)

--
PeterMcC
If you feel that any of the above is incorrect,
inappropriate or offensive in any way,
please ignore it and accept my apologies.

[David J Patrick]

On Tue, 22 Jun 2004 16:30:57 +0100, PeterMcC wrote:

It was a full hour TV script complete with all the formatting
Three things I want to know;
1) how are FD elements formatted when exported to html.
2) what do the headers look like (seen that, thanks)
3) if I followed that format, would I be able to import my files to FD.
BTW - I think I'm just confusing the issue with a red herring here. Red Herring, pan fried with a little butter.. delicious ! You don't have to keep on being polite,

My politness only goes so far. I'm genuinely interested in your sideline
to FD. You have been very helpful .. now get with it, ya dweeb !! ...
sorry.. ;-)

[Tim]

Wolfgang Wildeblood wrote:

Forget about numbering. Page break is useful but not
reliable.

David J Patrick <da***********@sympatico.ca> posted:
but number of pages (and hence numbering) is the carrot for the
scriptwriter, and an essential reference for reviewers.

They're really left with two options - print it and estimate, or do a word
count and some maths. The latter is probably going to be far more useful,
and can be done on a computer really easily.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

[David J Patrick]

On Thu, 24 Jun 2004 22:40:00 +0930, Tim wrote:

They're really left with two options - print it and estimate, or do a word
count and some maths. The latter is probably going to be far more useful,
and can be done on a computer really easily.

wc would have to calculate on a per element basis and also take into
account different element line spacing. It could be done, I suppose, but
if page breaks were effected for printout, why couldn't they be for a
screen representation?

[Wolfgang Wildeblood]

David J Patrick <da***********@sympatico.ca> wrote:

On Thu, 24 Jun 2004 22:40:00 +0930, Tim wrote:

They're really left with two options - print it and estimate, or do a word
count and some maths. The latter is probably going to be far more useful,
and can be done on a computer really easily.

wc would have to calculate on a per element basis and also take into
account different element line spacing. It could be done, I suppose, but
if page breaks were effected for printout, why couldn't they be for a
screen representation?

Because... (as I've already said... Grr) when page break properties
are implemented on screen, it's called "projection" and it's only
implemented in Opera. Have you tried it out yet?

Anyway, what's wrong with looking at the print preview when you want
to see the page breaks? Come to that, I'm not really sure why you want
markup at all; if the proper formatting is your over-riding concern
plain text files are the go.

--
You would cry too, if it happened to you.

[Tim]

On Thu, 24 Jun 2004 22:40:00 +0930, Tim wrote:

They're really left with two options - print it and estimate, or do a word
count and some maths. The latter is probably going to be far more useful,
and can be done on a computer really easily.

David J Patrick <da***********@sympatico.ca> posted:
wc would have to calculate on a per element basis and also take into
account different element line spacing. It could be done, I suppose, but
if page breaks were effected for printout, why couldn't they be for a
screen representation?

Because the screen isn't a piece of paper. It's somewhat rare for an
on-screen display to be a printed page size (in content). I did forget
something obvious - many print previews do give you a page count.

But counting pages is quite a vague estimation of what a script entails;
notes, lines, descriptions, etc., all have different amounts of work to go
along with the number of words involved.

Text processors often do quite a bit of statistical analysis on documents,
giving word counts, sentence counts, and so on. That sort of thing would
be just as good a way of doing an estimate, probably even better - I'd say
a word count is far more useful than a page count (I work in television
production, and I'd be loathe to estimate the length of a production by the
page count; it's just to arbitrary).

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

[Neal]

On Sat, 26 Jun 2004 21:59:03 +0930, Tim <ti*@mail.localhost.invalid> wrote:

But counting pages is quite a vague estimation of what a script entails;
notes, lines, descriptions, etc., all have different amounts of work to
go
along with the number of words involved.

It is vague, but it also happens to be the convention in the acting world.
There are too many parameters, some of which you cannot analyze from the
text alone - tempo, pauses, etc. - so they assume 1 page = 1 minute, and
it tends to work more often than not.

So for this type of project, that is the unit of measurement that needs to
be worked out. I suppose a script could count displayed characters and
carriage-return situations in some way to measure where page breaks should
occur, but it's beyond me to explain how.