pagestyle.css extra / integrated in stylesheet.css / or not at all?

[chaot]

This time the title says almost everything, right?

I got books which an extra pagestyle.css file.


pagestyle.css

The CSS looks most time somehow like this

@page {
  margin: 5px;
  }

That means, the pages coming in an ereader frame all around (top, bottom, left, right) 5px smaller.
I delete such an pagestyle.css (or put it to zero) - I want to see the characters (words) of the book and not a ''nice'' margin. (I think to make pagestyle (5px or even 10 px or more) is also a comercial argument - book got more pages.)

If I want pagestyle I can integrate it in the normal stylesheet, or not?

Do I need pagestyle for any purpose. I think no pagestyle is the same as pagestyle margin: 0.

Do pagestyle anyhow affect the CSS Box-model (margin/border/padding)?

[JSWolf]

I do think you should dump pagestyle.css.an @page is not needed. The problem with @page is that is forces margins when a margin of 0 is best. A margin of0 is best so that when using programs/apps that have margin settings, you get the margins the user wants using the margin settings instead of some fixed margin with the options only being able to add to that.

[jackie_w]

@chaot,

The existence of page_styles.css suggests you have an epub created by a calibre conversion. If you don't want it created you should review your calibre conversion settings - specifically the 4 x Margin settings on the Page Setup page. I have all mine set to 'Unchanged' and the extra page_styles.css is not created during conversion.

Caveat: If your epub contains embedded fonts then converting it will still create page_styles.css file and all the @font-face css statements will have been moved into it.

[BetterRed]

Originally Posted by jackie_w

I have all mine set to 'Unchanged' and the extra page_styles.css is not created during conversion.

since day 0 I've had mine set to 4 x 0, hoping that would get rid of it

BR

[Turtle91]

AFAIK the reason for a separate pagestyle.css was that the @page was not handled by certain devices. If that @page was included, it would disregard the entire stylesheet... so people would put it on its own sheet so it would not affect any other style commands.

I'm not sure if this is still an issue, but that's what I understood the reasoning to be...

Cheers,

[Toxaris]

Originally Posted by JSWolf

I do think you should dump pagestyle.css.an @page is not needed. The problem with @page is that is forces margins when a margin of 0 is best. A margin of0 is best so that when using programs/apps that have margin settings, you get the margins the user wants using the margin settings instead of some fixed margin with the options only being able to add to that.

No, you feel it is not needed and that a margin of 0 is best. Don't confuse your personal opinions with other peoples opinions. I personally like a small margin for each page. I feel that putting the value to 0 puts the text too close to the bezel of my reader and making reading harder.
Not all readers support margin settings in their software. In fact, I like my reader to honor the stylesheet as much as possible and perhaps only allow changes to the font-size.

Then again, that is MY opinion and I fully understand that other people have other opinions and I do not impose that my opinion is superior.

[JSWolf]

Originally Posted by Toxaris

No, you feel it is not needed and that a margin of 0 is best. Don't confuse your personal opinions with other peoples opinions. I personally like a small margin for each page. I feel that putting the value to 0 puts the text too close to the bezel of my reader and making reading harder.
Not all readers support margin settings in their software. In fact, I like my reader to honor the stylesheet as much as possible and perhaps only allow changes to the font-size.

Then again, that is MY opinion and I fully understand that other people have other opinions and I do not impose that my opinion is superior.

The problem comes from programs/apps/Readers that do not have a margin control. Most modern programs/apps/Readers do have a margin control and setting a margin other than 0 can take full control out of the hands of the user. So in your opinion, what is the solution? Not all programs/apps/Readers that have a margin control can override the margins. So for those users, 0 is best.

[Toxaris]

Originally Posted by JSWolf

The problem comes from programs/apps/Readers that do not have a margin control. Most modern programs/apps/Readers do have a margin control and setting a margin other than 0 can take full control out of the hands of the user. So in your opinion, what is the solution? Not all programs/apps/Readers that have a margin control can override the margins. So for those users, 0 is best.

