Placing div's side by side

[exaltedwombat]

Customers seem to prefer a table to a text graphic.
I tried integrating captions with their picture. Got complaints that the text quality didn't match up, but they seem to accept the occasional orphaned caption. No accounting for taste!
If you want a real crash down to Earth, try formatting for a customer who has discovered Smashwords. They don't accept ANYTHING :-(

[theducks]

Originally Posted by mrmikel

And tables are NOT rotate-able to take advantage of the longer dimension of the page either. If you have to use an image in order for a table to work, you might as well be using a PDF if the device is big enough. Since I have a PRS-300, images are how I go.

Lack of this feature in EPUB has me

With some devices having accelerometers not having the ability to control rotation or best fit seems daft.

[DaleDe]

Originally Posted by theducks

Lack of this feature in EPUB has me

With some devices having accelerometers not having the ability to control rotation or best fit seems daft.

An accelerometer would likely override the landscape mode if it existed so they would have to be turned off. Today, if the reader application supports rotation then the user can take advantage of the wider screen format simply by rotating the device. The @page CSS construct does have support for landscape but ePub doesn't support this feature. I do agree this would be nice, particular for devices that do not have an accelerometer.

Dale

[mrmikel]

Right now, wide tables in e-ink readers are good eye tests --- is it 5 or 6????(grin)

[exaltedwombat]

Originally Posted by mrmikel

Right now, wide tables in e-ink readers are good eye tests --- is it 5 or 6????(grin)

Do we mean the same thing by "table"? I'm just talking about a method of laying out standard text using HTML.

[mrmikel]

Wide tables must have very small type in 5-6" e-ink readers, hence the comment.

[exaltedwombat]

Originally Posted by mrmikel

Wide tables must have very small type in 5-6" e-ink readers, hence the comment.

No more so than other lines of text. Within a table cell, text will line-wrap same as anywhere else.

[theducks]

Originally Posted by DaleDe

An accelerometer would likely override the landscape mode if it existed so they would have to be turned off. Today, if the reader application supports rotation then the user can take advantage of the wider screen format simply by rotating the device. The @page CSS construct does have support for landscape but ePub doesn't support this feature. I do agree this would be nice, particular for devices that do not have an accelerometer.

Dale

I want to be able to ignore (or counteract) the device orientation.

Say I pre-rotate a chart or Image to take advantage of the 3:4 aspect (normal view on most older dedicated devices). The (best aspect) control would stop rotation IF the device was already rotated.

[mrmikel]

2,000,456 or a similar number you do not want to wrap. Words will not hyphenate inside a table so must be <br />ed.

Attached is a jpg that illustrates this sort of problem.

[mrmikel]

Ducks, seems like you want the dwim button. (Do what I mean!)

[theducks]

Originally Posted by mrmikel

Ducks, seems like you want the dwim button. (Do what I mean!)

An early (Electronics Engineering) boss taught me the 6 P's
Prior Planning Prevents Piss Poor Performance

Anticipating problem scenarios fits right in.

[mrmikel]

I do a lot of non-fiction and tables are a part of it. I would rather leave it out, but.....

[Jellby]

Originally Posted by theducks

I want to be able to ignore (or counteract) the device orientation.

Say I pre-rotate a chart or Image to take advantage of the 3:4 aspect (normal view on most older dedicated devices). The (best aspect) control would stop rotation IF the device was already rotated.

I'd say it's best NOT to pre-rotate things. If something would look better in landscape, the user can rotate the display (either manually or with the accelerometer) in most readers.

[theducks]

Originally Posted by Jellby

I'd say it's best NOT to pre-rotate things. If something would look better in landscape, the user can rotate the display (either manually or with the accelerometer) in most readers.

I forgot I even HAD a rotate item on the menu

[Hitch]

Originally Posted by exaltedwombat

Customers seem to prefer a table to a text graphic.
I tried integrating captions with their picture. Got complaints that the text quality didn't match up, but they seem to accept the occasional orphaned caption. No accounting for taste!
If you want a real crash down to Earth, try formatting for a customer who has discovered Smashwords. They don't accept ANYTHING :-(

Yes, this has created misery for us as well, even for fiction. If you are creating an ePUB with any embedded fonts, you need the xml file for Apple, to ensure that the fonts display. But that makes intake fail at Smashwords, which is using an older version of ePUBcheck. So, then, you have to remove it, which means that when the book is distributed via SW to iBooks, maybe the fonts will work; maybe they won't. This mightn't be the end of the world for something relatively minor, like Chapter heads; but it's death on a stick for an embedded font used for, say, Cyrillic letters or something akin.

I see that Rob over at 52N has taken a direct approach to it and simply made it expensive. That's one way of handling it, I suppose. We try to make our customers happy, but...there's only so many ways you can get stretched. We're already at (occasionally) two ePUBs, one for iBooks, one for everyone else; sometimes a third if it's a publisher (an ePUB optimized for Amazon), otherwise it's a MOBI...and now we have people complaining because perhaps they loaded some obscure reading app on some Droid tablet and the file "doesn't look right" because they can override publisher defaults. It's a bloody headache, I tell you. Until something gets done about actual standardization--which I don't ever see happening--it's not going to get better, only worse.

And that's my happy thought du jour.

@mrmikel:

Basically, we test every table we do on a smaller device--either a Nook or an older/smaller Kindle. If it works there, great. If it doesn't, image. And folks here should remember that a Nook, for example, will skip right past a table, as though it doesn't exist, if the table is too long (too many rows, or too many wide rows) to display on a single screen. The reader won't even know it was there...it simply pages past it. Don't say you weren't warned!

Hitch