ADE adds blank pages?

[JSWolf]

You might want to play around with making that ornament a transparent PNG and see how it works.

[Psymon]

Originally Posted by JSWolf

You might want to play around with making that ornament a transparent PNG and see how it works.

Um, I think I said that.

[Psymon]

Originally Posted by JSWolf

You might want to play around with making that ornament a transparent PNG and see how it works.

Done! Looks fine now (along with other ornaments that were JPEG before).

[dgatwood]

Originally Posted by Hitch

Sorry to get off on a tear, but at the very least, let's try to avoid using PX for positioning in REFLOWABLE BOOKS.

I'm not sure I necessarily agree. There probably are some situations where positioning shouldn't depend on font size. If you can guarantee CSS3 support, viewport-relative units (vw/vh/vmin/vmax) are usually better choices than px, but if not, then px is the only real option left.

It is, however, critical for developers/designers to take the time to think about what they're trying to accomplish, to decide whether the size unit should depend on the font size or not, and to test on a wide range of screen sizes with a wide range of font magnification settings to make sure their decision really was the right one.

[Hitch]

Originally Posted by dgatwood

I'm not sure I necessarily agree. There probably are some situations where positioning shouldn't depend on font size. If you can guarantee CSS3 support, viewport-relative units (vw/vh/vmin/vmax) are usually better choices than px, but if not, then px is the only real option left.

It is, however, critical for developers/designers to take the time to think about what they're trying to accomplish, to decide whether the size unit should depend on the font size or not, and to test on a wide range of screen sizes with a wide range of font magnification settings to make sure their decision really was the right one.

dg:

God have mercy on my soul. that's all I'm gonna say. Ok, no, it's not all I'm gonna say: for some VERY LIMITED aspects, in ePUB3, for special purposes, fine. But generally, for ePUB2, and everybody who is Un-Apple..no. Not normally. And not for scene-breaks, in my humble opinion, which is worth less than you are paying for it, right this second.

Hitch

[DaleDe]

Originally Posted by dgatwood

I'm not sure I necessarily agree. There probably are some situations where positioning shouldn't depend on font size. If you can guarantee CSS3 support, viewport-relative units (vw/vh/vmin/vmax) are usually better choices than px, but if not, then px is the only real option left.

It is, however, critical for developers/designers to take the time to think about what they're trying to accomplish, to decide whether the size unit should depend on the font size or not, and to test on a wide range of screen sizes with a wide range of font magnification settings to make sure their decision really was the right one.

PX is perfect to avoid the shadow cast by the casing on the edge of the screen for example. 5 px margin works well in this case but for other uses it makes no sense.

Dale

[JSWolf]

Originally Posted by DaleDe

PX is perfect to avoid the shadow cast by the casing on the edge of the screen for example. 5 px margin works well in this case but for other uses it makes no sense.

Dale

@page {
margin-top: 5px;
margin-right: 5px;
margin-left: 5px
}

That's a case where I do agree what px works fine.

[Psymon]

Originally Posted by JSWolf

@page {
margin-top: 5px;
margin-right: 5px;
margin-left: 5px
}

That's a case where I do agree what px works fine.

Not bottom? Is it just assumed that light won't be coming from the bottom (i.e. from "you"), hence no shadow there?

[Jellby]

Originally Posted by DaleDe

PX is perfect to avoid the shadow cast by the casing on the edge of the screen for example. 5 px margin works well in this case but for other uses it makes no sense.

Given the rather unintuitive and sometimes ambiguous (or wrongly implemented) definition of "px" in CSS, I'd say it's better to use a really absolute unit (like "mm") in those cases. Even so, "mm" is sometimes not correctly implemented either.

Originally Posted by Psymon

Not bottom?

Jon is of the opinion that you don't need a bottom margin, because the text will often not reach the bottom edge, as it only displays full lines. Of course, that doesn't mean it cannot reach it. Only by adding a bottom margin will you prevent it, and the margin should not affect the cases where the text wouldn't reach the bottom anyway.

[theducks]

Originally Posted by Psymon

Not bottom? Is it just assumed that light won't be coming from the bottom (i.e. from "you"), hence no shadow there?

The bottom is not the screen bottom on many devices.

Many have a reserved status line (may be blank most of the time on some devices, but it is still there)

My PEz is most times blank
My K4NT has reading Progress (It also has a TOP info/status)


The RULE:
There are no hard rules.

Know your target device if you are fine tuning to the device level, otherwise use a Generic, not-quite optimum settings

[Psymon]

You guys (and gals) keep coming up with stuff that means that I have to go back and re-do ALL my previous ebooks!

Stop it! I'm doing just fine until y'all make me "aware" of something -- ignorance is bliss, don't you know?

[JSWolf]

Originally Posted by Jellby

Jon is of the opinion that you don't need a bottom margin, because the text will often not reach the bottom edge, as it only displays full lines. Of course, that doesn't mean it cannot reach it. Only by adding a bottom margin will you prevent it, and the margin should not affect the cases where the text wouldn't reach the bottom anyway.

Most eInk readers have a footer at the bottom of the sreen and thus you won't be reaching the bottom of the screen. Even even so, you don't reach the very bottom all the time anyway be it eInk or a tablet/phone. So I see little need for a bottom margin.

[Psymon]

Geez! On a semi-related note to this thread, I just discovered that the latest update to iBooks would seem to start the first page of the book on the right-hand page (in two-page landscape mode), which means that ALL the books that I've done, which all incorporate a nice frontispiece that previously would show up opposite the title page, now have the frontispiece on the right-hand page, followed by the title page on the left.

ADE on my PC still displays things the way they're supposed to (that is, the way I wanted them to, and expected them to), but this now has me wondering whether to ever include a nice frontispiece at all, in any of my books, and just start with the title page. :/

[Toxaris]

Well, it has been said several times before. The more fancy you make things, the bigger the change that it will not work cross-devices or break after an update. That being said, iBooks is doing everything like its wants, inventing its own crippled variations on the standard. It is almost like iBooks is something from Apple...

[Hitch]

Originally Posted by Toxaris

Well, it has been said several times before. The more fancy you make things, the bigger the change that it will not work cross-devices or break after an update. That being said, iBooks is doing everything like its wants, inventing its own crippled variations on the standard. It is almost like iBooks is something from Apple...

Listen to Toxaris. He's seen some of our "fancier" books (beta testing), and he KNOWS. What works hither shan't work thither.

(n.b.: we just spent days doing VISUAL POETRY. No. I don't want to talk about it. I vaguely want to shoot myself for accepting it in the first place, but it's in a prestigious literary journal. {sigh})

Hitch