This is not a thread for debating rich text/plain text portability. We have plenty of those already
For those who have settled on rich text, or that prefer it over plain text formats such as Markdown…
What use case(s) prompts you to pick it over plain text? Or, what limitations in plain text force your hand? I’m more interested in use cases where you’ve actively chosen rich text, rather than needing it to collaborate with others via a certain file format, but all answers are welcome.
Imagine a Hypothetical Plaintext Editor (HPE) that, from the user’s perspective, renders rich data and allows rich formatting, but that stores your data in plaintext under the hood. Would this convince you to switch to plaintext?
I prefer rich text because I can manage styles easily (and update an entire document as needed with style changes), create TOC easily, dealing with citations and bibliographies is easier, and it is far easier to create tables and add images as needed. I’ve used Obsidian, iA Writer, and Craft–I can do all of the above (except style management and bibliographies) in those apps, but it is easier in rich text, and I eliminate a step–conversion. I have one app for writing, and everything I need is readily available, including advanced features. For me, it means less friction, fewer apps, no plugins to manage, and fewer steps to the final product. I hope this answers your question.
This is close to what Craft does, although it uses Jason files. I presume the hypothetical app would only use plain text files.
Why can’t you do “style management” with Ulysses?
You have to simply alter the CSS you use, to do so, and could do it even with simply changing the CSS for all of your files in once, instead of changing every single file. https://styles.ulysses.app/learn/html-styles
I knew you would be the first to reply to this topic! I even read your linked post beforehand As usual, your reply was very informative.
I am not a heavy user of tables - are you doing anything “fancy” with yours (merged cells, formulas, etc) or is the rich text advantage simply less typing and a table that’s less prone to accidentally deleting half the columns?
Yes, but while Craft uses its own JSON format under the hood (although they are quite committed to opening this up further, link to their blog post for those interested), the hypothetical app would use a plaintext format that you could directly use in other apps/editors, including but not limited to Markdown.
This is a lot more complex than a few button clicks in a word processor. Learning CSS isn’t a worthwhile investment for everyone - that being said, I think the CSS-based styling method built into some Markdown editors is pretty neat and a useful consequence of Markdown’s roots in HTML.
You don’t have to learn “CSS” to get an nice Style Sheet, that meet your needs.
I used one that I found on the internet as a base, open Ulysses, the Window where I could see the Text in the Layout Format I choose, and a third window of an text editor like BBEdit, Sublime or TextMate to made the required changes within the CSS to accommodate your needs, and see right away what those changes looks like, in your chosen Layout.
I changed a CSS on this way, to accommodate the needs I have to observe within the German Justice, and it took me less than an hour, to do so.
There are some PlugIns for certain Text Editor to make this easier from Ulysses. https://styles.ulysses.app/reference/editorplugins
Because I don’t know how to change CSS and don’t have the time or inclination to learn. And, while I like Ulysses, I had a scary issue syncing my book project. I’d also like to eliminate another subscription.
That is nothing to be scared about.
Look for a CSS that meets your needs the most, and do little changes to get it perfect the way I (and Ulysses) described.
There is a lot of help from the Ulysses page, if you follow the links above, and there are a lot of Forums, where you will get help in the worth case.
If you have more complex styling to do, working with CSS begins to take up more and more time relative to word processor based styles. I have cooked up CSS with breakfast before, and I agree in many instances it shouldn’t be too hard - but I’ve also engaged in all-night CSS combat before, so I get it from both sides.
But in any case, the problems encountered by people like @Bmosbacker are not, I think, about one specific issue or another, but rather about a “death by a thousand paper cuts”. Sure, CSS configuration only requires about an hour with a text editor. Oh, you want citations? Off you go to learn about pandoc, terminal, BibTex. Oh, you want image resizing? Time to learn about HTML. So in some ways, the actual issue of CSS is irrelevant - it’s the combination that requires you to have or develop a good amount of technical skill, which isn’t worth it for everyone.
In any case, my intention behind this thread is not to reiterate these kinds of technical solutions. I am more interested as to what pain points people have found with plain text, and what advantages they have found with rich text - a discussion which is valuable if we wish to create tools that enable more people to work with plaintext more easily (hence the question about the Hypothetical Plaintext Editor).
I assume you are facing this problem because you need to share an editable document, rather than something like a PDF, which would solve this problem?
That is exactly it! When using plain text I have to constantly “make it work” with the tool unless all I’m doing is straight unadulterated text. That is not the majority of my writing. Even when giving a simple presentation I include citations in my notes in case someone wants the source of information I quote or refer to. There is a reason(s) why rich text and word processors were created.
I think, if somebody really wants to deal with the search for a solution, it will end up with a solution, that simply translates what the user want, into the required code, to change the CSS, HTML or whatever is underlying.
Of course! What do you think Word is doing under the hood when you click those styling buttons?
That’s the awesome thing about this situation - we don’t necessarily need to invent new systems! We just need to package up things that already exist, in a way that doesn’t require you to be a developer to easily work with them.
I know what Word is doing!
The problem you might face with your Approach:
If it would be so easy to do so, it would have been most probably already be done some 20 years ago!
And also, what is the advantage to use a software to alter a CSS via a UI, if you still use a separate software to write your text?
A solution like this would be a nice add on for Ulysses, iA Writer and Apps like this, but I have currently no imagination, to see a real market for this as a single use app!
A quick disclaimer - I am not saying that I am developing a text editor that does this (although I’m not saying otherwise either - it may be an interesting side project). While I agree with this for the most part, it also pays well to keep in mind that the technological landscape now is much different than it was 20 years ago. 20 years ago if I wanted to build a project that processed Markdown I would’ve had to build a parser and editor myself - now, I can just pick one up “off-the-shelf” (link to GitHub).
Well, the point is kind of that this would be 1 unified app. One of the problems Bmosbacker identified earlier is that working with complex plaintext documents requires you to install and familiarize yourself with a whole toolchain of software. We should not require a user to know about CSS to add a cool header to their document.
Refer back to my previous statement re: developing such a text editor. This is not market research - it’s more of an off-the-cuff brainstorm and also an attempt from myself to understand why people pick rich text, as they probably have reasoning that I would not think of (rkaplan’s post being an example of this already).