In most cases I would say that’s a compromised proposition, given how very different these formats are. Even if the underlying technology were not so radically different (top-left origin print-based measurements vs floating box model), just to speak purely on aesthetics, what looks good in PDF might not work well in an ebook and vice versa, and any tweaking you do is going to require more work proofing multiple copies to make sure the change doesn’t blow up everything else.
I’m talking even things like measurements between elements, like how wide your label gutter here is, which will consume most of an iPhone screen. For an ebook it might even make sense to ditch the hanging indent label and use a vertical stack approach where maybe the content is indented, but only a little. Or maybe it means ditching the fixed label column gutter and letting the label flow into the first line however wide it needs to (like how the user manual handles menu and interface label descriptions, if that isn’t clear). That’s what I’m talking about—I don’t see how design decisions for a fixed media system can always be expected to work well in a reflowable media that needs to scale from budget phones to 27" screens, and if you change your design to live with that, then you’re compromising what you wanted for print media.
There is a reason for why switching to ePub in Scrivener offers none of the print/word processing Formats, and “Ebook” isn’t an option in them. We never intended for these to be easily cross-wired, and little of what any of those stock Formats do would be applicable across the divide.
I know some do try for this One Format to Rule Them All approach, but I wouldn’t be interested in the amount of bidirectional lowest common denominator compromises I’d have to make to get it working. I feel like the result would tend to converge toward a much more bland result, than if each file type can be refined and made to look good for what that media uniquely offers. End of page footnotes in PDF, pop-up interactive in ebooks, etc.
I understand this is proofing, so some of what I’m saying is less relevant, but I mean to at least put some fundamental background to the concept of why cross-wiring isn’t easier—and why formatting decisions like the very thing you are asking about are reasons why even fairly basic output intended for a beta reader audience can still benefit from a media-specific touch.
Theory aside, I’d go with your first option. Bear in mind that table support in ebook readers very much isn’t a layout tool. Most readers will be presuming tabular data, not hanging indent formatting meant to go on for page after page. It certainly is not “best practices” at any rate.
With this setup, I would use a Format Replacement to convert the “syntax” you’ve established to spans, and the style you’re using to wrap everything neatly. So a sequence of such paragraphs using this style might come out as:
<div class="glossary">
<p class="entry"><span class="label">Authority</span> Mr Dr Strange</p>
...
</div>
(Or if you did want the dash still, that could be left in there somewhere or in a second span.)
As for presentation with CSS, you’re right you would usually want to establish a widest common margin based on the widest label, same as you did for PDF. I don’t really see the problem with that. So long as you use em units so that it can scale with the ebook font that should be pretty resilient.
Maybe I’m misunderstanding it, but I don’t see how a table would even solve this problem, fundamentally, anyway. Whatever width you set for the first column is still going to need to be based upon some maximum that everything else sits within.
Or maybe the missing ingredient is that I’m not sure what you’re trying with the CSS, but your description of using an inline-block for the span is how I’d go about it anyway. I did write up a solution a while back for cleaning up Scrivener’s stock endnote numbering. So obviously the application is completely different, but the execution is very similar: a fixed label width column alongside a flush left content column. The CSS was tested against all popular ebook reader engines.
, a question about ePub for readers who want that instead of PDF (planning ahead)
