Poor editing?

[thibaulthalpern]

Originally Posted by cerement

This is why I'm looking for what would be suitable as a "master format". The XHTML component of ePub is not rigid enough. The DTBook component looks better (and easier to validate as XML). TEI is used more often in humanities, and DITA offers non-linear flexibility.

But a "master format" is going to have to be relatively rigid in its makeup because the purpose of a so-called "master format" would be to prevent or minimize these errors. Even something as simple as

<span class="dropcap">M</span>obileread

can cause problems by breaking searches for "mobileread" (even though it's not supposed to).

This is why I like PDF for electronic formats. Now, it doesn't mean it's the most friendly format for an eReader, but in terms of electronic format in general, I absolutely love PDFs. It allows me to store them in one hard drive, do searches, and even maintain notes along with the PDFs, and print them out when I need to for marking up etc.

Some machines handle PDFs quite well. I think, so far, my experience with the PRS-700 in reading PDFs has been fair to good for PDF.

I LIKE PDFs!

[thibaulthalpern]

Originally Posted by DaleDe

Well, perhaps although digital transfers are mostly glitch free and I doubt if they have any in their 200K eBooks. Typos should not creep in at all and formatting errors are possible as are characters not in their final character set but why would that say the use a very large version of the source file?

Dale

I think typos can creep in when, say for example, you're switching from one character set to another...maybe. So maybe in the conversion process, something goes awry and the character set goes from Unicode 8 (UTF-8) to ASCII. Problems can appear there, perhaps.

Talking about character sets, I wish the computing industry would abandon ASCII entirely and move entirely to UTF-8. ASCII is such an Anglo-centric character set leaving the languages of the rest of the world aside.

[cerement]

Originally Posted by thibaulthalpern

This is why I like PDF for electronic formats. Now, it doesn't mean it's the most friendly format for an eReader, but in terms of electronic format in general, I absolutely love PDFs. It allows me to store them in one hard drive, do searches, and even maintain notes along with the PDFs, and print them out when I need to for marking up etc.

But that comes back to the same point though, PDF is a layout format, not an eBook format, it makes a fantastic ending point, but a horrific starting point when doing conversions.

[Steven Lyle Jordan]

Originally Posted by DaleDe

Well, perhaps although digital transfers are mostly glitch free and I doubt if they have any in their 200K eBooks.

All I can tell you is, I uploaded books into the Kindle conversion process multiple times and watched it do something different to the file each time. I don't have any idea why that was, and I suspect it has as much to do with server activity during upload (who knows how many documents it might be converting at any one time?) as it does with any faults in their conversion SW. And of course, trying to get answers from the DTP staff as like pulling teeth.

Just saying, whoever uploads those files, someone needs to proof them, because the Kindle system simply is not foolproof. Anyone who just assumes their material will come out as it went in, is making a grievous error.

[JSWolf]

Originally Posted by Amalthia

I convert a lot of fan fiction into LRF and even with the word doc I have to convert that to HTML (using Word97 seems to give the best output) I still have to go in and check to make sure the Table of Contents links work, add page breaks after chapters make sure the chapters are centered...and even after all that once the file is created I have to go in and check to make sure the links really do work (sometimes they work in the browser but not in the LRF file) and yeah it's some amount of work and I just discovered in half my conversions sometimes the italics are not showing because the html had < i > < p > instead of < p > < i >

I tried using the newer word programs to convert to html (thinking the code would have correct tags) but it just doesn't work as well as the Microsoft Word 97. The good news is at least with Word 97 I can read the HTML and use replace all to fix things.

So basically, yeah I can see how "professional" novels would have not only typos but all sorts of formatting errors. I'm fixing shorter works but some of the fan fiction stories are novel length and at least I'm starting off with a clean electronic version.

What I've done with stuff like that is load it into Word 2003 and if it looks good on screen but has a problem as HTML, I save as RTF and load into Book Designer. Sometimes that works quite well. But not always.

[JSWolf]

Originally Posted by Steve Jordan

Amazon is simply saying that their conversion process (which can be from multiple formats, including Word, Mobi, etc, to their Mobi/AZW files--I suspect even Mobi files are re-converted through their system) can result in typos and formatting errors caused by glitches during upload--in other words, their data transfer isn't perfect. And finally, they leave it up to the author to check his material once it's up for proper formatting and display, page by page as required. This was my experience when I had books in the Kindle system.

Would it not be best to have the eBooks uploaded as DRM free Mobipocket and then all Amazon has to do is tack on the DRM and away we go? And that way, if there are any errors, they would be the publisher's fault and not Amazon's.

[JSWolf]

Originally Posted by thibaulthalpern

This is why I like PDF for electronic formats. Now, it doesn't mean it's the most friendly format for an eReader

eReader does not display PDF. It only displays eReader format.

[Amalthia]

Originally Posted by thibaulthalpern

Very helpful information there, Amalthia! So it does prove again that conversion from one electronic format to another is not as simple as executing one command.

Calibre is getting closer to achieving that goal I think...but yeah whoever can make that program will probably rake in the dollars.

But for the time being, sadly no it's not as simple as hitting a button to convert and keep all the settings. Though with good LIT files I've had the best results with converting to LRF. I stress the good part because I've had some crazy results with converting LIT.

[Amalthia]

Originally Posted by JSWolf

What I've done with stuff like that is load it into Word 2003 and if it looks good on screen but has a problem as HTML, I save as RTF and load into Book Designer. Sometimes that works quite well. But not always.

I've run into that as well, though to be fair I'm a complete novice with Book Designer. I've found a system that works for me. But if I didn't have Word 97...I probably would have been forced to learn how to use Book Designer. For the moment, except with a few glitches, I've got something that works 99% of the time and I do double check my LRF creations.

Once you have a clean html source it's rather doable to make it look pretty on the device. Well maybe not that pretty... I'm happy with the chapters being bolded and centered and a space afterwards before the start of a new paragraph. Anything more than that would take too long.

[jgray]

Originally Posted by thibaulthalpern

I think typos can creep in when, say for example, you're switching from one character set to another...maybe. So maybe in the conversion process, something goes awry and the character set goes from Unicode 8 (UTF-8) to ASCII. Problems can appear there, perhaps.

Talking about character sets, I wish the computing industry would abandon ASCII entirely and move entirely to UTF-8. ASCII is such an Anglo-centric character set leaving the languages of the rest of the world aside.

Yes, UTF-8 (or UTF-16 if necessary) is a much better choice. One thing to keep in mind, at least as far as epub: for most non-ASCII characters you have to use the numeric form, as very few of the extended characters are defined in XHTML. This is not a problem with epub, but with the XHTML spec.