My FOSS Writing Process
I believe writing should be a universal thing that everyone has access to. FOSS software is in a really good position right now, where it should cost someone nothing to get started writing, as long as they have a computer. I'm going to share what my writing process is in case it helps someone build or improve their own.
FOSS of course stands for "free, open-source software". Software that is free to use, modify, and redistribute. These are important traits for me, because I wish to actually own the software I use to ensure that I will always have access to my creations in the future.
If you don't have your own computer, consider trying out PortableApps as a way to carry the software with you to the library or other places with free computer access.
Capture/Notes
The first step in writing is to capture ideas down into notes. Ideas can come at any time, so I often capture the notes using my smartphone, and gradually expand on them either on my phone or my computer.
Format
I keep track of these using simple text files written in Markdown. It's fast, universal, and easy to use.
Although I prefer AsciiDoctor, Markdown is quite popular, so there is a lot of support for it. Most of my writing is for Gemini now, and gemtext is very close to Markdown anyways. If you know how to write gemtext, you already know how to write most of Markdown.
Sometimes if I'm finding Markdown too limiting, I'll just use a basic plain text file, but this is rarely needed.
Layout
All of my notes are kept inside a single "notes" directory. That directory holds many subdirectories for more specific categories. This simple files + directories structure makes it really easy to backup and sync my notes to anywhere.
Syncing
The notes directory is kept in sync between all of my devices using Syncthing. This provides unlimited syncing and storage (as long as I have the hard-drive space.
The only downside is that two devices need to be on at the same time in order to sync. I'm lucky enough to have the resources to set up a personal server that stays always online, ensuring everything will always be up to sync. If you have something like a smartphone or tablet that you leave on all the time, it should be good enough at providing basically the same service.
Mobile
It's important to be able to capture ideas from anywhere. A good note taking app for mobile is essential for catching ideas that pop up while away from the computer.
On my smartphone, I use Markor. I set it to use my synced notes directory as its Notebook directory (Settings > General > Notebook) and it interacts nicely with the file-system structure. It can be installed easily through F-Droid, which is essential for anyone wishing to keep their smartphones FOSS.
Desktop/Laptop
My laptop tends to be where I do more in-depth writing. On my desktop, I use Thunar and Kate.
Thunar is just a file manager I can use to navigate to where my notes are stored. I keep a shortcut to my notes directory in the sidebar for quick access.
Kate is a text editor with some more advanced features that I found easy to get the grasp of. You could use any text editor, but it's nice to have one that has syntax highlighting for the markup language you'll be using. Kate supports both Markdown and AsciiDoctor by default.
In XFCE, I set up a keyboard shortcut Super + N (N for Notes) to open up my Quicknotes.txt file in Kate directly. I also have a Super + T shortcut (T for Text editor) to open Kate with a blank document which I decide where to save after I've written the thought down.
I suggest *not* using Windows Notepad. It handles text file encoding inaccurately in a way that can corrupt files and fails to recognize non-Windozian line endings. You can use it in a pinch, but there are a lot nicer text editors out there who will treat you better.
Kate Editor (cross platform text editor)
Notepad++ (a popular text editor for Windows)
Searching
I find notes again either by using the directory structure or using search software. On mobile, Markor has a built-in search.
On desktop, I use Catfish File Search. I limit the search scope to the notes directory, and enable the option to search for both file names and the contents of files.
Outlining
As I get more ideas, I will return to that idea's note file and gradually add more to it. Once a note has expanded enough to graduate to a full project, I'll start outlining it. It could branch in multiple directions depending on the project and my mood.
Markdown Headers
If what I'm writing is simple enough, I will simply use Markdown headers as my outline. Shift things around as needed by highlighting the whole section and cut-pasting it elsewhere. Inserting new sections is as easy as typing it in.
AsciiDoctor
If I want something just a step above Markdown, I may use AsciiDoctor instead. It has much more advanced features than Markdown. I can split a work across multiple files for organization, and it can be converted nicely to PDF.
It's a good choice for uses like documentation since it syncs nicely through git. It's also my preferred way of writing man-pages.
At this stage it can be useful to have a live preview. For this, I use the Firefox extension. I'll keep the document in Kate tiled on the left half of the screen, and Firefox with the preview open tiled on the right side of the screen.
Editing AsciiDoc with Live Preview
CherryTree
For writing with more complex structure, I use a program called CherryTree. This allows dividing writing up into nodes, which can then be arranged in a tree as a hierarchy. It also has more advanced features such as rich text, linking, bulleted lists, numbering, and more.
Non-Fiction Writing
I generally lay things out into two trees.
The first tree acts as an outline for the document. The top level node is for the document name (usually a generic placeholder name while I think of one). In that node I store a list of ideas for the document title. In the nodes below it, I make more nodes for each section and subsection as I see fit. They can shift around a lot. I try to keep similar content together and have the information flow from basics to more advanced things that build off from the basics.
The second tree is for storing my notes and references. Generally they are laid out as Notes > Category > Source > Info. Notes are broken up into categories to help ease finding them later. In the source node I include a link to the source (if possible) and a citation, usually generated using Zbib.
Document
├── Introduction
├── Section
│ └── Subsection
├── Another Section
└── Conclusion
Notes
├── Apples
│ └── The Apple Journal
│ ├── Apple species
│ └── Apple flavor profiles
└── Oranges
└── Some random research paper on oranges
└── Orange nutritional value
Creative Writing
If I'm doing creative writing, I instead break down the Notes sub-nodes into People, Places, Things, Events, and a scratchpad. Then record details about each in sub-nodes. The scratchpad is a place to quickly jot down ideas that can be sorted later.
The document tree then would be broken down into chapters, and often the chapter sub-nodes are notes on story beats I want to include. I may arrange the story beats around until they form into natural chapters, then create a chapter out of those. Other times I write a quick outline of what I want to happen in a chapter node, then the sub-nodes will be long-form versions of the writing.
Story
├── Chapter 1: Initiation of the Beginning Starts
│ ├── Beat 1
│ ├── Beat 2
│ └── Beat 3
└── Chapter 2: More Things Happen
└── This thing happens
Notes
├── People
│ └── Agatha
├── Places
│ └── Continent
│ └── Region
│ └── Country
├── Things
│ └── The Sword of Damocles
├── Events
│ └── The French Revolution
│ ├── Cake Happens
│ └── The Time Travelers Arrive
└── Scratchpad
├── This thing would be cool
└── Robot ninja dinosaurs in space?
I may duplicate nodes and keep them side by side as a form of revision history. This lets me try out multiple ideas for how something should go and quickly toggle between them to decide which one I like best.
Feel free to add any additional trees or sections as you need. For example, you may wish to add a tree for the colophon information before the story. Or make the scratchpad its own tree, and only move it up to the Notes tree when it's fully formed and ready to be incorporated into canon. Add a node for Magic to keep track of how it works in your world.
TiddlyWiki
If I need a more advanced place to store notes, and know it's going to be referenced many more times in the future, I'll consider moving things over to a personal wiki. I use TiddlyWiki for this. I'll create a new wiki for each project to help keep things compartmentalized.
The wiki is only for information that has been finalized. I don't use it for hashing out ideas. I'll keep a scratchpad space open elsewhere for that, then move it over when it's more complete.
Finalizing
At some point, the writing will be ready to finalize and get ready for publishing.
Gemini
If a project is to be released on Gemini, I need to make sure it's in proper gemtext. Usually I know in advance that I want to target Gemini, so in the early note-taking phase, I'll write out my Markdown files using gemtext. I use the Markdown file extension so Kate and Markor know to provide Markdown syntax highlighting for at least the syntax that overlaps with gemtext.
To get it ready, I'll check through the file to ensure there's no remnants of Markdown formatting, unless I wish to leave it in. Often I will deliberately leave in some formatting such as inline formatting, since it's useful semantic information that gemtext doesn't offer a solution for.
I am aware Markdown-to-Gemtext converters exist, but they don't work how I would like. Mainly with how they handle links. I like to provide more context in my gemtext links. So while gemtext does not support inline links, I just write out how I want the link to go the first time. These converters then don't really save me time. Perhaps I'll start using them in a future where I start cross-publishing through HTML.
Sometimes I may use additional tricks in my gemtext formatting to squeeze in unintended features, which none of the currently available converters use.
The hardest part to convert are tables. They have to be built up in box drawing characters, then wrapped in a code block. Usually I'll search the web for a conversion tool and use whatever works first. Otherwise, I'll copy-paste them off from the Wikipedia page or just leave the Markdown table as-is.
[Wikipedia] Box-drawing character
Something I should be doing more frequently that I haven't been doing is opening the file in LibreOffice so I can use it's more powerful engine for spelling and grammar checking. It can open and save to text files with no conversion necessary.
When I've finished writing, I'll change the file's extension from .md to .gmi, then preview it locally in Lagrange and fix any obvious errors. (Somehow, Lagrange seems to be the only Gemini browser capable of reading from local files.)
UPDATE: LibreOffice Writer outputs text files with a Byte Order Marker at the front. This causes breakage with flounder.online. Be sure to strip it when finished. See this post for a fix:
//zelena.flounder.online/gemlog/2023-11-12_BOM_Breaks_Flounder.gmi
Documents
For rich documents, I use LibreOffice Writer. It's the most powerful and complete office-style document writer currently available. I like it much better than Microsoft Word.
I've built my own LibreOffice templates for the common types of documents I write. I usually start with one of those when starting a new project.
If I need a more advanced layout ability, I'll use the Scribus desktop publisher instead.
If I'm ever in the unfortunate position of needing to use LaTeX for my project, I use LyX to lay it out. I don't use LaTeX often, so a GUI to help guide me through the formatting is greatly beneficial.
When I'm working in LibreOffice, I'm usually working off the outline I created in CherryTree. I deliberately do not export the project to open directly in LibreOffice. Instead, I will open a fresh empty document and pull in parts piece-by-piece as I feel would be good. This helps me cut out unnecessary parts, and forces me to reconsider how the parts all flow together as a final piece.
It's worthwhile to get acquainted with LibreOffice's advanced features if you use it frequently.
Check `View > User Interface…` and choose the layout style that fits you best. I'm personally fond of the Sidebar layout, since it makes efficient use of horizontal space.
Don't just change the font properties directly. Use styles. Familiarize yourself with the style editor, and you'll save yourself a lot of time trying to match formatting from previous sections, keep your documents more consistent, and add useful semantic information.
Another thing is to look at is the the advanced font options. Some fonts, such as Libertine, have advanced font features which are useful for improving the readability of a font. When you can, prefer the OFT (OpenType) format over TTF (TrueType), since it is a more advanced successor that will let you interact with these features more easily through LibreOffice. Ever wanted to type in lowercase numbers? Well now you can!
LibreOffice Help: OpenType Font Features
Smaller Files Tip
Here's a trick for reducing the file size of LibreOffice documents.
- Go to `Tools > Options`.
- In the window that pops up, navigate in the sidebar to `LibreOffice > Advanced`.
- Click the button `Open Expert Configuration`.
- In the new window that pops up, search for `GenerateThumbnail`.
- An option under `org.openoffice.Office.Common > Save > Document` should appear. Toggle its value to false.
This stops LibreOffice from generating a thumbnail image that gets embedded into the output ODT file. This thumbnail is used by a file explorer to get a preview of the document. I don't find this useful when the documents are mostly text, so I disable it. The resulting file size is a lot smaller when it's not also holding the image.
Scriptwriting
For writing screenplays and stage plays, I write it in Fountain.
Fountain is a lightweight plain text markup language for writing screenplays. It's as easy to use as Markdown, and is quite natural to use for someone experienced in screenwriting. Even if you're not experienced, it's really simple to pick up. Keep the syntax page open on the side and you'll get it in no time.
Being a plain text format, it can be written using any text editor. Kate doesn't have Fountain syntax highlighting, but it's really not necessary.
Similar to with LibreOffice, I'll keep the outline open on the left side of the screen for reference, and be writing out the final version in Kate on the right side of the screen.
You could set up a template in LibreOffice for writing screenplays, but I've never bothered. It's much more convenient to use Fountain.
Publishing/Sharing
Once you've finished your writing, it's time to set it free out in the world. Whoever you are working with, be it a publisher, a website, a coworker, or a friend, coordinate ahead of time to understand what your target format should be.
Gemini (flounder.online)
Thunar makes it super easy to connect to flounder.online through SFTP. (You will need sftp installed and an ssh key configured.) Put `sftp://username.flounder.online` in the navigation bar, where `username` is your own username. Log in when you're prompted. Once connected, save a shortcut to the sidebar.
I set it up so Thunar remembers my login. I simply click the shortcut, then copy-and-paste the files over.
Documents
When you've finished your document, save your file as an ODT (OpenDocument Text). This is the format Writer has the best compatibility with. Treat it as the master file. If someone else wants the file in a different format, open the ODT and `Save As…` the format to a different file.
Most likely people are going to want it in a Word Doc format. Be warned that there are some compatibility issues with Word. Word can open ODT files, but Microsoft chooses not to honor all of its features in an attempt to make their own format look better. This means more advanced style information is likely to get lost.
If they only need to read the document and don't need to do any editing, offer to share it as a PDF instead. LibreOffice can make a PDF by going to `File > Export As > Export as PDF…`. You will probably be fine with the default settings, but look around if there's anything to change. When ready, click Export and select the name and destination for the file.
Epub
To publish to epub, I start by writing the final version in LibreOffice for formalization, then export it to HTML to be used in Sigil. LibreOffice does have a feature now for exporting directly to epub, but it's not yet stable enough for me.
Using Sigil requires understanding of HTML, CSS, and the epub standard. It's a much more complicated process than the others talked about here, but doing it manually produces the best results.
This has already gone on long enough, so I will skip the in-depth tutorial on using Sigil. Check out the project's documentation to learn how to use it.
Scriptwriting
If you want to submit your scripts to a big-name studio, you'll have basically no other option other than to use Final Draft (maybe Fade In if you're lucky). However, both are able to import Fountain scripts. So feel free to work in Fountain until you need to.
Studios are total sticklers to formatting standards when they review screenplays. If a script doesn't match exactly, they use it as an excuse to toss it. They run largely on tradition, which means sticking to "the industry standard", which in this case is Final Draft. (Also why it's so over-priced. Seriously, don't buy Final Draft.)
What is this standard? It doesn't exist. Many professionals will tell you it's however they write their own scripts, but truth be told, every studio has their own set of standards. You'll need to investigate what it is if you're going to try and match it. Hopefully they're more with the times.
The only truly consistent part seems to be that scripts are written using 12 point Courier font, which is an entire font family with it's own set of inconsistencies. Consider getting the Courier Prime font for your scripts. (It's probably already in your Linux distro's repositories.) It's a really nice font designed with screenwriting in mind.
If you're writing for yourself or a hobby project, then the restrictions are a lot looser. You can do whatever you want.
I like to use AfterWriting for converting scripts to a PDF. It's pretty straightforward to use. I download and use the offline version. (Download link is under the Info section.)
If that doesn't work for you, take a look through the list of apps to find one you like.
Take a Break
I don't use any "tricks" to coax out writing like most articles on a writing process. I just do it using some reliable tools.
Nothing here is a law that must not be broken. Do whatever you want. Experiment. Your writing process will differ. I don't even follow my own process strictly all the time. But I hope it was useful to help think about what might help you start or improve your own process.
/gemlog/