Override ePub CSS with userStyle.css?

[barium]

Can I tell the PRS-350 to ignore ePubs' CSS and use the userStyle.css for all ePubs instead? That would make editing individual ePubs' CSS unnecessary.

I installed porkupan/boroda's firmware, and made some changes to userStyle.css. The changes don't seem to affect ePub formatting. Maybe I'm entering bad CSS code, but I think there may be conflicting CSS in the ePub files I'm viewing.

Can someone please tell me if the CSS code below has errors in it?

(1) eliminate margins:

p {
   margin-left: 0;
   margin-right: 0;
   margin-top: 0;
   margin-bottom: 0;
}

(2) set line height to 1.04em:

p {
line-height: 1.04em;
}

(3) eliminate blank lines between paragraphs and indent paragraphs:

p, div {
margin: 0pt;
border: 0pt;
text-indent: 1.5em;
}

Maybe adding !important to each item would do the trick?

[barium]

For some calibre created epubs, I found the following, idiotic solution. I viewed the stylesheet.css for one, and noticed several .calibre# classes with formatting information.

E.g.:
.calibre1 {
border: 1px inset;
color: black;
display: block;
height: 2px;
margin-bottom: 0.5em;
margin-left: auto;
margin-right: auto;
margin-top: 0.5em
}

In my userStyle.css, I replaced the formatting in ALL of those classes with my desired formatting for the p {} tag:

.calibre1 {
line-height: 1.06em !important;
margin-top: 0 !important;
padding:0;
etc.
}

.calibre2 {
line-height: 1.06em !important;
margin-top: 0 !important;
padding:0;
etc.
}

And that worked. Now news downloads, and other calibre created epubs, look more or less the way I'd like them to. A lot of formatting is ripped out, of course. And there are some gaps, because some calibre epubs use more classes than others, but I think that should be easy to fix by simply adding more .calibre# classes to userStyle.css.

ePubs created elsewhere, though, use different classes and tags, but I guess coming up with several commonly used classes and tags and ripping them out using the userStyle.css file in the same way should help.

[jswinden]

Originally Posted by barium

Can I tell the PRS-350 to ignore ePubs' CSS and use the userStyle.css for all ePubs instead? That would make editing individual ePubs' CSS unnecessary.

I installed porkupan/boroda's firmware, and made some changes to userStyle.css. The changes don't seem to affect ePub formatting. Maybe I'm entering bad CSS code, but I think there may be conflicting CSS in the ePub files I'm viewing.

Can someone please tell me if the CSS code below has errors in it?

(1) eliminate margins:

p {
   margin-left: 0;
   margin-right: 0;
   margin-top: 0;
   margin-bottom: 0;
}

(2) set line height to 1.04em:

p {
line-height: 1.04em;
}

(3) eliminate blank lines between paragraphs and indent paragraphs:

p, div {
margin: 0pt;
border: 0pt;
text-indent: 1.5em;
}

Maybe adding !important to each item would do the trick?

-------------------------------------------------------------------------

I think you need a measurement type for margin:

p {
   margin-left: 0em;
   margin-right: 0em;
   margin-top: 0em;
   margin-bottom: 0em;
}

or just simplify to p { margin: 0em }.

I doubt if p { line-height: 1.04em } will display any different than p { line-height: 1.00em } unless em is really big.

All the other CSS looks fine, except that I would use em rather than pt for ereaders.

I'm not familiar with porkupan/boroda's firmware, so it might just be the default that you are changing. I would not be surprised if the book's CSS overrides the firmware defaults.

Also, if you edit your ePubs with Sigil you will get much cleaner CSS and HTML. Calibre adds too much garbage to the file which makes it difficult to read when trying to make modifications.

[JSWolf]

You do not need em. And you also do not need a ; on the last line before }.

p {
   margin-left: 0;
   margin-right: 0;
   margin-top: 0;
   margin-bottom: 0
}

The above code is correct.

[barium]

Thanks for the tips.

Originally Posted by jswinden

