Because it is built on three layers of inaccurately-parsed encodings.
“Standards and wonderful – so many to choose from!”
Plain text
First came plain text to emulate and automate the typewriter.
So we had ASCII printable characters 32 to 127, beneath which were encoded via control codes to command typewriter actions to move the “paper” around.
Critically, 10 rolled paper down a line, while 13 returned the print position to the start of the line.
At this point, plain text went tribal; some expected a normal carriage return to do 13 only, others though it cheaper for 13 to imply a full 13, 10 (or is that 10, 13) sequence.
This UNIX vs. DOS squabble screws up text to this day.
Rich text
After emulating the humble typewriter, word processors privatized attempts to encode the full printing press. Rich Text Format was an early attempted standard, the way XML-based open alternatives [1] to MS Word may do today, while the PostScript printer control language morphed into PDF, the de facto standard to preserve DTP layout as editable text.
So far, so messy - but wait, it’s about to get worse.
To embrace the world’s glyphs beyond US/UK English, character size doubled from 8-bit bytes to 16-bit Unicode characters.
That in itself added a new spin to tribalized ASCII vs. ANSI vs. IBM vs. bits lost to transmission overheads. Let’s skip the quagmire of code pages, MIME encodings, 8-bit extensions for now (ideally, forever)...
ASCII defined 7 bits, with one bit of a byte (first or last end? pick your tribe) free for other use. But communications needed more bits that either had to be stolen from characters, or padded in such that 10 communication bits carried a character or control code.
Typically, these added communication control bits meant Parity, Escape, etc. (I can’t recall the details, dial-up notworking modems were so long ago and therapy has helped forget the horror)
So… there’s all that - but that was before HTML Hell.
HTML
HTML said; “forget rigorous formatting and DTP typesetting, let’s cheapen and enshittify that to simply pouring enriched text into whatever container the display device makes available”.
Not a bad idea in itself, but screwed up by three deep problems.
First, it inherited the “one lump or two” 10, 13, 10+13, 13+10 Carriage Return squabble, and to that, added a cavalier disregard for white space.
Spaces, tabs and line breaks get stripped and simplified to whatever deranged mess the parsing code deems appropriate. Program-to-blog has been a nightmare ever since.
Second, Gates’ Windows 98 “everything is a web page” mania that spread HTML into CHM Help files and HTT Folder Views, coincided with the big ‘oops’ of OOP - which created the exploitable mess we endure today.
Object Oriented Programming meant that everything was to be treated as an Object, with Properties (hidden internal variable) and Methods (code interfaces to expose variables… and ‘do stuff’).
So what was harmless readable text became a script-encrusted code risk… by design.
Third, “RTF’s Revenge” was added to the mix.
While HTML dumbed down text layout, Markup was added as a way to candy-up Comments and bloggery in general. This supported *bold*, /italics/, _underlining_ and to provide an antidote to proportional fonts, so that spaces to align columns could finally work like a real typewriter… but why bother, when HTML will screw that up anyway, unless it understands the ‘display as code’ directive.
All this in the hope some formatting bling will reduce ENRAGED ALLCAPS SCREAMING in Comments; don’t you know ALlCAPS should only be used to make EULAs unpalatable in tiny scroll-to-death frames?
So:
We now have three levels of interlocking syntax to parse; plain text control codes and escape sequences, HTML, and Markup. This is further polluted via Word behavior, e.g. “smart quotes”, should ‘text’ be pushed through .doc(x) rather than the Open word processor ODF file format that nothing in the ‘real’ (commercialized) world seems to use.
Can AI Help?
I submit to UI pressure and chat to Gemini, who understands the problem but cannot fix it, thus failing the performance evaluation part of the interview.
We chat, and at the end I ask for a transcript to paste from Google’s AI, through Google’s Android clipboard, into Google’s Docs App to store on Google’s Drive so I can FINALLY download ‘my’ chat back to my Android phone, so I can get it off the phone as a file to my PC via USB to pretend my content hasn’t been sucked into the Cloud.
The result is a total folkup. Fails to Copy to clipboard. Fails to Paste into Docs. Does not Select All, only some stuff. No alerts or errors of course, so things may look as if they worked, only to find you only have the last AI response of an hour-long 10-prompt Chat.
AND THEY WONDER WHY WE SCREAM IN ALLCAPS. Do you have an emoji for ‘tears of frustration and retching’? I do... &-Q
PS: [1] I asked CoPilot of ODF was based on XML, and it replied:
Not based on XML
OpenDocument Format (ODF) is not based on XML. ODF is an open file format for word processing documents, spreadsheets, presentations, and graphics, developed with the aim of providing an open, XML-based file format specification for office applications. It was based on the Sun Microsystems specification for OpenOffice.org XML and is published as an ISO/IEC international standard ISO/IEC 26300 – Open Document Format for Office Applications (OpenDocument).
So... it’s not based on XML, because it’s developed to provide an XML-based file format.
In other news, this chunk of AI-generated text line-breaks in the middle of words when pasted into this post (via LibreOffice Writer), as every “space” character is a no-break-space character, using a different underlying character code that looks the same (hello, homoglyph exploits)
