[Faterson]

Originally Posted by cedhax

I won't call it a flaw.

It's definitely a major flaw. Sorry, but it's really unacceptable – to expect the user to manually check and fix all the errors and distortions in highlights/annotations upon their export.

Originally Posted by cedhax

Anyway, I have yet to see any EPUB reader that fully supports this

Just because everyone fails, is no excuse for MapleRead to fail as well.

Originally Posted by cedhax

As EPUB is based on HTML, I have yet to see any web browser (desktop or mobile) that supports this

Eh?! What has that got to do with "web browsers"? It's not about web browsers – it's about exporting annotations from EPUB files. Precisely because EPUB files are HTML-based, there should clearly be a way to determine whether a word appears in the book in italics or bold (etc.), whether what is highlighted are 2 or 3 separate paragraphs, or a single paragraph, and so on. Of course there is a way to determine that – otherwise, MapleRead and all the others would also be incapable of displaying those fundamental formatting features properly.

So, what is needed – and sorry, it's a non-negotiable – is for the e-reader app to faithfully also export what it faithfully displays. As I mentioned, I realize that this is no easy thing to achieve, because a text property like "italics" can be marked up in an EPUB file in many ways (think of all the CSS variations...), but that doesn't mean developers should just give up and be content with the corruption of highlights/annotations upon export. That's unacceptable for professional-grade software, and will never be acceptable. I'm not being harsh, cedhax – just describing some basic requirements in straightforward language.

On the positive side: MapleRead does at least preserve new-lines in user-written annotations. (I believe here is where Marvin and others fail – merging the entire annotation into a single line upon export.) For user-written annotations, cedhax, it's OK to talk about "new-lines", because annotations are composed in plain-text. And in plain-text, a standard paragraph break is "hitting the Enter key twice" – that is, two successive new-lines. But none of this applies to book texts which are, typically for 2017, no longer plain-text (as in Project Gutenberg in the 1990s), but rich-text. Therefore, paragraph breaks from the book text should be exported as paragraph breaks (not "new-lines") in exported highlights.

That means: the exported highlights/annotations file must be rich-text, not plain-text. This is the great irony: Marvin allows you to export annotations via (among other options) a HTML file (which is a fabulous Marvin "killer feature" that MapleRead would do well to emulate), but the highlights inserted into that HTML file are... plain-text , which just makes no sense whatsoever...

Originally Posted by cedhax

However, not everything you stated in #4 above is correct. MapleRead highlights do preserve the "newline" characters between adjacent paragraphs.

Not true, cedhax. And, please, don't confuse paragraph breaks with new-lines. That is definitely not the same thing. If there are clear, multiple paragraphs in the book as displayed by MapleRead – then in the exported highlights, there must likewise be multiple paragraphs, not multiple "new-lines".

And, although the "new-lines" might appear upon export from the Alice sample book provided by MapleRead, that definitely doesn't work in all e-books I tested in MapleRead. For an example, please see the first screenshot attached to this post. That's an official EPUB release I purchased via Lulu – and all multiple-paragraph highlights get merged into a single paragraph (no new-lines anywhere) by MapleRead upon export.

In the meantime, I have discovered one more major shortcoming of MapleRead (you may wish to be "politically correct" and call it a "missing feature" instead, but that doesn't make the issue any more palatable...): MapleRead, unlike Marvin (and, apparently, Hyphen), does not support the higher resolution on the 13-inch iPad. That's a major drawback, in my eyes, because the interface of apps only optimized for 10-inch screens looks really terrible on that gorgeous, expansive (also expensive...) 13-inch iPad screen. Therefore, MapleRead should cater to the 13-inch iPads as well. You can take a look at the second screenshot attached to this post – it shows the multi-tasking screen on the 13-inch iPad, with the same book opened in MapleRead, Hypen and Marvin. It would, I think, be difficult to deny that Marvin's display of the book is the most elegant of all three. And MapleRead's display is the least elegant of the three... (The lack of distinct separation between book text and headers/footers once again comes into play.) Among other things, when an app isn't optimized for the 13-inch screen, the fonts employed in such an app seem slightly grainy/blurry upon viewing. And that's hardly acceptable for MapleRead in the long run, right?

Originally Posted by cedhax

I see. You are a self-confessed MapleRead newbie, but a Marvin old-timer.

A Mobipocket Reader old-timer, to be precise. Then Stanza. Then Marvin. And I'm sticking with Marvin as my main e-reader app for now, because although it's marred with many flaws or shortcomings, other apps seem to have even more of those, although they may be superior over Marvin in certain aspects (such as MapleRead's annotations syncing, fabulous themes treatment, the "curl" option for page flips, etc.). That's the sad state of things in the world of e-books (not just on Apple's platform) as of 2017.

The good news is, MapleRead (and Hyphen, and Marvin itself) can all become better than the current Marvin. So, there is always some hope. Although it might be an unrealistic "hope against hope" because, as someone (an app developer) remarked in this forum subsection a few weeks ago, it's likely impossible to earn a livelihood by developing a top-quality e-reader app... The world at large is content with mediocrity – and when it comes to catering to the mediocre, the likes of Apple, Amazon, Google or Microsoft will always gladly deliver.