Forum: Author Hangout

I had some issue early on with the Lulu epub system due to the validator Amazon insists they use,

It can't be Amazon. I submit an epub to Amazon (generated from Calibre) and it works fine.

It can't be Amazon. I submit an epub to Amazon (generated from Calibre) and it works fine.

All my e-pubs are created in Calibre, but a lot will depend on how you have the system set up, as well. Read my longer post to graybyrd about the past issues I had with the validator at Lulu. From them I know it's not insisted on and controlled by Apple or Lulu. I doubt Kobo or B&N have the influence to insist on it, so the likely culprit in this case is Amazon. The only way to sure of knowing if there are two different sets of parameters in use is to take a file rejected by the validator at Lulu and see if Amazon accepts it, or the reverse.

I did find the idea for tweaking Calibre input & output prefs to be useful.

Finding the ability to tweak the file in Calibre is what got me to finally start providing e-pubs. One thing I did find, when I first started, was I could create e-pubs that validates at the IDPF Validator ( http://validator.idpf.org/ ) but got rejected by the checker / validation program at Lulu (more on that later).

However, at that time I wasn't using Heading 1 and Heading 2 for the chapter and sub-chapter headings in the document file. I went through a document and redid all the headings using the Heading 1 and Heading 2 codes and created a new PDF, and it went through OK. The only other trouble I had was when I created an e-pub and tried to load it up straight away, the validator didn't like a publication date in its future. That's now fixed. Sometimes I have to load the e-pub file a couple of times before it's accepted, I suspect the problem there is related to a data corruption during the upload - maybe the electrons got too soggy crossing the bottom of the Pacific Ocean (you may laugh now).

Now, back to the Lulu validator. When I first started loading e-pubs at Lulu the process was very much like when you loaded a PDF file for the print books. On one of the early screens you had three choices - sell via the market group, sell via Lulu only, restrict to only yourself. At that time when I loaded an e-pub as sell via Lulu only it didn't run a validator program over the file, but if I selected to sell through the market group it did run the validator over the file and was sent to all the members of the group. That showed the validator program was being insisted on by the other members of the market group (Amazon, Apple, Kobo, B&N) and not Lulu. A few months later the upload system for the e-pubs changed and the choice screen was removed, but all e-pubs being loaded were then put through the the validator, and at the end you got a screen to choose which of the market group you wished to sell through - you could pick and choose. If you pick Amazon you get another page listing a large number of other requirements the file must adhere to before Amazon would accept it - one is the story can't be on Amazon already.

Another issue I've had with e-pubs was at one point the metadata was listing me as Mr Ernest Bywater, and Apple were getting their nickers in a twist about that, and I had to have the Mr removed from the name before they'd accept the file. This was after it was passed through the validator. Investigation found my account at Lulu had the Mr in its name, changed the account name and all was well. If Apple had been the main force behind the validator they'd have had that as part of the check routine, instead of running it through another check at their end. And since the early use of the validator only came when using the market group, it wasn't being pushed by Lulu. I later confirmed this when i started having the trouble with posting e-pubs with a date in their future, a complaint to the Lulu Support people got a response of them saying they'll pass it on to the market group member who manages the validator software.

Their error report reported it could not "find" the publication date.

In Calibre, after you load the file into, the second icon from the left is a big blue circle with an i in it, titles edit metadata. When you click on that it opens a window where you can enter the isbn number, the publisher, the language, tags, and the published date - which opens a little calendar when clicked on. It's very easy to enter a published date via that link.

There's a number of less-than-happy campers concerning the Lulu epub validation errors.

Graybyrd, within the metadata section I mentioned before are two date points, one is automatically filed in with the current date, and the second I need to select a date for. Don't know why that is, but it is so.

With regards the Lulu validator, I know it's imposed on them by one of their market group partners, either Amazon, Kobo, or B&N - Apple run another validator of their own when it reaches them and something can pass the first and get rejected by Apple. When i had an issue with the validator re dates ahead of their local time, Lulu had to pass the reports on to the partner who managed the validator - but wouldn't say who. I also know, from when I first started posting e-pubs, the validator was only used (then) when I selected to sell through the market group, sales through Lulu only didn't need to be validated - but the lodgement system changed and now all pass through it to make the system a simpler one.

Now, I have a few e-pubs from other authors and just checked a couple of them, some have two dates, while some have only the one date, yet they all are validated by the idpf.org validator. Why this is so with them is beyond my knowledge.

With regards the Lulu validator, I know it's imposed on them by one of their market group partners, either Amazon, Kobo, or B&N - Apple run another validator of their own when it reaches them and something can pass the first and get rejected by Apple.

Ernest, that's what they claim, but it's clearly untrue. I've posted to each of those sources before, and I've never encountered the requirements that lulu insists on (especially their punctuation and date rules). Someone at lulu got 'creative', and we all have to pay the price for it!

I can't submit over half my books to Apple, B&N and Kobo because their rules aren't applied consistently (most notably, sometime I can use a standard cover, and other times it insists on a squarish cover). If I have a single book which lulu won't approve, I yank the entire series so I won't disappoint potential readers. Note: The weird cover limitation isn't used by anyone but lulu!

Graybyrd, another issue I found is that lulu forces Amazon's 'single space indent' rule, even if you don't post to Amazon (in my case, I post to Amazon directly). To get around that (for all the non-Amazon sales, I convert the < blockquote > command to remove the qualifier and it works fine. A single global search works fine.

I found is that lulu forces Amazon's 'single space indent' rule, even if you don't post to Amazon (in my case, I post to Amazon directly).

Which is a good reason why i suspect it's being forced by Amazon. We already have plenty of cases where what they insist comes from another publisher is different to what they allow through their own direct inlets.

Ever since I started posting e-pubs at Lulu the validator was used for any being posted to the marketing group, but not for sale through Lulu only when I first started posting e-pubs. I actually had half a dozen e-pubs up at Lulu before I saw the validator for one I was putting on the market group. Then I had another for Lulu only and no validator needed. That made it clear it was not a requirement from Lulu, but from the market group. Since then I've had some pass by the validator and get rejected by Apple, showing they aren't behind the validator at Lulu. So that rules Lulu and Apple as those forcing it's usage.

So that rules Lulu and Apple as those forcing it's usage.

I also posted (until recently) to the same sources on SW and never had those posting restrictions. I suspect Lulu (especially for the cover limitations, as Apple prefers 6"x9" covers, as does Amazon (though in an off-the wall dimensions)). It is likely the capitalization requirements are imposed by Apple, since I haven't posted there for a while. The strange date processing issue is purely lulu, though. The single space indents are entirely Amazon, as that's an internal requirement for their readers.

The strange date processing issue is purely lulu, though. The single space indents are entirely Amazon, as that's an internal requirement for their readers.

The strange date validation is a requirement of the validator, true, but Lulu don't manage or control that validator while they are required to use it. Amazon must have some input on the validator software to have it enforcing their single space indent requirement, since no one else has it.

I had thought the validator may have been by a separate entity, until I had the trouble with the Mr Ernest Bywater in the author field. It was accepted by Lulu, Kobo, Amazon, B&N, and rejected by Apple after the others accepted it. When I changed it to not have the Mr in it Apple accepted it. If Apple had control of the validator that check would be in there, also, if Lulu had control and was incorporating their partner needs that check would've been in it. But it's not, showing it's outside of the control of Lulu and Apple.

The strange date validation is a requirement of the validator, true, but Lulu don't manage or control that validator while they are required to use it. Amazon must have some input on the validator software to have it enforcing their single space indent requirement, since no one else has it.

Graybyrd essentially documented that Apple's validator isn't the issue with lulu, instead it's the way lulu constructs their book creation dates. When he replaces their date with his own, the issue evaporates: ergo, it's their date creation process rather than the validator.

Discussing the validator; Apple did not write the validator, which was developed by a (supposedly) independent third-party, but that doesn't mean that Apple, and others, won't continually impose their own standards to access their marketplace.

Graybyrd essentially documented that Apple's validator isn't the issue with lulu,

Which is what I also said, due to apple kicking up an issue AFTER the validator imposed on Lulu by the market group partnership. A validator that used to be only relevant if you select to go with the market group, but now checks everything due to that selection being done at a alter point due to people authors later changing the choices.

A validator that used to be only relevant if you select to go with the market group, but now checks everything due to that selection being done at a alter point due to people authors later changing the choices.

The validator, being an independent product, is largely used for most epub submissions as a 'first-pass' acceptance before the more device specific restrictions are applied.

On a separate note, another major gotcha for epubs is Apple's insistence on a separate "span" command in order to center text on a line. The standard: < p align="center" > won't work on Apple devices. Instead you've got to include the additional qualifier: < span class="Center" >. It's a pain-in-the-ass additional step, but the various validator processors won't alert you that your centered text isn't centered on specific devices. Instead, you only learn that by examining each device individually, and then checking the Apple design guidelines.

As for lulu requiring a "publication date", Calibre offers a 'book information lookup' feature, which will supply the necessary information based on public sources (in case you can't remember when you published a story). Simply click the lookup, it pops up a separate window, you select whatever information you want, enter it and you're set. Otherwise, lulu searched the same information, and when it finds a conflict between the two dates, will reject the entire submission.

Apple's insistence on a separate "span" command in order to center text on a line.

That was pointed out in Guido's article on converting .doc to ebook. He didn't mention it was Apple so I assumed it was a general ebook requirement.

That was pointed out in Guido's article on converting .doc to ebook. He didn't mention it was Apple so I assumed it was a general ebook requirement.

Nope, it's purely Apple, though they've never explained their justification for why they feel it's necessary. However, since it effects ebooks in general, it's a safe guideline to include it in all ebooks.

I just wasn't sure many people were aware of that particular issue.

I cannot find that feature in my copy of Calibre (latest version). Can you be a bit more specific? Perhaps it's one of the optional plug-ins?

It's under the "Edit Metadata" window. Down at the very bottom, there's an option to "Download metadata", which details your original publication date (though you often have to go to the optional second page). On the main details page, you select "View Log", which lists the specific details (like the publication date, which isn't displayed on the bigger displays).

Even if < span > validates, it shouldn't work because the span tag is an inline tag and centering is done at the block level like < p >. < p Class="center" > would only center text if your style sheet has a class called .center and it contains {text-align:center}.

That's what I do. In my CSS I have:

p.centered

{

text-indent: 0em;

text-align: center;

}

And then in the body I have stuff like:

|p class="title">|span class="centered">SEXUAL|/span>}/p>

where the | is a less than sign

XHTML & CSS allow very flexible ePub construction

The sad part is if the standard was written to be use exact xthml code, and the devices made the same way we'd have a uniform presentation on all the devices and web pages of the same code - but we don't.

NO, we don't. And we have damned little say in the matter.

GB, I know we don't tight now, but if the standard for the code was exactly the same (and there is no reason why it can't be) then anyone like Amazon who refused to work to the standard would be pushed to the side. The current problem is mobs like Amazon, Apple, B&N had a lot of say when the e-pub standard was set, and have it so messed up that their crap variance in hardware are within the standards for e-pub (or were when I checked a couple of years back).

I agreed with you the first time,

Sorry, I misread it as you disagreeing.

As to being a published writer, don't expect too many kudos or cash soon. In the last decade I've now published 97 stories and 4 paper (guides etc) - I'm still waiting for the media interview calls.

Standards have a reason. So do uniform railroad track gauges, and highway signs, and stoplight colors.

And punctuation.

If that's meant as some sort of grammar nazi remark, you can put it where the sun don't shine.

"Standards have a reason." They're your words.

computer languages have strict requirements; a loosely-defined subjective area such as language is rather different: language is constantly evolving, usage varies to achieve differing needs

Technology is evolving light years faster than the English language. And the technology standards you refer to are brand new (unlike language standards). So if you believe an author doesn't have to follow punctuation standards, don't badmouth Amazon, Microsoft, or any other technology company that goes contrary to a standard they probably didn't even agree to. And a standard that's constantly changing (like things in HTML 4 that all of a sudden aren't valid in HTML 5).

That was my only point.

Even if < span > validates, it shouldn't work because the span tag is an inline tag and centering is done at the block level like < p >. < p Class="center" > would only center text if your style sheet has a class called .center and it contains {text-align:center}.

Lazeez, I've tried both with Apple, and neither works unless you define a "center" style and include a < span class="center style" > qualifier, however, the < span > option works whether you use 'align="center"' or < p class="center" > command.

Apparently, Apple ignores ANY align commands unless it's wrapped in a separate < span > package. :(

And no, there is no separate Apple validator, instead Apple will simply not center any text/graphic unless you format it as they specify (i.e. you receive no warnings it didn't function).

Ernest, using CSS isn't a big hassle. If you've ever used Style Definitions in either WORD or OO, then you're already using CSS without knowing it. You just take the internal CSS definitions, clean out all the crap, and include it in a CSS section (not even a separate document, though it gets shifted to a separate section in the epub (compressed rar) file.

P.S. Switch, I like your "|" alternate for the "less-than" command initiator. I think I'll start using that as well (though I have no "|" key on my damn keyboard!!!)

P.S. Switch, I like your "|" alternate for the "less-than" command initiator.

On wattpad, I use &lt(with the semicolon) instead of the < and it displays correctly. That didn't work here.

It is located on the same key as the (it looks like a colon, but made with vertical lines instead of dots)

On most keyboards the key with the slash from the top left to the bottom right has the pipe key as it's shift key option and it looks like this | in some fonts it will show as 2 short down strokes one above the other. It's often used in programming commands.

backslash (goes upper-left to bottom right. The opposite of this '/')

one oddity of life is when I was growing up, and also when i first started using a typewriter and a computer a / was called an up slash and was called a down slash because you started from the left - for some reason a bunch of US techos started calling the other a backslash - which I could never work out why.

It often doesn't show in computer messages because it's a very common programming sign, just like the pipe is.

I believe the | is called a 'pipe'. It is located on the same key as the (it looks like a colon, but made with vertical lines instead of dots) and is usually located somewhere near [Enter].

Duh! It's been so long since I've done any actual programming (aside from writing html code), I've completely forgotten that key. Thanks for reminding me. Hopefully I'll remember it for more than a few hours. :-)

I don't know if Apple uses different validation for the iBooks store vs the iBooks App, but the code generated by SOL centres correctly on the iBooks app without complaints nor silly html code shenanigans.

I was publishing my second book via Apple, when I saw several messages on the topic on an Apple forum, and began studying my books. They appeared correctly on most devices, including my MacBook, but not on my iPad and iPhone. It may not be consistent, but since then I've included the obnoxious demand, but like you, I concentrate on CSS Style definitions rather than relying on in-line coding--which works in most cases.

If it works, that's fine and I won't belabor the point. But having been burned, I remain forever cautious! :(

P.S. Now that I know how your code converter operates, I'll change how I prepare files. Previously, I'd change my own |p class=Centered> (no quotes, which seems to work across all devices) to |p align="center">. Now, I'll switch my codes for "{c}", or simply replace my own "Centered" for "c" (with quotes).

the '{c}' will work, the "c" won't. < p class="centered"> may work, but not guaranteed.

Oops! You tell me just after I submitted a new 10-chapter post, coded incorrectly. Sorry! I'll adjust this weeks posts to use the preferred format.

In other words, the processor ignores all |p class=> commands, even if it translates code into that very format? That's easy enough to understand, and it's what I'm already doing by stripping out the |p> options.

That's purely a function of CSS style definitions

This part of the thread makes me glad I do not get involved in the html or xhtml code required for the e-pub. I write in Libre Office, convert to e-pub in Calibre, and that's the e-pub done. I do create a plain html version to upload to SoL now, and for my own website, later.

couldn't find the publication date

G'day graybyrd,

I've checked a number of e-pubs I have from several sources, and they all have two dates in them: the file addition date and the book publication date. In some of the files the publication date is a lot earlier than the addition date, and a bit of research shows the publication date is the same as on the first print book issue date.

When I add a new file to the Calibre library it automatically adds in today's date as the addition date, and I have to manually enter the Publication date, unless the file already has one in it. I just confirmed this by adding two e-pub files from other authors. In both cases the addition date shows as today's date, while one file has a publication date of May (the date the author published it and released it), while the other has no date at all. I just confirmed the actions with two other e-pubs, one of which has a publication date of Nov 2015 and an addition date of today. Why it doesn't populate the publication date as today's I don't know. I adjust it in the Edit Metadata section as stated earlier.

I was hoping there was a 'quick and dirty' solution Lazeez could manage, but it won't work.

Frankly, Switch, Earnest and I (with the help of anyone else out there who's publishing) should put together an "SOL guide to publishing" (like Ernest did) and publish that. Maybe if we did we could get Lazeez to list it as a reference for new publishers.

I've long thought that Lazeez should offer a "published authors" list on SOL, where SOL collects a portion of each sale, as many sites do, but he seems reluctant to get involved in outside commercial entities. But several story sites collect commissions by listing member publications, but this might be an exception to Lazeez's 'no commerical links' rule (especially if we offer it as a free resource to authors).

search function for this forum

I don't think there is a specific one, but I've never seen a forum with a search function just for it. Mind you, a Google search will find matching results in the forum.

(As an aside, I can't find any sort of search function for this forum; these bits of knowledge about publish sites and epubs and submission details, etc. are useful to all authors--but no so much if we can't find them later.)

There are so few of us who publish on this forum, it's better talking privately to the few who do, and asking for all the various 'gotchas' up front. There's a LOT of them, and you can save yourself a ton of work by asking a few questions. Unfortunately, each of us have our own processes, so you've got to differentiate technique from publishing issues. But that's the best way to get started in publishing, and once you've published, you can simply revert to the active (new) discussion for any issues encountered by others.

Any time you try something new, it's best to seek advise from people with more experience in the field.