What about the existing "standard", PowerPoint slides and PDFs? Although most of my notes could be plain-text, any graphs or figures need pictures. ASCII art doesn't cut it.
Plain-text just needs to be the format. Checkout (e.g.) Markdown editors like Typora. The underlying format is Markdown, but it can be edited and displayed in a more visual fashion.
With the text being in plain-text, it guarantees someone the base ability to just open up (e.g.) Notepad.exe if all else fails vs. trying to open up a Powerpoint '97 presentation with embedded RealMedia files in 2017.
There are two answers to that. One is that to fully support these rich formats you have to have compete feature parity with Office, which isn't trivial. The other is that we're comparing to plain text, which doesn't even pretend to give you any control over how things look.
The alternative offered is Markdown. How can you say that it's ok for Humans to revert to raw Markdown, but unacceptable to open a legacy .ppt format in an application that may not render with 100% fidelity?
No one ever said that humans need to write raw Markdown. Take a look at Typora as an example Markdown editor. Raw Markdown would be the fallback scenario, which is still readable/grok-able. docx/pptx/xlsx don't have such a fallback scenario.
There are countless software packages that can edit and display Office XML files besides just the Office package, so I'd think the fallback scenario is using one of those.
If you're going to propose an standard for graphs and figures, please make it SVG. It's hard to find tools for editing PDF that would support text and graphics, and PowerPoint exists only as a proprietary closed format.
unfortunately, since svg is a web standard, it can reference external objects
that severely limits its adoption with people that spend all their days defending the idea of 'attack surface'. so google draw uses svg, and exports svg, but won't import svg. github won't inline svgs in md, etc
i don't personally like the svg design, its got a lot of weird corners and has the usual screwy relationship with the DOM. but having a fully neutral vector format would be such a massive win, by all means svgs if you can get it more widely adopted...maybe some sort of sanitized/sandboxed svg subset.
postscript should have been that format, but they were so focussed on driving rasterization that they made any kind of other interpretation (i.e. editing) impossible.
What does that link intend to prove? The Office Open XML standard relies heavily on hidden implementation details of the Microsoft Office software suite.
From what I've heard, the MS Office applications do not even entirely comply with the published specification. So OOXML is still not a definition of the format with which PowerPoint stores its files.
Your source claims the spec contradicts previous adapted ISO standards, not that it contradicts itself (which is what I assume you mean by it not being self-consistent). It does, however, raise the issue of bits like legacy compatibility for Word 97 behavior and scripts not being documented.
Well, no, it is self-inconsistent in places [0]. However, as you mention, those are probably minor points compared to how it contradicts existing standards, like the Gregorian calendar [1], date representation, and language codes.
Those are annoyances and give increased complexity. They are not, as you described earlier, inconsistencies that make the spec impossible to implement.
Other standards, and web standards in particular, tend to have several open source implementations to guarantee that it's possible to build tools that support it without being the reference implementation. OOXML has no such thing, and the reference implementation is closed source, so it's basically impossible to replicate in any practical sense.
Not fully compatible with PowerPoint, no. That's why I said the PowerPoint format is proprietary; it's impossible to build a working interoperable tool, because either parts of its format remain secret and do not follow the published standard, or the format itself makes references to hidden implementation details.
Having an open source tool that can open files created on PowerPoint without them becoming horribly mangled, or vice versa, is a very realistic concern. Microsoft Office is well known for being extremely difficult to make its file formats portable beyond the very basic layout features.
Given a sufficient device it's actually a fairly decent format. The problem is that that device has to relatively closely correspond to printed paper sizes, within a factor of about 75% - 125%.
What PDF offers is a consistent, space-persistent, formatted output. For reading longer works, it actually does matter to me where a passage appears on a page, or within a work. Spatial memory is important that way.
I read a lot of material, in a lot of different formats: paged text (manpages, console-mode browsers), formatted HTML, ePubs, DJVU, image-scanned books.
If I'm reading on a largish (9-10") tablet, PDF in one-page-up format is actually really good. Fills the screen, is almost always suitably readable. Scans of old books (thank you, Internet Archive and Google) in particular are a delight -- there's something about reading a century-plus-old library copy with markings and (hopefully not too much) marginalia, as well as the original typesetting and images.
The main problem I have with fluid formats ultimately is their fluidity. I realise that that's perverse, and that there are times when it's a real benefit, but again, I can't seem to get away from that spatial memory thing.
If I'm extracting content from works, I prefer source (LaTeX, Markdown, DocBook, etc.). Though that's another story.
The ability to spin out formats on demand would be an ideal. I'm looking into ways of doing that.
> If I'm extracting content from works, I prefer source (LaTeX, Markdown, DocBook, etc.). Though that's another story.
except it's not actually another story. it's just a different part of the same story. and a format (like .pdf) which only handles one part of the story well (such as reading) but falls apart on another part (like text reuse) is not -- ultimately -- a good solution.
but that doesn't mean .pdf is worthless. yes, it's worthless as an archival format, and as a distribution format. (and those two are the ones which people commonly pitch as _strengths_ of .pdf, unfortunately, which is misguided.)
but .pdf is fine as a one-off output-format, spun out in an on-demand fashion by an end-user who wants .pdf for their own personal reasons (which require no justification to us). this is what you mention at the end of your comment, and i, too, am working on that...
As you note: if PDF is what you want, then the option to request it, or whatever other format is your preferred option, would be excellent user-centric behaviour.
The idea of requesting, say, <item>.<extension>, where extension is [html,pdf,epub,djvu,txt,json,tex,md,csv,dir,...] would be interesting.
This presumes that there's a way to represent the content as, say, a directory listing, CSV, or JSON archive.
pdf is my prefered format of storing information, after markdown and source code, of course. It allows me to portably crystallize visual information without resorting to images which completely wipe out textual information.
