Re: Sony misreading epub layout of poetry - how do I solve it?

Lee,

This is helpful beyond what I had expected. Thank you very much for your 
time and trouble.

It particularly clarifies the viable usage between html group coding and 
css; something I could not find useful focus on previously. And the 
variation in interpretive codes is always difficult to get clear; your 
words have helped there - a great deal.

Others, from this and other lists, have been discussing off-lists, 
trying to get the rust out of my brain.  I think many of them would find 
this helpful as well. May I send this round to them?

Joseph


On 17/05/2011 23:04, Lee Passey wrote:
> 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 (&nbsp;). 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
> "&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;" 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/