Hi All...
The only way to get reasonably consistent EPUB output is to strip the styling down to the bare minimum. Each reader and platform will have subtle differences in the way they interpret formatting properties, so the less there is to interpret, the fewer differences you'll run into. In my opinion, for the Techcomm world, you should be focusing on the content, and not focusing on providing special formatting. This may be different for "retail" books which may have more of a focus on the art of how the "page" is formatted. Again .. that's just my opinion.
FrameMaker (via the RoboHelp engine) does some strange things to the underlying HTML (this is true for all HTML-based output from FM/RH). It tends to generate HTML that uses a mix of CSS classes and hard-coded style attributes. In the example that Arnis provided, you see a classic example ..
<span class="FM_SmallCaps" style="font-weight : bold; font-variant : small-caps; ">
WHY is the style attribute needed? This essentially overrides the font-weight and font-variant properties that may be defined by the CSS class of FM_SmallCaps .. negating the efficiency of using CSS. This is especially problematic for tables and lists, and makes them work very poorly on a small screen. It will often be trying to emulate properties assigned in the FM document (likely a page-based presentation of a fixed size), and using that for the online formatting of varying sizes. This is bad.
I haven't done enough testing to see how to overcome this problem using only FrameMaker (or RH). It may be that the style properties are passed on if you apply style overrides to the content in Frame. I think this is part of the problem, so if you avoid that practice (which is bad anyway), you may be a bit better off, but it does not eliminate the problem.
In order to understand this problem fully, you have to carefully review the HTML markup that is being generated by FM/RH. (Note that this forum is specific to Adobe products, so that's what we're talking about here .. but this problem exists for ALL techcomm tools that I've tested, so it's not a matter of choosing another tool.) In order to review the underlying HTML, you need to use a tool that lets you open up the generated EPUB and look at the files. Calibre and Sigil are two tools that can do this (both are free) .. I prefer to use Oxygen XML Editor, because it is a powerful XML editor that lets you make global changes to the files in the EPUB, much better than other tools. It also lets you run the epubcheck validator within the interface and lists all problems which are easily accessible to review and locate.
When I use FM/RH to generate an EPUB, I open up the resulting EPUB and strip out all style attributes .. everywhere. Then you can rely on the CSS classes to control the formatting. This will help with the reader inconsistencies, but even with that you'll see some. The solution is to eliminate the formatting that seems flaky or just live with the inconsistencies.
There is a website called EPUB Test (http://epubtest.org) that provides examples of reader inconsistencies. Good place to visit.
But the bottom line is that if you're using special formatting in your EPUB, you'll need to test on as many readers as possible. When I say "special" formatting, I mean pretty much anything. Unless the HTML in your EPUB looks like HTML from the early 90s (H1, H2, P, B, I, .. you get the idea), it's up for interpretation by various readers, and you should know how it looks to your customers. Document which readers have been tested and encourage your users to report back on any issues they run into.
NEVER just generate an EPUB and ship it to your users without testing in multiple readers.
If you're interested in seeing some of the slides from presentations I've given on this subject, as well as articles for STC Intercomm and TCWorld magazines, visit this page on my website ..
http://leximation.com/aboutscott.php#PRESENTATIONS
Cheers!
…scott
29
Replies
AdChoices