CSS Problem in Uploading Epubs to PUBIT and on Nook as Document

[tomthom1]

This is a problem that's been perplexing me for more than a year. I have
created nine ebooks for my account on Pubit. I also sell ebooks through 
Amazon Kindle and Apple iBooks. I have learned HTML coding and manage my
own author's website in native HTML through Dreamweaver. I learned the 
further steps required to make an epub from the jedisaber.com ebook 
tutorial website. I have successfully constructed these epubs so that 
they pass the Rainwater Soft LLC epub checker without errors or 
warnings. When I upload these epub files for the Kindle and iBooks, they
display correctly on the distributor's ereader--and I have learned from 
experience that the Apple iTunes upload process is very particular about
accepting epubs with any kind of errors or warnings.

However, when I upload the same epub file on pubit.com, the conversion 
seems to ignore the CSS file included in the epub and instead loads or 
reads from a default stylesheet. When the conversion process is finished
and offers me a sample for checking, the book appears with all text 
flush left, no special treatment of title page and chapter headings, all
text the same size, all paragraphs without indent and separated by extra
space. These are all treatments controlled by the CSS. On the other 
hand, text treatments controlled by inline coding, like italics and 
boldface, appear as designed.

When I buy a sample of my books from these epubs on the Nook, it also 
appears with the default or missing CSS, not the style formatting I 
created. When I load my own epub files into my Nook as documents, they 
appear exactly as do the Nook books downloaded from Barnes & Noble; so 
I'm pretty sure the issue is not in your upload conversion.

The same files load and display correctly on my Kindle and iBooks, 
showing all the intended CSS formatting. When I've asked friends who 
have Nooks what my books look like, they report the same virtually 
unformatted flush-left look.