[I]t might just be the default that you are changing. I would not be surprised if the book's CSS overrides the firmware defaults.

I think that normally, the book's CSS overrides the firmware defaults. But if you add the !important property, the firmware defaults override the book's CSS.

Some ePubs seem to get formatting information from a .xpgt file. I wonder if it's possible to override those using CSS. The formatting in those files doesn't look like it's in the same language, so I don't even know how to try.

[JSWolf]

I tried PRS+ on the 505 and found that the user style sheet overrode what was in the CSS for the eBook and thus, was not all that useful because I was unable to override the user style sheet in the ePub.

[charleski]

Originally Posted by JSWolf

I tried PRS+ on the 505 and found that the user style sheet overrode what was in the CSS for the eBook and thus, was not all that useful because I was unable to override the user style sheet in the ePub.

Your description isn't very clear, but a lot depends on what level you apply the style. I use a 505 with the PRS+ and set everything at the topmost level (the html tag).

For instance, I set Minion as my default font with the following:

@font-face {
       font-family: "Minion";
...
}
... all the necessary directives
html {
	font-family: "Minion";
...
}

This means that any ePub with an embedded font will display that font correctly as long as it applies the tags at the body level or below (which is almost always the case).

Since, in the vast majority of cases, I rip off the DRM and wrangle the css garbage inside the ePub into something that's readable, I don't have much need for the !important overrride. But it's useful for those who don't want to do that all the time.

[edit: BTW, a line-height of 1.04em is WAY too small unless you're using a font with a ridiculously small x-height and then blowing it up. You really want 1.2em at least to get optimal readability. Cramming all the lines together may sound like a good way to get more text on the screen, but it's not really a good idea.]

[JSWolf]

Originally Posted by charleski

[edit: BTW, a line-height of 1.04em is WAY too small unless you're using a font with a ridiculously small x-height and then blowing it up. You really want 1.2em at least to get optimal readability. Cramming all the lines together may sound like a good way to get more text on the screen, but it's not really a good idea.]

Actually, I disagree. I fine 1.2em to be too large. I'd use 1.1em.

But, I use a font-size of 95% and a line-height of 1.03em. That works. But where the font size is larger then the body size like h2, I use 1.1em.

[charleski]

Originally Posted by JSWolf

Actually, I disagree. I fine 1.2em to be too large. I'd use 1.1em.

But, I use a font-size of 95% and a line-height of 1.03em. That works. But where the font size is larger then the body size like h2, I use 1.1em.

Readability is fundamentally determined by word-shape, which means you need enough negative space around the word so that the shape is clearly defined. A leading of at least 1.2em is generally regarded as adequate to provide this.

As I said, this does depend on the font, and you could get by with less if using a font with a particularly small x-height. But it's no co-incidence that fonts designed for high legibilty at small sizes typically have a large x-height and rely on a reasonable amount of leading to provide the negative space needed for shape-recognition.

[JSWolf]

I do find that if there is too much space between the lines, that it is distracting. So I prefer a tighter space between the lines. That's why 1.2em is too large for most fonts I've tried.

[kartu]

The only right way to override fonts in my opinion is:

@font-face
{
        font-family: sans-serif;
        src:url(res://....);
}
@font-face
{
        font-family: serif;
        src:url(res://...);
}
@font-face
{
        font-family: monospace;
        src:url(res://...);
}

As this way you don't have to mess with CSS selectors.

Custom CSS works in all books, but some might have style that overrides yours, which is a generic CSS "issue". Check this:
Understanding the selectors priority

[charleski]

Originally Posted by kartu

Custom CSS works in all books, but some might have style that overrides yours, which is a generic CSS "issue".

Actually, that's the goal: modify the defaults, but allow the book's own css to override these as needed so its design is preserved. If the ePub's design is faulty, then it's the ePub that needs to be fixed, since mucking around with !important properties that will mess things up in other books.

But you have a point about redefining the base font classes, that will catch cases where the book (unnecessarily) has something like body { font-family: serif ... }.