What's required to get small caps to an epub? (Frame 12)

Report · Jun 03, 2014

In Frame 12, I started with the standard template for the User Guide and have put all chapters in the one file. Then I successfully published to epub and HTML5.

Both files show the blue chapter number across the top of the chapter.
Both files show the different paragraph style for the first paragraph following each new chapter (now temporarily identified with Heading1)
Neither file shows the running headers or footers. Can I change this?
Only the HTML5 shows the small caps Character Tag with which the first words of each new chapter are tagged.

Advice for correcting the last two points?

Thanks in advance.

Report · Jun 05, 2014

@Jeff .. using RH to do the cleanup is one option, but I wouldn't consider it to be "easy". I prefer OxygenXML for this purpose for the following reasons ..

OxygenXML is a native XML editor so it provides many features for editing XML files (which make up "99%" of the EPUB[3] contents)
To edit an EPUB you just open it in Oxygen .. no muss no fuss .. open it, make your edits and save
The built-in debugger is amazing. Run the validator, get a list of errors, click each line and it opens the file and scrolls to the offending code.

RH is great for editing/developing "Help" systems .. setting up the project, generating TOC/Index/etc, authoring content, and generating various types of output .. but it's not a great "code editor". When you're fixing up an EPUB you're in the code, and you don't want some "magic" happening to change what you've done.

Report · Jun 05, 2014

I'm finding that there are some "phunnies" going on with FM12 when it comes to inserting the character tags that may be contributing to the additional hard-coded style entries appearing in the resulting html. Since the Publish process goes through MIF, that's where I've been looking to see what FM is actually inserting.

For a defined character style-tag, FM should just insert the tag name around the selected text, but this isn't always the case. Depending upon when and how the style tag was created, FM sometimes also inserts the formatting particulars along with the tag, for example:

Catalog definition:

<Font

> # end of Font

Used in text:

<ParaLine

<Font

<FCase FSmallCaps>

> # end of Font

<Font

> # end of Font

Note the secondary declaration of the FCase attribute for the small caps tag (the string should have been wrapped in just the FTag component with no additional formatting specifications). This then seems to cause the RH components to use the CSS (span class=) for the small caps and also to add an explicit font-variant attribute for the small caps. Why and under what circumstances FM is adding these spurious definitions isn't yet clear to me. Some tags are clean and other have all sorts of additional formats.This needs to be investigated further.

However, it's clear that FM is complicit in some of the odd goings on in the ePub (and probably all html based outputs) creation. A little clean-up utility that removes all spurious entries in an applied character tag seems to be warranted (assuming that everyone uses character tags systematically and properly).

Report · Jun 05, 2014

@Arnis .. interesting observation. That was my suspicion, but I hadn't taken it to the level that you have to investigate. Yes .. it may be that doing some serious scrubbing on the FM source could clean up the bulk of the issues. I think that tables will still be the outlier though .. but that's a whole 'nother issue. :-^

Report · Jun 05, 2014

@Scott – I wasn’t really thinking it was easier, just that it would cut down on the number of issues downstream in the resulting EPUB, so you wouldn’t need to get OxygenXML in the first place. ;>)

Report · Jun 05, 2014

@Jeff .. I like the thought, but so far, other than for the most basic files, I've never seen an EPUB come out of FM/RH (or any other HAT) that doesn't need to be fixed in some way. At a minimum, they all have something that doesn't pass validation.