Which word processor to use

By Soren, 16 February, 2026

Forum
macOS and Mac Apps

Hi.
So, now that pages has joined my no-go list because of apple deciding that a predatory subscription model is a good idea, I will have to change word processors again.
The question at hand is, which word processor is accessible at all?

Options

Comments

By Khomus on Monday, February 16, 2026 - 22:37

You just get extra stuff, mostly AI junk as far as I can tell, if you subscribe. Also maybe some templates or something.

https://appleinsider.com/articles/26/01/13/pages-numbers-and-keynote-are-still-mostly-free-but-we-dont-like-the-trend

I mean, sure, they don't like *the trend*. Anybody can look at a change and go, "they're gonna do more of that, you just hide and watch"! They don't know that. I don't know that. Nobody knows. They could make it all subscription all the time tomorrow, or it could be just like it is now for the next twelve years.

By TheBlindGuy07 on Tuesday, February 17, 2026 - 03:56

Stop moaning guys, iwork is still free, the worse that can happen is ads for apple creator studio.
ACS execution around iwork is nothing less than a terrible poor joke to me, if they really wanted people to pay for templates they should have put it in apple one or icloud plus.
I use pages because iwork is still free!
HTH.

By Soren on Tuesday, February 17, 2026 - 10:09

I am sorry. But you just can not get me to support an ad or subscription based word processor. Not if they press the subscription into your face like pages does constantly. Therefore, my question still stands.

By TheBlindGuy07 on Tuesday, February 17, 2026 - 12:22

If you want the closest equivalent to pages on mac with VO, then good luck. Eulicies is the only thing I can think of without ever having trying it. Otherwise, forget google suite, it's usable yes but nowhere close to the experience on windows. Outside iWork? Switch to windows as much as I don't like this, iwork is still the only viable productivity suite with a good accessibility experience. Or just use pages, like outside of the popup it still works great. iCloud Plus is advertised in system settings too.

By Alicia Krage on Tuesday, February 17, 2026 - 14:17

I use text edit, which saves documents in a RTF format. I haven't really done much with Pages. From the brief look I got, I didn't really like the interface.

By Jason White on Tuesday, February 17, 2026 - 15:50

I updated to Pages 15, and it doesn't require a subscription. I agree that Pages is still the best option on macOS.

I personally use a markup language and a text editor rather than a word processor for most of my writing as a matter of preference.

Much proprietary software is subscription-based these days. Eitehr get used to it, or consider free software/open-source alternatives.

By Joshua on Tuesday, February 17, 2026 - 17:44

i don't know how it is on mack but it's awesome on windows, i love it and use it sometimes

By Jason White on Tuesday, February 17, 2026 - 18:45

It's largely accessible with a screen reader under Linux, but I've never tried it on the Mac.

By TheBlindGuy07 on Tuesday, February 17, 2026 - 18:55