I have tried to correct this in many ways. I have studied your epub 
formatting guidelines available on the Pubit site, but the level of 
detail does not approach this problem, and I'm confident I'm following 
your guidelines, such as they are. I have not uploaded test versions to 
the Pubit site, because I did not want to interrupt book sales with 
possibly damaged files, but I did run several experiments with various 
epubs and loaded them as documents on my Nook. In one, I changed the 
filename of the CSS from the unique name I use for epubs (because I have
various CSS's for different publishing tasks). In another, I changed the
CSS file to the generic "stylesheet.css" name. (Of course, I made sure 
that the name of the CSS in the OEBPS is the same as the name in each 
chapter's HTML coding call.) In a third experiment, I used inline coding
for all stylesheet elements in one of the chapter HTMLs, which should 
have overridden the CSS and any default with the appropriate stye. In 
all cases, I saw the same flush-left default style on my Nook. Lately, 
I've been coding the books as XHTMLs as a more advanced format. But the 
Nook versions still appear in default style.

I know that others have created handsome books for the Nook with 
appropriate title pages, chapter headings, paragraphs with no extra 
space and with first lines indented. In particular, George R. R. 
Martin's "Song of Ice and Fire" uses graphics on the chapter headings. 
So I know good, specific formatting is possible. If it were possible to 
crack open their epubs and examine the CSS, I would. However, zipped 
epubs are virtually impenetrable--for a reason.

Can you suggest what might be going on or what I might be doing wrong? 
I've checked your Pubit bulletin board and found nothing approaching my 
problem. I've done Goggle searches looking for Nook and CSS issues 
without success. The format of my books as they appear on the Nook is 
still useful and readable, and none of my readers has commented or 
complained. But I'm disappointed that my Nook books do not look as good 
as the versions on Kindle or iBooks.

[Strayer]

I use Word 2003 and save as .doc. I use some of the formatting information in the Smashwords guide. Indents should be .25 in format and no hard tabs. Pubit doesn't like complicated code in the document. It converts to epub and you don't have to have the document in epub to upload. I have pictures and text and it came out well on Nook and Kindle. Simple is usually better.

[cale]

Since you've also published at Amazon, then you must have mobi version of these files too, no? I make my mobi file sfirst hand coding everything from the HTML to the OPF and NCX files. I keep most of my styles internal and aoms are inline. In fact, I just use one long HTML page for making mobi files because there's no size limit like there is with epub. After I make the mobi via KindleGen (actually most people just use Previewer to do this because it works better and gives you warnings if something isn't formatted correctly), I then take that mobi file and simply cnvert it to epub with Calibre with all the settings set to the default. It creates a perfect mobi every time and even splits the HTML file up into shorter pages that will pass epub check. I've had no trouble at all uploading these to PubIt.

One caveat. If you have certain styles set to take advantage of Kindle Fire's KF8 ablities, you have to check that Calibre doesn't muck up these styles. Hopefully everything will revert to legacy epub devices with no problem, but there are some things to be aware of such as drop caps. Calibre doesn't know what to do with those and screws up the first couple lines of the paragraph's first chapter. So I create a separate HTML file aimed at epubs where the drop cap styles are removed and replaced by a raised bold letter stye:

<span style="font-size: xx-large;"><strong>First Letter Goes Here</strong></span>

Then I make a new mobi file from this to bring into Calibre.

[tomthom1]

Thank you for the information. I hadn't thought of starting in MOBI, as ePubs appeared to be the more universal format. I'm not sure about having all styles in line or even internal to the text file, or about having the whole book as one big file and mechanically cutting it apart later. (I respect Calibre but haven't had any luck with it as a translator.) I'll take your approach under advisement.

[cale]

Sorry I muffed up the English language so much in that message, but I think you got the drift of it.

"I keep most of my styles internal and aoms are inline."

"Aoms" should read "many."

"It creates a perfect mobi every time"

I meant epub of course.

If you’re experienced enough with HTML to split the files into chapters or whatever, then you’re probably better off to do so. I only bother with that when the books are extremely long, like over 500-pages, or if it’s something like a history book with a bunch of sub headings and the like.

At any rate, I’m no fan of Calibre, but it really will make a perfect epub from your mobi file if you just watch out for any CSS styles that you know epub can’t handle. If you have any of your files in anything other than UTF-8 charset, it will even convert them to UTF-8 for you automatically. I know it’s weird, but KF8 guidelines say it’s best to take your HTML page(s) and open them in Notepad, and then save them as ANSI. Why I don’t know. Epub requires UTF-8 files, so it’s good that Calibre will convert them without you even asking. Actually I think you can use UTF-8 for the mobi conversion in KindleGen too. I’m thinking that whoever wrote Amazon’s style guidelines was wasted at the time. It’s full of errors, and I’m inclined to think this ANSI business is yet another one.

[tomthom1]

Actually, I create my HTML files with DreamWeaver using appropriate XHTML headings. I write the book in Word and have a pretty good format for making a display PDF for various purposes.

To convert then to XHTML, I do the manual coding of anything in line with Word find-and-replace. These are elements like codes for smart quotes, non-ASCII symbols and punctuation, Italics and other specific character treatments. Then I copy the passages into the "code" section of the DreamWeaver panels. This eliminates any underlying Word formatting at a single step, because Code is not Design. I work up the CSS in DreamWeaver too, and process the content.opf and toc.ncx in TextEdit or other non-formating text editor.

As noted above, this all works perfectly for direct upload to Kindle and iBooks. But for some reason Nook, which is native in epub, seems to ignore the CSS. Interestingly, Nook also treats the text files differently depending on whether they are a document upload to the Nook reader itself or a document in the Nook app.

[cale]

“Actually, I create my HTML files with DreamWeaver using appropriate XHTML headings. I write the book in Word and have a pretty good format for making a display PDF for various purposes.”

Well everybody uses some kind of HTML editor, including those who say they “hand code.” It’s ten times faster to do it in something like DreamWeaver or Expression Web and just check the code as you go along to make sure it hasn’t messed something up. By the way, with Expression I can just paste text in from Word and the smart quotes will stay smart, which is nice. Also, I just switched to Open Office Writer from Word. It’s so much improved now that it’s even better than Word in some ways. It may be good for you too because it can save in PDF. (I don’t think Word can yet, but I may be wrong.)

One hint about the search & replace thing: I’m not sure about DreamWeaver, but if it’s anything like Expression or FrontPage, it can sometimes take a long time to perform. If you open the file in Notepad instead, search & replace there works extremely quick. That’s something I just discovered.

Are you uploading the HTML files etc. to PubIt to do the conversion? Maybe there’s just a temporary glitch in the system. Calibre is free. I would try using that to convert to epub first from your mobi file and see how that works. If you want to get a little more in depth with the epub coding, you might try Sigil out. Both programs are free and make decent epubs. Jutoh’s not bad either, but it’s $40.

[tomthom1]

I hand-assemble the epubs by writing the HTML file names and other details into the content.opf and toc.ncx files using a text editor. I never go to a MOBI file in the first place, because the Kindle upload interprets the epub so well. I've used Calibre a bit, but I'm not keen on mechanical assemblers. When they make a mistake, they make it big-time and in repetitive copies. (When I first tried to convert a Word file to epub with Calibre, it interpreted Word's embedded formatting into in-line style calls leading every paragraph, made a few mistakes in doing so, and generated about 600 single-spaced pages of errors on the epub checker. Bad dog!)

I've found that my basic issue here--Nook not interpreting the CSS files--seems to be covered by a parallel post in this forum right nearby from Liz Castro. At least it covers my issue as far as the centering of chapter headings and other text goes. It seems that Nook and other ADE readers can't understand the "text-align: center" call, but she has a workaround. That was the biggest thing that bothered me. So I have some experimentation to do.

[cale]

If I were in your shoes I would download the Amazon Previewer. It's on the same page as the KindleGen download. Previewer converts your file just like KindleGen, but it will also show you any errors in your files after converting to mobi, and it will show you what your mobi files looks like on standard Kindles, Fire, ipad, and iPhones. You just drag you OPF file onto the Previewer window and it starts converting. Then you'll have your own master mobi. Calibre works fine converting that to Epub.

Believe me, I'm no Calibre fan, but it does do well at converting a master mobi to epub.

PS, I use the text-align: center; style all the time with no trouble. That shouldn't be a problem. Centering things like chapter titles with standard centering tags is no big deal with mobi or epub. They may not be dead center, but it's close enough that no one would notice unless it's something like poetry which you're better off left aligning anyway and using non breaking spaces to place the text where you want it. Liz goes to the trouble to do hanging indents with all kinds of media queries and several CSS sheets for various readers. I think the better solution is to simply number the lines. When people see a line that isn't numbered they'll know it's continued from the previous line. Publishers have numbered lines of poetry for years and years anyway.

Good luck with it.