saving magazine as epub

[Kev28410820xkum]

I have made a magazine that's in its initial print run now, and I want to do an ePub version - because of the design, it can't reflow, so I chose fixed layout. It all worked perfectly, except one article that has a background pattern to the page, with lightly tinted coloured boxes overlaid with multiply in front of the background pattern, but behind the text. These boxes appear solid, and in front of the text when saved as ePub.

I'm using INDD 19.1 

Currently, the only way I can think of getting around this is to remove those boxes, but they're part of the design, so if there's another way I'd prefer to use it - I do get an error message saying that some images saved as JPG should be saved as PNG, but I don't see where to make that decision.

[James Gifford—NitroPress]

FXL is a difficult (and, honestly, obsolete) format best left to "picture page" books like children's books and graphic novels. It's very difficult to work with and almost entirely "what you export is what you get" — it's hard to tweak or modify afterwards.

But it sounds as if it's working for you, mostly, so...

Next point is that no two EPUB readers are the same, and what you see may not be what any other reader sees unless you're sharing the exact same reader. I'd recommend Calibre for proofing, as it's the closest to a standard reader that has no egregious bugs. (Thorium Reader is in theory the gold standard, following all EPUB standards without any extras, but it has a persistent font-size bug that renders it less than useful.) The only alternative to consider is Apple's reader IF you are releasing the magazine only on iTunes or equivalent; Apple is reliable but has some quirks that make it a poor choice for general-release proofing.

So, the image problem...

It is very difficult to control things like layering order in an EPUB export. But I'd suggest trying this: put those graphics in a layer of their own, and make sure the layer is behind all others. That should get them to the back of the stack, although I don't think InDesign exports the <z-index> values and EPUB readers don't always respect it. So another approach is to put those graphics in a frame with a named Object Style (such as BGgraphicsLayer, and then add this line to the CSS at export:

div.BGgraphicsLayer { z-index:-100; }

Put this line in a plain-ASCII text file named MyFixes.css or such, and add that file to the HTML/CSS list in the EPUB export menu.)

Try all of  this, and be sure you're using EPUB 3.xx, not 2. If the image are behind the content, good; if they're still solid, we'll tackle that next.

[James Gifford—NitroPress]

An addition (InDesign was acting up and wouldn't let me check): I see EPUB 3 is the only option for FXL, which is good. Still having the completly obsolete v2 on there until recently just compounded the problems.

What might solve both of the other problems is to specify JPEG for the image output, not "Automatic," I generally trust JPEG more than PNG, from accumulated experience — more because some apps and readers and so forth handle the format badly, even now than because there's anything inherently wrong with it.

[rayek.elfin]

If possible group the background pattern and foreground pattern, and use the Object Export Options to rasterize (convert to bitmap) that group. It will depend whether that is a feasible solution on the layer order. If these include any transparency rasterizing the content of the group to PNG is the correct format.

I disagree somewhat with @James Gifford—NitroPress in regard to his comment about PNG images and readers - the main issue (in my experience) is that InDesign users not familiar with the inner workings of how it deals with ppi, rastering images, and epub export will output far to high resolution PNG files that prove too heavy or trigger Apple's max rez error.

PNG may very well be a (much) better option depending on the type of graphic. Of course, if transparency is involved, PNG is the only option.

I do agree, however, that fixed layout epubs are less than ideal, in particular for print-target magazines. Why no just export to a screen resolution PDF instead? It's not as if anything is animated or interactive in your magazine, correct? And with a PDF your eMagazine is accessible to anyone on any OS, device, and computing platform. With FXL epubs that audience shrinks to a fraction of your potential audience. It is also a more secure format, and PDF readers generally offer a FAR more user-friendly navigation experience for navigating and browsing an eMagazine than any epub reader.

[James Gifford—NitroPress]

I freely admit my aversion to PNG is an acquired prejudice not necessarily based in solid technical matters.  I've just seen too many project/export faults because of it, and misuse for printing when it's not the right format for that, and like all the other web-developed formats, it tends to pop up in... inexpert, poorly chosen circumstances. But I'm sure it's a nice little format and its mother loves it. (🙂 Now, that nasty little WEBP format, though...)

I just suggested JPEG as perhaps a simpler option while the other details are worked out, so that PNG's minor quirks are sure not to be contributing to the problems. Getting things like layers, opacity etc. sorted out for EPUB is... probably going to take a few rounds, and your suggestions of using the export options is very much the next step. But a page background may not group well with, say, forward page content... so it's going to be one step at a time.

And spot-on about EPUB vs PDF... with the problem being that distribution and DRM of PDF are almost insurmountable. EPUB is the only format that allows third-party distribution with something like copy protection.