<div> instead of <p>?

[Slevin#7]

Guys, you're missing the point: the Apple users are the real victims here - once again extra hours with the psychiatrist...

[Moonbase59]

@Slevin#7: Yeah, it’s a mess- The more apps & devices you try, the more problems you find… :-(

@RbnJrg: I don’t change smartphones often – it’s a Sony Xperia (H4213) running Android 9. No more updates, as usual… :-(

And you know what? After switching it to page margins "Author" once, I can’t make it misbehave anymore, whatever I set the page margins to! So maybe there is a hidden bug in the PB app somewhere…

KOReader on the same device works nicely.

[PeterT]

The hiding / placement of options in many programs I find highly counter intuitive.

So few programs come with any real documentation these days. Authors seem to have a myriad of ways to hide even finding their settings menu.

And it's not just mobile apps. I always have a hard time remembering where on earth certain features are within calibre.

[Quoth]

Though there is some excuse for Calibre as it's at least:

• A Library / Database to manage your ebooks
• An advanced full text content search system for research
• An ebook viewer
• An ebook editor, inc ToC creation/editing and more.
• Manage devices and transfer to or from them, inc user templates.
• Edit Metadata.
• Create or add covers
• Search Internet for covers or metadata.
• Convert between many ebook formats.
• Manage annotations from devices (Kobo Utilities or Annotations)
• Well supported 3rd party plugins for many features*.
• Supports all three main OS for desktops/laptops
• A server that provides a web interface and OPDS.
• Can create catalogues as ebooks
• Better docx to epub than expensive "rent only" Adobe InDesign

It's beyond a Swiss Army knife or tool box but a virtual digital version of the library in a mansion (not a lending library) with a workshop and expert bookbinders, librarians, researchers, secretaries and butler. However it doesn't actually serve drinks.

A multi-tool where each blade or part can be a multi-tool!


Thanks Kovid. It's up there with web Browser, spreadsheet, wordprocessor, email and image editor for anyone that writes, reads or publishes as a "must have" application.

[* What's in this cupboard? Oh, fantastic!]

[RbnJrg]

Originally Posted by Moonbase59

And you know what? After switching it to page margins "Author" once, I can’t make it misbehave anymore, whatever I set the page margins to! So maybe there is a hidden bug in the PB app somewhere…

Well, now we have the same "issue" , try changing the paragraph in lightblue to have <div> instead of <p> tag. The problem should disappear.

[Moonbase59]

Originally Posted by RbnJrg

try changing the paragraph in lightblue to have <div> instead of <p> tag.

Nah, as I said above, I give up. And I will not change well-done EPUBs just for a bloody effing reader deficiency! Let them repair their reader software.

Yep, that’s just how I am. Stubborn, at times. ;-)

[Quoth]

Originally Posted by RbnJrg

Well, now we have the same "issue" , try changing the paragraph in lightblue to have <div> instead of <p> tag. The problem should disappear.

No, they need to fix their end. I'm not going to break the semantic and other logics of the epubs. Clue in name. p for paragraph, div for division.

Oddly I don't see the issue on my pocketbook app on Android.

[JSWolf]

Originally Posted by RbnJrg

By enabling author-based margins (a hidden feature deep within the application's settings), PB honors the margins specified in the style sheet.

However, if the user happens to modify the page margins using the easily accessible command in PB's main menu, the program not only modifies the page margins, but also all the margins, including paragraph margins. Thus, the specific values specified in the style sheet are no longer honored.

The only way for these margins to remain unchanged even when the user changes the page margins is to use <div> tags instead of <p> in paragraphs where a special margin is required. Terrible handling of margins by PB.

Is this an issue with PB on iOS or just Android?

[RbnJrg]

Originally Posted by JSWolf

Is this an issue with PB on iOS or just Android?

Slevin#7 has iOS and his PB has the bug; Moonbase59 has Android and his PB has the bug; the same for me with Android. But Quoth has Android and his PB works fine. You see, there is something for everyone.

[Slevin#7]

Originally Posted by JSWolf

Is this an issue with PB on iOS or just Android?

Originally Posted by RbnJrg

Slevin#7 has iOS and his PB has the bug

I have an iOS and I don't even have the feature to set margins to authors. All I have is the dignity to smile and wave and have some lemon ice.

[Moonbase59]

Originally Posted by Slevin#7

I have an iOS and I don't even have the feature to set margins to authors.

Maybe it’s called differently—Pocketbooks’s translations are sometimes a bit off. My German version also has no "Author", it’s called "Default" there. Or maybe it’s not there at all, because of Apple iOS restrictions.

[Slevin#7]

Originally Posted by Moonbase59

Maybe it’s called differently—Pocketbooks’s translations are sometimes a bit off. My German version also has no "Author", it’s called "Default" there. Or maybe it’s not there at all, because of Apple iOS restrictions.

As you may see here, this is all you can configure about margins:


And whatever you set, it only affects page margins, not any p-tag or elsewhat margins.

I never set any applications to German, since this makes things just senseless complicated for development, but to explain, 'unset' means really unset and not default in the sense of author's preference.

Anyhow, I will share now my current solution which has the benefit to keep semantically correct p-tags. I will add this pseudo-element class only to selected p-tags where absolutely necessary due to styling issues otherwise. At least with the readers I've tested there seems no clash so far with the standardly applied styles. And Google also makes no troubles although height is set to 0. So here we go:

CSS

p.special-treatment:before,
p.special-treatment:after {
  content: "";
  display: block;
  height: 0 !important;
}

p.special-treatment:before {
  margin-top: 2em;
}

p.special-treatment:after {
  margin-bottom: 2em;
}

We add block elements with a height of 0, apply margins and therefore stay in the same margin-scope with p which allows for collapsing.

Hallelujah everyone, just doing well asylum style...

[RbnJrg]

Originally Posted by Slevin#7

As you may see here, this is all you can configure about margins:
Attachment 217075

And whatever you set, it only affects page margins, not any p-tag or elsewhat margins.

I never set any applications to German, since this makes things just senseless complicated for development, but to explain, 'unset' means really unset and not default in the sense of author's preference.

Anyhow, I will share now my current solution which has the benefit to keep semantically correct p-tags. I will add this pseudo-element class only to selected p-tags where absolutely necessary due to styling issues otherwise. At least with the readers I've tested there seems no clash so far with the standardly applied styles. And Google also makes no troubles although height is set to 0. So here we go:

CSS

p.special-treatment:before,
p.special-treatment:after {
  content: "";
  display: block;
  height: 0 !important;
}

p.special-treatment:before {
  margin-top: 2em;
}

p.special-treatment:after {
  margin-bottom: 2em;
}

We add block elements with a height of 0, apply margins and therefore stay in the same margin-scope with p which allows for collapsing.

Hallelujah everyone, just doing well asylum style...

Nice! The problem here Is the code doesn't work for RMSDK (ADE Legacy).

[Slevin#7]

Originally Posted by RbnJrg

Nice! The problem here Is the code doesn't work for RMSDK (ADE Legacy).

Which reader would that affect, and with which result?

I mean, ADE isn't worth the time to deal with - out of curiousity I've looked up the iOS app, it is 4 years old and has one of the most bad ratings in the whole app store of 1.1 out of 105 votes, that's just awful. All reviews, really ALL are 1 star and complaining through and through. I have never seen something like that, even Disney's Snow White got better ratings. So if there is no real requirement other than ADE, just let it die gracefully...

[Quoth]

Very many older ereaders (maybe all that do epub) and some current ereaders use ADE.

Obviously apps on iOS and Android are a different kettle of fish and very many Android ereaders make epubs worse than a conversion to mobi for a Gen1 or Gen2 Kindle, certainly far worse than ancient ADE versions on a Binatone ereader. Absolute garbage. Though it's a few years now since my mad spree of testing Android ereader apps.

Edit:
Not impossible that ADE on iOS is crippled in some fashion.