Bugs & Fixes: Poor Rich Text Format (RTF) support in iOS
Posted 17 February 2012 - 03:39 PM
I remember being able to do this on my BlackBerry
Posted 18 February 2012 - 09:30 AM
The problem isn't confined to iOS. Look at OS X. It's only marginally better. Text handling on Macs assumes that WordStar circa 1982 was the last word in word processing. That's when the execs at Apple first got into computing. That's the ruler bar and the obsession with copying and pasting font specs literally and blindly.
Apple's only concession to change since then is to save/read/write/copy/paste with a limited set of rtf coding. That's why core features from Word 4.0 from the late 1980s, over twenty years ago, aren't there. I'm referring in particular to named paragraph and character styles, aka semantic markup. Semantic markup is an absolute necessity if text is going to be able to move intelligently from an iMac's 27-inch screen to an iPhone's 3.5-inch one. Keeping the same font size for a heading just isn't going to work. And yet, apart from HTML, neither OS X nor iOS understand anything about it. That's insane.
Those who work with text have, for the most part, given up on Apple and have become dependent on clever ideas from third-party developers. Dealing with bloated Word is a time-wasting distraction, only exceeded by the mess that results when we try to import a Word file into anything else. Adobe has been trying to get that right for at least ten years and still hasn't succeeded.
What writers and third-party developers are doing is bypass rtf completely, opting for MultiMarkdown and its kin. It's an easy way to code both semantics (i.e. headings and subheading) and formatting (i.e italics) that moves from app to app and for various uses from printed books to blog pages without all the hassles of rtf coding developed over twenty years ago or Apple's woefully inadequate text tools.
And Apple continues to remain clueless. iBooks Author fits the way-behind-the-times workflow of major textbook publishers, with a Word file for each chapter. I know. I worked for Pearson. What it doesn't do is fit with the work process being adopted by writers and the smarter app developers.
Why do I need to create a separate Word file for each chapter to bring text file into IBA. Why can't I feed it a Markdown file where # signals a new chapter, ## signals a new section, along with *text* for bold and _text_ for italics. It's easy, it's fast, and it's failproof, unlike Word/rtf imports. And it means you can write in virtually any text app on any bit of hardware. And coding IBA to understand Markdown would be so easy, a summer intern could do it.
In short, Apple doesn't just need to do rtf a bit better, although that would be helpful. It needs to pay attention to what its users are doing and learn from them. And in the case of text features, it needs to listen to writers and bloggers.
--Michael W. Perry, author of Untangling Tolkien
Posted 19 February 2012 - 12:56 AM
Posted 20 February 2012 - 12:29 PM
Posted 20 February 2012 - 09:34 PM
I include a considerable number of AppleStore staff in that number.
Posted 14 March 2012 - 10:42 AM
Of all the changes I'd make to iOS proper RTF support would head my list. Due to this failure: I resort to a host of other 3rd party apps, each of which maintains it's own directory structure, and wacky and overly complex interface.
Perhaps we ALL need to visit Apples Feedback page:
( http://www.apple.com/feedback/ ) (which annoyingly doesn't have an iOS category - so you need to choose a specific device).
Posted 25 April 2012 - 07:22 PM
I work at Mariner Software and we've been looking at solutions to this problem for quite some time. One of the big issues is that the RTF spec (by Microsoft) is pretty complex. Second, the layout engine and pagination are another issue. iOS only recently (with AirPrint) got some idea about what a page is. So, who could fix this issue besides Apple? Most any company with their own word processor engine. what companies does that include? Well, first and foremost, Microsoft, but I doubt they really want to do Office for iOS. A number of java based word processor engines would do the trick and I believe that is where Office2, docs to go, quickoffice, and a few others are coming from. Mariner has
a word processor engine (in Mariner Write) and a few other companies do as well. One thing that holds many companies back from releasing an RTF compliant word processor equipped with object embedded graphics, stylesheets, rulers, tabs, and support for different page sizes is the fact that the cost of development is quite high. Imagine spending over $100,000 on an RTF editor that you'll sell for 5 bucks or less. Then give 30% of revenue to Apple. You'll need to be around and selling and updating your app for each iOS release for quite awhile to break even. I don't think we're talking about Angry Birds money here. One last thought is that at any time, Apple could wipe you into obscurity by including something like TextEdit on iOS (and it's underlying API's).