Everything is largely inaccessible on the mac, great on windows and gnome with orca on fedora (writer) :(

By Igna Triay on Tuesday, February 17, 2026 - 20:59

At least it hasn't for me. In any case, look at the bit in the appstore description where it says creating editing, colaborating are still free... But yeah am not getting this to my face. Besides, let’s be honest, even if you get the type of things, were you’re constantly asked to subscribe, which app doesn’t do it? Microsoft? guilty. Google? Same thing. All subscriptions platforms are in your face to, subscribe. Its not only a pages thing and for what its worth; pages doesn't just do it in your face; its only if you press choose template and if you press on one of the premium templates... I'm sorry, but that is not in your face one bit. Microsoft, google etc, are waaaaaaaaaaay more in your face than this one.
Yeah, to answer your question, pages is your best bet. Either that, or text edit.
Edit, just tested it. New document? No in your face. Choose template? No in your face... Again, sorry, but this? Is not in your face one bit as @op says it is.
Libra office... not accessible, however, its not on apple that they don't support qquarts; or that voiceover doesn't as someone said. libra office could be made accessible if they followed apple's guidelines on how to make apps accessible with voiceover... That's on the libra office devs; not on apple. That's like saying oh this windows app doesn't run propperly on windows! Yeah, because you didn't follow the propper way to actually port it to windows or to make it windows compatible. Is it microsoft's fault? Hell no; its on the developer, not the operating system developers.

By Khomus on Tuesday, February 17, 2026 - 21:25

Did they break something? I reported on this last year and though it wasn't great, you could write text in Writer and arrow around in it and such. People were claiming it was totally inaccessible, as in it wouldn't even read the window, and that's not true anymore.

I don't know if its usable, because I don't do enough word processing to care about messing with it. But somebody should really investigate, because the last time this came up, there was a lot of "it's totally inaccessible, but I tried it two years ago".

Weirdly, things can change over time. So maybe things are different from two years ago, you know?

By Bruce Harrell on Tuesday, February 17, 2026 - 21:57

What sort of word processing do you want to use it for? If nothing fancy, use Text Edit, which offers nothing fancy and is very simple/easy to use. smile

By Igna Triay on Tuesday, February 17, 2026 - 23:21

Not sure, I tried it a few months ago just to see if something had changed but no such luck, at least per my testing. Might have to try it again after a bit though just to see if anything has changed out of Curiosity. To be bfair though, there's nothing stopping people from getting in contact with the devs to see about improving accessibility as well.

By Khomus on Tuesday, February 17, 2026 - 23:46

When I tried it you could install it and run Writer. You could write text in Writer, and you could use the arrows to move around which means you could get it to read to you and proof it. I don't think VOa worked if you wanted to read the entire document, and I don't remember if the standard commands like opt-left/right moved by words and such.

I tried it very briefly, because like I said, I don't do enough word processing to worry about it. This was under some version of OS 15. I doubt it's really fully usable, especially if you're doing heavier word processing. But the very basics seemed to be more or less functional anyway.

I can't find the thread where I originally commented, so I don't know if it's just gone or if I'm bad at searching. I'll try looking again after I'm done with my workout. But if you can do the basics, it may indeed be worth it to talk to the devs about accessibility, or see if there's any ongoing improvement.

By João Santos on Wednesday, February 18, 2026 - 01:29

Personally I just write Markdown with some LaTeX and HTML sprinkled in when I need more customization, and honestly have no idea why anyone would need anything else, but am always open to be educated on this.

Markdown has been around for over two decades now, and is becoming a de facto portable document source format due to how easy it is to parse and convert to all kinds of final document formats like PDF and HTML, or even other source formats like LaTeX which are native to tools like pandoc. It was also the output format of choice picked by OpenAI when they launched ChatGPT in 2022 because there's no shortage of parsers and converters available for it, so all large language models use it these days.

This comment was written in Markdown, which I've been using since 2007 myself, as it was the only option available on reddit when I created my first account on the platform back then. My editor of choice is TextMate, which I use for pretty much everything that does not directly target Apple's platforms.

By TheBlindGuy07 on Wednesday, February 18, 2026 - 03:32

The thing is, even in the CS program I am, the people (usually very outdated at best) who're officially government mandated to adapt stuff for accessibility do a terrible job of writing shitty boilerplate bbcode like placeholder inside .docx produced like .doc of 2003s with 0 respect for readability by their very audience, among other blind people with only a limited numbers of braille cells. No latek, no tagged proper office math equations, and things like {ms} for the - (minus) sign everywhere (yes I'm not kidding).
For personal stuff, yes, pandoc is in the first utilities I always install even on experimental test machines like chrome os flex, asahi linux on mac, and obviously all the oses I do daily work on. It must be more than enough for most people, heck even google docs supports markdown.
But this ideally, so of course it never happens.
And there is (for me at least) a sense of comfort in gui apps (when accessibility usually follows) like pages on mac or word on windows which can have advantages over raw well tagged markdown or similar code. I'd be a heavy user of latek but we most often get untagged pdf downstream, rarely the raw documents in academics. Not to mention the nonsense of platforms like ebscohost or other pearson+ and similar for drm vendor locked subscription based textbooks......... But this is beyond the scope of this thread :)
TLDR I'd love to get away with markdown imported in and markdown out, but it's kinda difficult.