In my opinion programs/apps/Readers should not override any settings that is set in the stylesheet, with the exception of the font-size. Which can easily be done if the font-size is set in em. I feel that a lot of reading apps use 'overrides' because they think it is too hard to support the stylesheet and call it 'user friendly'.

Of course there are good and bad books out there, but in general a reading app should honor the stylesheet. Like I said, if there is no margin, the text is too close to the screen edge to read comfortably.

[JSWolf]

Originally Posted by Toxaris

In my opinion programs/apps/Readers should not override any settings that is set in the stylesheet, with the exception of the font-size. Which can easily be done if the font-size is set in em. I feel that a lot of reading apps use 'overrides' because they think it is too hard to support the stylesheet and call it 'user friendly'.

Of course there are good and bad books out there, but in general a reading app should honor the stylesheet. Like I said, if there is no margin, the text is too close to the screen edge to read comfortably.

The problem is that different people like things differently. I like a smaller margin and a smaller line-height than some. So if you put in no margins and no line-height, you can set the margin and line-height as you like and I can set these as I like. But, if you have a margin and line-height that you like, it might not be how I like or what the other person likes. Start with the lowest common options and let the user use the settings to change things.

There is one way to please everyone. No DRM and make it so the margins and line-height are set in the body style. Just edit the body style and you are good to go. It's really that simple. But in reality, it'll never be that simple.

[chaot]

Originally Posted by Toxaris

I feel that putting the value to 0 puts the text too close to the bezel of my reader and making reading harder.

My Tolino generates (values to 0) always a left/right margin of about 4mm (top/bottom even more) what I think is fairly enough.

[dgatwood]

Originally Posted by Turtle91

AFAIK the reason for a separate pagestyle.css was that the @page was not handled by certain devices. If that @page was included, it would disregard the entire stylesheet... so people would put it on its own sheet so it would not affect any other style commands.

Specifically, unless they've improved things very recently, Adobe Digital Editions barfs on almost all @ rules except for @font and certain extremely basic @media rules. That means any reader based on RMSDK also fails in the same way, which means that readers are probably more likely to fail on @page rules than handle them correctly.

[GeoffR]

Originally Posted by dgatwood

Specifically, unless they've improved things very recently, Adobe Digital Editions barfs on almost all @ rules except for @font and certain extremely basic @media rules. That means any reader based on RMSDK also fails in the same way, which means that readers are probably more likely to fail on @page rules than handle them correctly.

This was fixed long ago, RMSDK10 (released 2014) has no problem with @page.

[Toxaris]

Originally Posted by dgatwood

Specifically, unless they've improved things very recently, Adobe Digital Editions barfs on almost all @ rules except for @font and certain extremely basic @media rules. That means any reader based on RMSDK also fails in the same way, which means that readers are probably more likely to fail on @page rules than handle them correctly.

Err, what? Even my (very) old PRS-300 from 2009 supports the @page perfectly fine.

[dgatwood]

Originally Posted by Toxaris

Err, what? Even my (very) old PRS-300 from 2009 supports the @page perfectly fine.

Interesting. It failed for me as recently as a couple of years ago. Maybe it's a problem that has periodically been fixed and rebroken, or maybe it was some specific subfeature of @page that I was experimenting with (perhaps @top-center).

And at last check, @media worked for simple things, like the standard Kindle strings, but broke with more interesting rules like these:

@media not screen {
...
}
@media screen and (max-device-width:960px) and (orientation:portrait) {
...
}
@media (-webkit-min-device-pixel-ratio: 2) {
...
}

[Turtle91]

Originally Posted by GeoffR

This was fixed long ago, RMSDK10 (released 2014) has no problem with @page.

OK. I was simply mentioning where the technique came from... or at least my understanding of where it came from. As we all know, people tend to use the techniques they know without totally understanding why they do...

Is it wrong to put it on a separate sheet?? No. Is it necessary?? Maybe, maybe not. Are you willing to take a chance by putting it on the same sheet?? I am, because I know my reader of choice doesn't barf on it and I only code for my personal use.

Cheers,