{counter} for play line numbering?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

{counter} for play line numbering?

sethwoodworth
Hi folks!

If I were to try to format Romeo and Juliet in Asciidoc, how should I go about formatting each speech?

Background: I've put Project Gutenberg on Github (gitenberg.github.io) and I intend to port many of the books to Asciidoc.

The format of a play is roughly:
* Play
  * Act
    * Scene
      * Setting
      * Stage Direction
      * Speech
        * Speaker
        * Line(s)

Play, Act, Scene looks like it should map to =, ==, and ===.
I'm unclear what blocks make the most sense for setting or stage dir, but I am willing to default to standard paragraphs.
My current best idea for Speech is to use a [verse] block.  
If I want a play-style layout, I can customize a template to produce something like:

    Romeo: Pardon, good Mercutio, my business was great; and in
                   such a case as mine a man may strain courtesy.

Lastly, can I use the {counter} element to apply to every line in the play? Is that a supported use or are counters limited to specific blocks?


--Seth

Reply | Threaded
Open this post in threaded view
|

Re: {counter} for play line numbering?

mojavelinux
Administrator
On Fri, Mar 20, 2015 at 2:24 PM, sethwoodworth [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Hi folks!

If I were to try to format Romeo and Juliet in Asciidoc, how should I go about formatting each speech?

That's a great question. The best way to know is to try some samples and and iterate until we have a layout that feels the most natural.

As far as goals, we should think about the core tenets of AsciiDoc (as I've defined them):

* concise
* consistent
* semantic

Obviously, concise is good. That's why we're in the business of AsciiDoc (and not DocBook).

Consistent is good because it feels true to AsciiDoc and authors can recognize patterns and apply them naturally.

Semantic is critical for long-term storage, especially for texts like those from Project Gutenberg. Where there is friction against being semantic, we should consider whether a core change or an extension is necessary to alleviate the friction. 
 

Background: I've put Project Gutenberg on Github (gitenberg.github.io) and I intend to port many of the books to Asciidoc.

Super cool!!

I recently was looking for the text for Le Petit Prince (as part of my French language study) and I was appalled that I couldn't get the text as plain text markup in a format I could transform. I really missed having in AsciiDoc (so I started creating it myself, btw).
 

The format of a play is roughly:
* Play
  * Act
    * Scene
      * Setting
      * Stage Direction
      * Speech
        * Speaker
        * Line(s)

Play, Act, Scene looks like it should map to =, ==, and ===.

Agreed.
 
I'm unclear what blocks make the most sense for setting or stage dir, but I am willing to default to standard paragraphs.

Perhaps either paragraphs or open blocks with a custom style is appropriate as it allows us to hook into them and format them specially.

[setting]
A vast, dense forest.

[setting]
--
A vast, dense forest.

In the middle, there was a big clearing.
--
 
My current best idea for Speech is to use a [verse] block.

Seems like a great fit. I recommend using the Asciidoctor-style shorthands:

[verse]
""
Stand back, my son!
""
 
 

If I want a play-style layout, I can customize a template to produce something like:

    Romeo: Pardon, good Mercutio, my business was great; and in
                   such a case as mine a man may strain courtesy.

Or perhaps you could use a description list.

Romeo:: Pardon, good Mercutio, my business was great; and in 
                   such a case as mine a man may strain courtesy. 

That way it formats nicely even with the default stylesheet.


Lastly, can I use the {counter} element to apply to every line in the play? Is that a supported use or are counters limited to specific blocks?

The {counter} is a general purpose way to count. It could certain work for line numbers. However, since line numbers are so implicit, perhaps they could be weaved in using an post-processing extension (such as a Treeprocessor). I'd only include them in the source if they were something that the author needed artistic control over. (or, in case we are losing semantic information by dropping them).

I'm very interested in this initiative. I hope that helps a bit!

-Dan

--
Reply | Threaded
Open this post in threaded view
|

Re: {counter} for play line numbering?

mojavelinux
Administrator
In reply to this post by sethwoodworth
Btw, to move the conversation forward, perhaps you could cite specific examples where design of the AsciiDoc is needed. Once we establish the patterns, then they can be applied across the whole work.

-Dan

On Mon, May 4, 2015 at 7:45 PM, Dan Allen <[hidden email]> wrote:
On Fri, Mar 20, 2015 at 2:24 PM, sethwoodworth [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Hi folks!

If I were to try to format Romeo and Juliet in Asciidoc, how should I go about formatting each speech?

That's a great question. The best way to know is to try some samples and and iterate until we have a layout that feels the most natural.

As far as goals, we should think about the core tenets of AsciiDoc (as I've defined them):

* concise
* consistent
* semantic

Obviously, concise is good. That's why we're in the business of AsciiDoc (and not DocBook).

Consistent is good because it feels true to AsciiDoc and authors can recognize patterns and apply them naturally.

Semantic is critical for long-term storage, especially for texts like those from Project Gutenberg. Where there is friction against being semantic, we should consider whether a core change or an extension is necessary to alleviate the friction. 
 

Background: I've put Project Gutenberg on Github (gitenberg.github.io) and I intend to port many of the books to Asciidoc.

Super cool!!

I recently was looking for the text for Le Petit Prince (as part of my French language study) and I was appalled that I couldn't get the text as plain text markup in a format I could transform. I really missed having in AsciiDoc (so I started creating it myself, btw).
 

The format of a play is roughly:
* Play
  * Act
    * Scene
      * Setting
      * Stage Direction
      * Speech
        * Speaker
        * Line(s)

Play, Act, Scene looks like it should map to =, ==, and ===.

Agreed.
 
I'm unclear what blocks make the most sense for setting or stage dir, but I am willing to default to standard paragraphs.

Perhaps either paragraphs or open blocks with a custom style is appropriate as it allows us to hook into them and format them specially.

[setting]
A vast, dense forest.

[setting]
--
A vast, dense forest.

In the middle, there was a big clearing.
--
 
My current best idea for Speech is to use a [verse] block.

Seems like a great fit. I recommend using the Asciidoctor-style shorthands:

[verse]
""
Stand back, my son!
""
 
 

If I want a play-style layout, I can customize a template to produce something like:

    Romeo: Pardon, good Mercutio, my business was great; and in
                   such a case as mine a man may strain courtesy.

Or perhaps you could use a description list.

Romeo:: Pardon, good Mercutio, my business was great; and in 
                   such a case as mine a man may strain courtesy. 

That way it formats nicely even with the default stylesheet.


Lastly, can I use the {counter} element to apply to every line in the play? Is that a supported use or are counters limited to specific blocks?

The {counter} is a general purpose way to count. It could certain work for line numbers. However, since line numbers are so implicit, perhaps they could be weaved in using an post-processing extension (such as a Treeprocessor). I'd only include them in the source if they were something that the author needed artistic control over. (or, in case we are losing semantic information by dropping them).

I'm very interested in this initiative. I hope that helps a bit!

-Dan

--



--