feelings on .epub ?

[HarryT]

Originally Posted by bowerbird

it really drives me batty that mobipocket's "pages" aren't consistent.
it's laughable to me that they thought they could get away with that.
and even more laughable that amazon paid $3.5 million for such crap.

-bowerbird

Do you frequently find yourself paging backward and forward through books? If you simply read a book from cover to cover (which I'd imagine is what most people do), the paging is perfectly consistent. Hardly "crap", IMHO, at least.

[DaleDe]

Originally Posted by HarryT

Yes, Mobi shows you the last page number at the right hand side of its progress bar. This is true on both the iLiad and Pocket PC versions of the Mobi reader.

Not true. At least on my freshly download Pocket PC version 5.3 of MobiPocket. I only the see page number I am currently on. This is display on the right hand of the progress bar. I do not have a clue as to how many pages there really are in the document. I do not know about the iLiad but I do know about the Pocket PC.

Dale

[bowerbird]

harry said:
> Do you frequently find yourself paging
> backward and forward through books?

all the time, harry, all the time... :+)

however, mobipocket's inconsistency bothers me for
_philosophical_ reasons more than _practical_ ones.

pages in paper-books have consistency. i like that...

besides, i don't want the book's text "reflowing" on me
unless _i_ reflow it. by the way, that's one reason why
i will never use adobe's digital-editions viewer-program;
i simply detest that _it_ decides how many columns i get
with a certain combination of the view-port and text-size,
and even switches them up sometimes when i do a resize.
that's a decision that _i_ want to make, thank you kindly...

-bowerbird

[HarryT]

Originally Posted by DaleDe

Not true. At least on my freshly download Pocket PC version 5.3 of MobiPocket. I only the see page number I am currently on. This is display on the right hand of the progress bar. I do not have a clue as to how many pages there really are in the document. I do not know about the iLiad but I do know about the Pocket PC.

Dale

I stand corrected - I was getting confused between the different versions. The iLiad version shows you the final page number at the right side of the progress bar. As you say, the Pocket PC version shows you the current page number there. Apologies for the mix-up.

[GregS]

I am looking at the .epub documents at the moment.

Can anyone with experience, save me a lot of searching by telling me if the following is possible:

To have rendered in the margin an element ID number for referencing paragraphs and in plays, lines?

ie.

1.122
Chapter 1 paragraph 122

Book 2 Section 3 Chapter 22 paragraph 45
2.3.22.45

CSS can do it but will reader software be able to?

Being in one of the shades of eink grey would help as well (rather than black).

It would be nice to have a standard reference system.

It is possible to give each edition a World Unique ID which when combined with relative reference would give an absolute and unambiguous reference.

Any comment would be welcome.

[jbenny]

Originally Posted by GregS

I am looking at the .epub documents at the moment.

Can anyone with experience, save me a lot of searching by telling me if the following is possible:

To have rendered in the margin an element ID number for referencing paragraphs and in plays, lines?

ie.

1.122
Chapter 1 paragraph 122

Book 2 Section 3 Chapter 22 paragraph 45
2.3.22.45

CSS can do it but will reader software be able to?

Being in one of the shades of eink grey would help as well (rather than black).

It would be nice to have a standard reference system.

It is possible to give each edition a World Unique ID which when combined with relative reference would give an absolute and unambiguous reference.

Any comment would be welcome.

As to the numbering of paragraphs and such, if you will give me an example of the CSS that you use to do this, I will test it. However, it may not be possible the way you are doing it now, if at all. The epub spec doesn't require that everything in CSS 2.0 be supported. Also, some supported XHTML and CSS statements are allowed to be rendered differently by the reader software/hardware. We have already discussed similar issues regarding footnotes in an epub.

I'm not sure what you are getting at with the rest of your question about a World Unique ID. Please elaborate.

[jbenny]

Just fooling around, I tried a few things to implement paragraph numbers. The CSS 2.0 spec talks about "Generated content" http://www.w3.org/TR/REC-CSS2/generate.html. I tried this, but the examples would not work in Firefox, so I didn't even try it in Digital Editions.

The next thing I tried was floating a span next to a paragraph, like so:

span.pnum { float:left; width:4em; }

This seemed to work. After adding the same amount of left margin to the paragraph to simulate a separate column, things looked good in Firefox.

p { margin-left: 4em; }