By Soren on Wednesday, February 18, 2026 - 08:29

From reading the markdown readme, It seems like that does Everything I ned. However, I Have to work with massive documents at times. We are talking 20000 pages of tables, images and all kinds of other messed up stuff. Is there a markdown editor that could convert these from docx format and allow me to view them with out going busy busy busy or not responding which is just an eufemism for busy all the time?

By João Santos on Wednesday, February 18, 2026 - 09:09

Microslop maintains a Python tool called Markitdown that is allegedly capable of doing such a thing, but I've never used it myself so cannot talk from personal experience, and would like your feedback if you try.

By Soren on Wednesday, February 18, 2026 - 10:00

I will most certainly try this one.

By Holger Fiallo on Wednesday, February 18, 2026 - 10:07

A long time ago in a far, far galaxy he did demo of a nice one. Do not recall the name but if you are able to send him a text or email, you could ask. I wished I could recall the name. Long live cats.

By Chamomile on Wednesday, February 18, 2026 - 21:40

Pages is still free. VoiceOver is insanely verbose. For example: I pulled out my Mac and tested both Pages with VoiceOver and Word with NVDA/JAWS for writing a story chapter. After each word, VoiceOver would try to predictive text guess the word halfway through writing it and would give me the text info "Body, Helvetica Noya, blah blah blah" after every word. I don't think I even managed to finish writing a paragraph, whereas it was a breeze using Windows.

FWIW - Google's worksuite isn't necessarily subscription based as long as you store less than 15GB (which is more forgiving than iCloud's 5GB, but at least the 30GB iCloud plan is $1.50). I personally find paying for Microsoft Office expensive (around $180 per year for the family plan but I'll bump down to a personal plan. Around $11 a month. Netflix is more expensive). But I swear by OneDrive and use Office on a near-daily basis even outside of work.

By TheBlindGuy07 on Wednesday, February 18, 2026 - 21:56

Predictive text and announce attribute changes (unless when I need it).

By Chamomile on Thursday, February 19, 2026 - 00:34

Thanks, I honestly didn't know that was a thing, so that's a good thing to keep in mind for OP.

By Jason White on Thursday, February 19, 2026 - 23:32

I would suggest Pandoc, which should have no trouble converting large documents to Markdown format. Then edit the Markdown using your text editor of choice.

By João Santos on Saturday, February 21, 2026 - 01:27

I find pandoc useful for translating content from Markdown with HTML and LaTeX to PDF that is suitable for the sighted, but its reliance on LaTeX as its native source format comes with accessibility limitations. The problem is that LaTeX itself was never designed to produce documents with semantic metadata, and last time I checked it had absolutely no support for tagged PDF so viewers like Preview on macOS can only do so much when it comes to providing accessibility to PDF content converted using pandoc.

Another problem with pandoc which I believe also stems from LaTeX is its inability to handle non-ASCII script properly, and that includes the ISO-8859-15 also known as the Latin15 character set which represents the first 256 Unicode code points that in turn is also the most common script used in the western world. This means that common accentuated western characters that already have dedicated code points in Latin15, end up being represented as alternative Unicode grapheme clusters that screen-readers may have trouble conveying through speech synthesis or Braille, although I do recognize that this is all part of a larger problem which is that Unicode is a horrible over-engineered mess in my opinion.

Tools like MarkItDown that I mentioned above may or may not handle both problems better. Although I'm not really sure if MarkItDown itself can convert from Markdown back to DocX or even PDF since, as I said earlier, I've never actually used it myself. MarkItDown is only a project that I found interesting and starred on GitHub some time ago for being potentially useful to extract semantic information out of complex Microslop document formats, and being built by the same company that specified those formats likely means proper support for them.

