MobileRead Forums - View Single Post

Katsunami · 11-03-2013, 04:24 PM

As an embedded software engineer (I write such software, I'm not embedded into anyting myself

), I can only say that I "hate" desktop software. It's huge, complicated, and tends to do everything, including roasting chickens for dinner.

Maybe people here have noticed that I like software that works like a compiler: you put stuff in at one side, and you get stuff out on the other side. Two software packages that do this are LaTeX for writing reports (or books), and LilyPond for sheet music. Another piece of software is PanDoc, which takes stuff in one markup language, and outputs it in another.

The one thing they have in common, is that all input is in plain text that can be written with any editor. The other thing is that they are still quite large, and require quite a steep learning curve to get started.

I was thinking to create a very small piece of software that compiles text-files into a book, but I'd strip it down to the most basic essential, so that a user would need to do absolutely nothing but write. What a writer would create is this:

Code:

+ My Great Work
    + 10-Part 1
      + 10-Chapter 1
          10-Scene.txt
          20-Scene.txt
      + 20-Chapter 2
          10-Scene.txt
          20-Scene
    + 20-Part 1
      + 10-Chapter 1
          10-Scene.txt
          20-Scene.txt
      + 20-Chapter 2
          10-Scene.txt
          20-Scene.txt

The items marked with a + would be folders, and the scenes are just normal plain text files. The numbers denote priority: "10-Part 1" comes before "20-Part 2", and so on.

Now, it would be relatively simple to write a very small program, that runs through that set of folders and text files. This program would compile everything into a valid (X)HTML file, with proper tagging; each "Part" would be <h1>, each "Chapter" would be <h2>, each paragraph would get it's own <p>-tags. Of course, there could also be multiple files; one for each chapter, for example. At some point, this program might be extended or replaced to directly create an EPUB. (PanDoc can create HTML-files and EPUBs, but it doesn't automatically build a book from a directory structure.)

In this case, everything with regard to markup and layout would be omitted from the writing process; I mean *EVERYTHING*, even the inclusion of images. This would be done using a placeholder, such as "Insert Image1.jpg here". After creating the (X)HTML file (or later, maybe the EPUB), one would take that file into a specific editor for marking it up, adding images, and adding covers and such. The main benefit would be that you can write stuff using any editor on any platform, anywhere; even using your phone if you want (or need) to, and you can just dump the text-files into the correct chapter with the correct priority, and be done.

It basically comes down to:
- You create (and name) parts and chapters by creating folders
- You create scenes by writing them in plain TXT files
- They are arranged using priorities (inserting a scene between 10-Scene.txt and 20-Scene.txt is as simple as creating 15-Scene.txt)
- When writing is done, you create the bare-bones (X)HTML or EPUB by running a simple command.
- You can then markup the bare-bones book in a program that can do EPUB-editing.

Would there be interest in something like this?

11-03-2013, 04:24 PM	#1
Katsunami Grand Sorcerer Posts: 6,111 Karma: 34000001 Join Date: Mar 2008 Device: KPW1, KA1	Writing using minimalistic software As an embedded software engineer (I write such software, I'm not embedded into anyting myself ), I can only say that I "hate" desktop software. It's huge, complicated, and tends to do everything, including roasting chickens for dinner. Maybe people here have noticed that I like software that works like a compiler: you put stuff in at one side, and you get stuff out on the other side. Two software packages that do this are LaTeX for writing reports (or books), and LilyPond for sheet music. Another piece of software is PanDoc, which takes stuff in one markup language, and outputs it in another. The one thing they have in common, is that all input is in plain text that can be written with any editor. The other thing is that they are still quite large, and require quite a steep learning curve to get started. I was thinking to create a very small piece of software that compiles text-files into a book, but I'd strip it down to the most basic essential, so that a user would need to do absolutely nothing but write. What a writer would create is this: Code: + My Great Work + 10-Part 1 + 10-Chapter 1 10-Scene.txt 20-Scene.txt + 20-Chapter 2 10-Scene.txt 20-Scene + 20-Part 1 + 10-Chapter 1 10-Scene.txt 20-Scene.txt + 20-Chapter 2 10-Scene.txt 20-Scene.txt The items marked with a + would be folders, and the scenes are just normal plain text files. The numbers denote priority: "10-Part 1" comes before "20-Part 2", and so on. Now, it would be relatively simple to write a very small program, that runs through that set of folders and text files. This program would compile everything into a valid (X)HTML file, with proper tagging; each "Part" would be <h1>, each "Chapter" would be <h2>, each paragraph would get it's own <p>-tags. Of course, there could also be multiple files; one for each chapter, for example. At some point, this program might be extended or replaced to directly create an EPUB. (PanDoc can create HTML-files and EPUBs, but it doesn't automatically build a book from a directory structure.) In this case, everything with regard to markup and layout would be omitted from the writing process; I mean EVERYTHING, even the inclusion of images. This would be done using a placeholder, such as "Insert Image1.jpg here". After creating the (X)HTML file (or later, maybe the EPUB), one would take that file into a specific editor for marking it up, adding images, and adding covers and such. The main benefit would be that you can write stuff using any editor on any platform, anywhere; even using your phone if you want (or need) to, and you can just dump the text-files into the correct chapter with the correct priority, and be done. It basically comes down to: - You create (and name) parts and chapters by creating folders - You create scenes by writing them in plain TXT files - They are arranged using priorities (inserting a scene between 10-Scene.txt and 20-Scene.txt is as simple as creating 15-Scene.txt) - When writing is done, you create the bare-bones (X)HTML or EPUB by running a simple command. - You can then markup the bare-bones book in a program that can do EPUB-editing. Would there be interest in something like this? Last edited by Katsunami; 11-03-2013 at 04:30 PM.