I then created an epub, using this method. The epub is attached. Rename if from .zip to .epub. If you want to see how this looks in your browser, just extract the HTML file from the archive.

Since FBReader still does not support CSS, of course things displayed badly. The Lector plugin, using Firefox for rendering, displayed exactly as native Firefox. The only real test at this point was Digital Editions. Sorry to say, DE got it almost right. The numbers and paragraphs are in their own columns, as they should be. However, the paragraphs all start one line below the corresponding number. This isn't what we wanted, but is still useable.

It is possible that my quickly thrown together example is not correct in some way and that this may be the reason that DE isn't doing what we want. I will have to look at this a little closer before laying the blame on DE.

EDIT: I was thinking that using span outside a block element was probably not correct XHTML, so I wrapped each span/paragraph pair in a div for correctness. This didn't make any difference in how things displayed in FF or DE.

Edit: Using a separate div for each column was my first thought (like the way you would do it on a web page). However, since these are separate block elements, how would you keep the numbers in sync with the paragraphs? Using an in-line span was a lot easier.

[kovidgoyal]

Use tables.

[jbenny]

Originally Posted by kovidgoyal

Use tables.

The use of tables as a method of layout, although common, is considered poor practice. It makes separation of content and layout more difficult and can be a real mess to maintain if you change the layout. I think this might be even more of an issue with an ebook, because of widely varying screen sizes.

Yes, if we just want to make it work, tables will do the job. If trying to use the recommended standards of today and looking ahead, it's best to do the layout with CSS. I'm trying to break old habits myself and do things the "correct" way.

[kovidgoyal]

Use tables with % specification of widths. That takes care of screen size independence. If you must use CSS use hanging indents to accomplish this. See the demo file in the html2lrf thread. Though the tables based solution is actually more robust against font size changes.

Having a multi-column layout is what tables are supposed to do.

EDIT: Using tables for layout is not considered poor practice when you're trying to create a multi column layout. Indeed they are the best way to create a multi column layout.

[jbenny]

I hadn't thought of using an outdent for this purpose, but it does seem to work in FF. I'll have to try it in DE. As the code fragments below illustrate, you need to compensate in the body style for the outdent in the paragraphs (at least on the left side). These values can be adjusted to suit, of course.

body { margin-left: 2.3em; margin-right: 2.3em; }
p { text-indent: -2.3em; }

<p>1.1&nbsp;&nbsp;&nbsp;&nbsp;Now is the time for all good men

As usual, there is more than one way to skin a cat. Thanks for the suggestion.

Edit: I won't argue the use of tables for layout, as like any programming practice, there are proponents for both sides of the issue.

[kovidgoyal]

The problem with that is you're stuck with using fixed space based indents in your actual paragraphs, which is really inelegant.

I really don't see how this can be solved elegantly with block level positioning, unless there's a way to force a float to have the same height as its parent.

[jbenny]

Although I don't particularly like doing it with an outdent, I just tried it in DE and it does work ok. Using ems does make this scale correctly with font size.

Did you look at the epub I posted? What I was trying to do there was this:

p { margin-left: 4em; }
span.pnum { float:left; width:4em; }

<div>
<span class="pnum">1.1</span>
<p>Now is the time for all good men...</p>
</div>

This works just fine in FF, but DE inserts a newline after the span. I assume that it is a bug in DE, unless I'm missing something obvious.

[kovidgoyal]

That is a bug in DE. The problem with that solution is that the second line of the paragraph will be below the number, so it wont really be a margin note. That would work only if CSS would allow a float's height to be specified as 100% of the parent's height. Unfortunately, that doesn't seem to be possible as setting height=100% has no effect.

[jbenny]

Originally Posted by kovidgoyal

That is a bug in DE. The problem with that solution is that the second line of the paragraph will be below the number, so it wont really be a margin note. That would work only if CSS would allow a float's height to be specified as 100% of the parent's height. Unfortunately, that doesn't seem to be possible as setting height=100% has no effect.

Did you actually try my example? The numbers and the paragraphs display as if they are in two separate colums. This certainly does what the original poster asked for.

BTW, I fixed the bad behaviour of DE by adding "margin-top: 0" to the paragraph style. It also works the same in FF and IE 6. Shouldn't be necessary, but it works.

EDIT: attached is a cropped screenshot of how it looks in DE.