Re: Sony misreading epub layout of poetry - how do I solve it?
"Lee Passey" <[email protected]>
| Newsgroups | gmane.culture.literature.ebook-community |
|---|---|
| Message-ID | <[email protected]> |
Some musings about CSS in epub, in which you may find a nugget that is helpful.
On Mon, May 16, 2011 5:47 pm, joseph harris wrote:
> I do not possess any reading devices, so checking is a bit complex. I
> have a test epub file which is reported as showing up correctly in most
> devices.
If you think using CSS is hard, you ought to try implementing it! Implementing
CSS is /hard/, and it's no wonder that not everyone gets it right. As of right
now I think that when it comes to conformance with the ePub specification,
Adobe Digital Editions is the gold standard (although I don't find the user
experience particulary good), but even Adobe's support for CSS is incomplete
(e.g. support for the "page-break-before" style).
> Sony [which uses Digital Editions from Adobe] is failing to get the
> detail right.
I think that Sony has adopted the Adobe Adept TPM mechanism, which is little
more than a method for decrypting encrypted files, but beyone that it has no
connection to ADE, especially in the rendering engine (I believe ADE uses
WebKit internally, but that's just an educated guess).
> This involves css instructions for line positions. Almost
> every other line needs to be indented, but they are showing up as all at
> the left margin. Does anyone know what the difference is in
> interpretation that is causing this? Does Sony use different details in
> css; or is it more limited in what it can recognise? There seems to be
> a similar problem with Kobo.
It's safe to say that for the time being nobody has got support for CSS
completely right, so for an author or book designer the challenge is to
balance the best layout on the greatest number of platforms.
My approach to this challenge is rely most heavily on standard HTML elements,
augmented with CSS only when necessary, and avoiding the commonly unsupported
portions of CSS whenever possible.
"padding" is one of those CSS elements which tend to be poorly supported.
> I cannot find any help on the net, either because it isn't there or
> because I haven't found the right search words.
Traditionally, poetry has been structured in HTML using the <PRE> element[1].
Text inside a <PRE> element typically 1. does not collapse whitespace (two
adjacent spaces will remain as two adjacent spaces); 2. does not automatically
wrap lines (long lines will cause horizontal scrolling); and 3. is rendered in
a fixed width font (characters appear in "columns"). Typically, all three of
these attributes are desirable in poetry.
Support for the <pre> element is required for ePub 2.1 reading systems.
If indentation is your only concern, simple, variable indentation can be
created using "non-breaking" spaces ( ). In HTML (and most XML
vocabularies) non-breaking spaces cannot be collapsed, and cannot be used as a
wrap point. While inelegant, a 5 space identation can be created by using
" " at the beginning of a line.
These effects can also be created using CSS, but as usual you are subject to
varying degrees of compliance by user agents.
Setting a style of "white-space: pre"[2] on any text element should prevent
collapsing of white space and line wrapping on whitespace other than the
newline character (ASCII 10). Of course, "font-family:monospace" should cause
the User Agent to use a fixed-width font.
Blocks of text are typically indented using the "text-indent" or "margin-left"
styles. The difference between the two is that "text-indent" only causes the
first line of the block to be indented, whereas "margin-left" causes the
entire text block to be indented, with wrapped text having the same left
margin throughout the block. It is possible to use a negative number as the
value of the "text-indent" style which makes it possible, in combination with
the "margin-left" style to create "hanging" indents.
> The css is fairly simple, and this is what is working practically
> everywhere else:
>
> .line1-left
> {
> margin: noinherit;
> padding-bottom: 1%;
> font-family: serif;
> font-weight: 600;
> }
>
> .line2-indent3
> {
> padding-left: 2.2em;
> padding-bottom: 1%;
> font-family: serif;
> font-weight: 600;
> }
>
> Each line is in a <div> container.
I would be very cautious about defining styles that are not attached to a
specific element. Assuming that the above definitions worked, you might expect
<div class="line2-indent3"> to look the same as <p class="line2-indent3"> but
this might not be true in all cases. Cascading Style Sheets cascade, which
means that styles are additive, and later style definitions override earlier
styles. The <p> element was designed to demarcate paragraphs only, not
anonymous blocks, and so has certain semantic baggage. If a user has set her
User Agent to indent paragraphs 5 em, and you used <p class="line2-indent3">
for a line of poetry, that line may look extremely odd to that user.
The most common expression of this I have seen is when someone attempts to
create a short, centered text fragment, say for a headline, using <p
style="text-align:center">. When paragraph indentation is added to this
fragment it leads to text which is not quite centered, but shifted right by
the amount of the indentation.
Thus, rather than defining your style as:
.line1-left { ... }
I would define it as:
div.line1-left {...}
in which case it can only be applied when the text appears in a <div> element
(as you have).
Of course, on computer screens seriffed fonts suck, so you should remove from
your style declarations the requirement that a seriffed font be used. That
way, even if you disagree with me, the end user gets to decide what's best for
him. Nor do I see why you would want to set the font weight. Bolding in HTML
is rarely useful as it is so easily overlooked, and 600 is an odd weight (400
is normal, 700 is bold, and 900 is bolder. How would a user agent map 600? I
certainly don't know.)
Even in the CSS specification padding seems confusing to me, and is obviously
not well supported. If you find you need (or want) to use CSS styles (as
opposed to native HTML elements) I would suggest using "text-indent" instead.
My refactoring of your style would be:
div.line2-indent3
{
white-space:pre; /* insure that spaces are not collapsed,
and lines are not wrapped */
font-family: monospace; /* every character is the same width */
text-indent: 3em; /* indent the first (and only) line by this much */
}
Of course, if layout and font selection is really /that/ important, you
probably just ought to opt for PDF -- mimicing paper is what it's best at.
HTH
Cheers,
Lee
[1] http://www.w3.org/TR/1999/REC-html401-19991224/struct/text.html#edef-PRE
[2] http://www.w3.org/TR/2008/REC-CSS2-20080411/text.html
------------------------------------
------------------------------------------------------
Post a message: ebook-community [[at]] *
Unsubscribe: ebook-community-unsubscribe [[at]] *
Switch to digest: ebook-community-digest [[at]] *
Switch to normal: ebook-community-normal [[at]] *
Put mail on hold: ebook-community-nomail [[at]] *
Administrator: ebook-community-owner [[at]] *
(* == yahoogroups.com)
-------------------------------------------------------Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ebook-community/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ebook-community/join
(Yahoo! ID required)
<*> To change settings via email:
[email protected]
ebook-community-fullfeatured-hHKSG33TihhbjbujkaE4pw@public.gmane.org
<*> To unsubscribe from this group, send an email to:
ebook-community-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/