By Chamomile on Sunday, February 22, 2026 - 07:41

Sorry if that seems abrasive or argumentative. I've never used Markdown, never had a use for it because things like Control + B etc are generally fine and easy enough to do.

By João Santos on Sunday, February 22, 2026 - 12:09

Markdown is a widely used documentation markup language designed to be easily read and written as either plain-text or in formatted form. Essentially you write plain-text documents following some conventions that allow them to be rendered to stylized documents with little to no negative impact on the readability in plain-text. It's also very easy to parse and convert to any other format so it's quickly becoming the de facto standard for source text.

The source-form readability and writability in plain-text is what makes Markdown so appealing compared to other document formats. Whereas a DocX, for example, can be read and exchanged in XML form, XML itself is extremely verbose, and the document standards that use it make everything orders of magnitude worse for direct human consumption or production. Markdown, on the other hand, is quite easy to parse both by humans and machines, which is what makes it so appealing, and it can also be extended in a number of ways, thus making it possible to include features not available in common Markdown like audio and video playback, mathematical notation via LaTeX or MathML, direct HTML content, or anything you can think of, since it's quite flexible and the extra features depend entirely on what parser you're using. It can also be written using a common graphical editor, like all other formats, but being able to write it in plain-text is the killer advantage for me since it's quite liberating and allows me to produce all kinds of documents from a pretty normal code editor, while abstracting away pretty much all the mental drag associated in writing in other source document forms such as LaTeX.

By Khomus on Sunday, February 22, 2026 - 17:21

It also simplifies some things. I'm too lazy to look up the exact symbols, so I'm making this up. But for instance, if I want to do a link, instead of less-than, a href, equals, URL, greater-than, quote, text, quote, and so on, you just do like left bracket URL, right bracket, and text.

Also, if I use something like ctrl-b, then I have to figure out how to get the screen reader to specify font formatting and such to make sure I've started and stopped it in the right place. With Markdown, you have a readable code, sort of like HTML where you do something like less-than b, text, then end it.

Since it's straight text, it's smaller, and since it's humanly readable, you can read it and figure out what's going on, even if you don't have a program that makes it look all pretty. Try that with a Word document.

Oh also, back to apps, you can often use it in place of other things, e.g. if you have an inaccessible web-based editor, if it understands Markdown you can just write it in whatever and paste it in or upload it in some way.

This may or may not be stuff that you actually care about. But it shows up in a fair number of places, notably for most people, I suspect, if you do anything with a Wiki, that's using a form of Markdown.

By João Santos on Sunday, February 22, 2026 - 18:54

there are three alternative ways to add links to text in common Markdown, which I use most of the time to move the link metadata out of the text to footnote references at the bottom of the source document or to the end of the paragraphs containing them.

The conventional way to specify a link in Markdown involves writing the hyperlink text between brackets immediately followed by the URL and an optional link title between parenthesis, like in the following example:

[Hyperlink to AppleVis](http://www.applevis.com/ "Title of the hyperlink rendered as a visual tooltip when the mouse hovers over the text or as a hint to screen-reader users")

Which renders as follows:

Hyperlink to AppleVis

The first alternative hyperlink form, which I personally find a lot more convenient to read in plain-text, still uses brackets around the link text, but instead of being immediately followed by the URL and optional title in parenthesis, is followed by a single word with just ASCII letters or numbers between another set of brackets, with the letters and numbers inside acting as an identifier to be referred later as a footnote as follows:

[Hyperlink to AppleVis][AppleVis]

[AppleVis]: http://www.applevis.com/ "Title of the hyperlink rendered as a visual tooltip when the mouse hovers over the text or as a hint to screen-reader users"

Which renders exactly the same output as follows:

Hyperlink to AppleVis

The second alternative hyperlink form, where the identifiers themselves are rendered as hyperlinks in superscript notation, is formed by just writing a stand-alone identifier between brackets and separated from the surrounding text by spaces, and then referring them in plain-text footnote reference style elsewhere in the document, as follows:

Reference to AppleVis [AppleVis]

[AppleVis]: http://www.applevis.com/ "Title of the hyperlink rendered as a visual tooltip when the mouse hovers over the text or as a hint to screen-reader users"

Which gets rendered as follows:

Reference to AppleVis AppleVis

Finally, the footnote links that I also mentioned as a slight variant of the previous example, are written exactly the same way in plain-text, but differ in that the identifier between the brackets must be prefixed by a caret, the text in the footnote is not a URL itself as linking to external sources is not the intended purpose, the identifiers are replaced by ordinal numbers in the final rendering, and the footnotes themselves are rendered at the very bottom of the document, like in the following example:

Footnote about AppleVis [^AppleVis]

[^AppleVis]: AppleVis is the premier online resource for blind, DeafBlind, and low vision users of Apple technologies.

Which gets rendered as follows:

Footnote about AppleVis 1

Immediately following this comment, I will post yet another comment with this comment's Markdown source rendered in code voice, so that the people unfamiliar with the convention can have an example of its practicality, as I write all these rich-text documents in Markdown myself.


  1. AppleVis is the premier online resource for blind, DeafBlind, and low vision users of Apple technologies. â†©ï¸Ž

By João Santos on Sunday, February 22, 2026 - 18:59

As I promised in the above comment, below I post its Markdown source in code voice as it was written in plain-text for people to grasp the practicality of this format (I will not do the same recursively to the source of this comment though):

there are three alternative ways to add links to text in common Markdown, which I use most of the time to move the link metadata out of the text to footnote references at the bottom of the source document or to the end of the paragraphs containing them.

The conventional way to specify a link in Markdown involves writing the hyperlink text between brackets immediately followed by the URL and an optional link title between parenthesis, like in the following example:

    [Hyperlink to AppleVis](http://www.applevis.com/ "Title of the hyperlink rendered as a visual tooltip when the mouse hovers over the text or as a hint to screen-reader users")

Which renders as follows:

[Hyperlink to AppleVis](http://www.applevis.com/ "Title of the hyperlink rendered as a visual tooltip when the mouse hovers over the text or as a hint to screen-reader users")

The first alternative hyperlink form, which I personally find a lot more convenient to read in plain-text, still uses brackets around the link text, but instead of being immediately followed by the URL and optional title in parenthesis, is followed by a single word with just ASCII letters or numbers between another set of brackets, with the letters and numbers inside acting as an identifier to be referred later as a footnote as follows:

    [Hyperlink to AppleVis][AppleVis]

    [AppleVis]: http://www.applevis.com/ "Title of the hyperlink rendered as a visual tooltip when the mouse hovers over the text or as a hint to screen-reader users"

Which renders exactly the same output as follows:

[Hyperlink to AppleVis][AppleVis]

[AppleVis]: http://www.applevis.com/ "Title of the hyperlink rendered as a visual tooltip when the mouse hovers over the text or as a hint to screen-reader users"

The second alternative hyperlink form, where the identifiers themselves are rendered as hyperlinks in superscript notation, is formed by just writing a stand-alone identifier between brackets and separated from the surrounding text by spaces, and then referring them in plain-text footnote reference style elsewhere in the document, as follows:

    Reference to AppleVis [AppleVis]

    [AppleVis]: http://www.applevis.com/ "Title of the hyperlink rendered as a visual tooltip when the mouse hovers over the text or as a hint to screen-reader users"

Which gets rendered as follows:

Reference to AppleVis [AppleVis]

[AppleVis]: http://www.applevis.com/ "Title of the hyperlink rendered as a visual tooltip when the mouse hovers over the text or as a hint to screen-reader users"

Finally, the footnote links that I also mentioned as a slight variant of the previous example, are written exactly the same way in plain-text, but differ in that the identifier between the brackets must be prefixed by a caret, the text in the footnote is not a URL itself as linking to external sources is not the intended purpose, the identifiers are replaced by ordinal numbers in the final rendering, and the footnotes themselves are rendered at the very bottom of the document, like in the following example:

    Footnote about AppleVis [^AppleVis]

    [^AppleVis]: AppleVis is the premier online resource for blind, DeafBlind, and low vision users of Apple technologies.

Which gets rendered as follows:

Footnote about AppleVis [^AppleVis]

[^AppleVis]: AppleVis is the premier online resource for blind, DeafBlind, and low vision users of Apple technologies.

Immediately following this comment, I will post yet another comment with this comment's Markdown source rendered in code voice, so that the people unfamiliar with the convention can have an example of its practicality, as I write all these rich-text documents in Markdown myself.

By Jason White on Sunday, February 22, 2026 - 20:28

Responding to the earlier comment about Pandoc and its use of LaTeX:

LaTeX now has some support for generating tagged PDF. It isn't enabled by default; you have to add commands at the beginning of your LaTeX document. If you want to do this via Pandoc, you'll need to edit the LaTeX template, which Pandoc makes it fairly easy to do.

Also, modern LaTeX supports the UTF-8 character encoding, so I don't know what's causing the reported character set issues.

Finally, pandoc can also generate PDF using Typst rather than LaTeX, and Typst recently added support for tagged PDF. You can of course write documents in Typst or LaTeX directly rather than using Markdown or Pandoc.

By João Santos on Sunday, February 22, 2026 - 21:34

LaTeX now has some support for generating tagged PDF. It isn't enabled by default; you have to add commands at the beginning of your LaTeX document. If you want to do this via Pandoc, you'll need to edit the LaTeX template, which Pandoc makes it fairly easy to do.

I still wonder how this is actually going to pan out, since all the typesetting functionality on top of TeX including LaTeX itself is external to the engine. This means that the engine knows absolutely nothing about the semantics of the content that it's rendering, which in turn means that unless all the fundamental packages are updated to produce accessible content, nothing is likely to change in practice.

Also, modern LaTeX supports the UTF-8 character encoding, so I don't know what's causing the reported character set issues.

Unicode is much more than UTF-8, which is merely a kind of Huffman compression on Unicode code points and doesn't deal with the more complex aspects of unicode like grapheme clusters, since UTF-8 is only concerned about the serialization aspect of Unicode. Unicode is extremely over-engineered, and as someone who grew up using technology long predating its widespread use, who has experienced all the encoding pains with little to no benefit during the transition period, I maintain a very strong opinion against that standard. If you think UTF-8 is complex, the only thing I can say is that parsing UTF-8 in particular is child's play compared to parsing Unicode in general.

The biggest problem with Unicode is that it's so complex that very few people actually even have any kind of notion of how overwhelming it really is, and that in turn leads to lots of simplifications from people who, like you, underestimate the standard. This, coupled with most influential software engineers being natives of the western hemisphere, which is also my case, means that most of the problems resulting from the complexity of Unicode, which was pretty much designed around 7-bit ASCII, are not experienced very often by the people around us in particular. However as I said I grew up without Unicode and had to deal with the pains of the transition period as a professional, which here in the EU were especially annoying to deal with since we use accentuated characters that are not part of 7-bit ASCII despite most of our script being comprised of ASCII characters, which meant that very often I had to deal with languages, libraries, and even databases that either disagreed on the character set, did not understand any of the Unicode encodings, assumed that everything they got was Latin-1 or Latin-15 and resulting in double-encoding when it was already UTF-8, or tried to deal with content as 7-bit ASCII meaning that all accentuated characters were translated to question marks. Unknowingly to me back then though is that was only the tip of the iceberg, as the more subtle problems like associating all the possible grapheme cluster representations of the same glyphs, in order to mitigate against security threats exploiting the way characters are visually presented to human beings, require unnecessarily inefficient solutions, like just rendering the text and using computer vision techniques to perform tasks that, before Unicode became widespread, were as simple as just comparing numbers, and the worst of all this is that we aren't really using most of the features provided by the standard, so in the end fully implementing it results in providing a huge attack vector to be exploited by malware and used to work around spam filters for phishing attacks.

The way LaTeX itself, or rather the LaTeX PDF render as well as whatever pandoc uses to render HTML, fail when it comes to Unicode, is precisely in producing alternative grapheme cluster representations of accentuated characters that have dedicated code points in Unicode, like the A tilde example that I mentioned in an earlier comment. That specific glyph, very commonly used in Portuguese to denote a nasal pronunciation like in my own name, can either be represented using a single code point for the Latin-1 A tilde or as a grapheme cluster involving the ASCII A coupled with a tilde diacritic, likely resulting in the same visual representation with completely distinct serializations, and these are only two ways in which an A with a tilde can be represented, as Unicode allows people to get really creative with grapheme clusters to represent all kinds of glyphs, like you can put an acute accent on a Z, R, or L, which are all cases with no practical use in any script as far as I know, so short of really understanding the visual output of the text, there's no bullet proof way to deal with this problem.

Finally, pandoc can also generate PDF using Typst rather than LaTeX, and Typst recently added support for tagged PDF. You can of course write documents in Typst or LaTeX directly rather than using Markdown or Pandoc.

Yeah, pandoc loses most of its appeal if I'm going to write a document in typesetting code myself. To me personally it's only really useful to render Markdown as PDF.

By Chamomile on Tuesday, February 24, 2026 - 05:33

Thanks, you're always a wealth of resources :)

By TheBlindGuy07 on Tuesday, February 24, 2026 - 13:42

I thought like probably many others that utf8 and unicode were interchangeable :)
Thank you for educating us juniors!

By João Santos on Tuesday, February 24, 2026 - 14:58

While I tried to stick to the example that I provided when I mentioned the problems with Unicode, the fact is that it goes way beyond that example, as a fully implementation of Unicode includes having the ability to mess with the text renderer itself. This means applying linear transformations on text like turning it sideways or upside down, scaling, squishing or stretching it, and even moving it from its default location; changing the justification to the opposite side like in Arabic, writing invisible characters, and of course, drawing lots of emoji variants by including semantic information in the grapheme. For example drawing country flags involves a grapheme cluster comprised of a sequence with two code points, each of which representing a letter in the alphabet with a special region indicators, so the US flag would be represented by a graphene cluster including region indicator U and region indicator S in this sequence, whereas the Portuguese flag would be region indicator P and region indicator T in this sequence.

All the above stuff together makes Unicode the extremely over-engineered mess that I mentioned earlier in the thread, making complete implementations huge attack surfaces to be probed and exploited by malware authors. This happens both because the implementations themselves end up being quite complex, but also because by providing perfectly mundane strings with the ability to influence how they get rendered makes Unicode quite convenient to fool sighted readers.. Over the years there have been a number of reports of denial of service attacks in which someone making your device display specially crafted grapheme clusters was enough to force the device to reboot and even in some cases even soft-bricking it in a reboot loop state, and I'm also under the impression that these attacks have been exploited in zero-click exploits to install malware in the past, but take this claim with a grain of salt because I didn't bother verifying.

***

Editing to replace zero-clock with zero-click.

By Brian on Tuesday, February 24, 2026 - 16:42

This is why email spam subject lines and even message body content can, "look", legit. Because you can get an email that is seemingly from a legitimate source like Amazon, Social Security Administration, your financial institution, and other such organizations, when in actuality it's from a malicious individual whose intent is to infect your system with exploitative software in order to obtain personally identifiable information about you, all in the name of prophet of course.
The only saving grace about this would be that screen readers can, usually, pick up on these extra characters if you just pay attention to what your screen reader reads out when reading the subject line, or preview of an email message you received.

By Roaratron on Saturday, February 28, 2026 - 03:52

I would give Ulysses a try. It's great for writing large documents with Markdown.