View Full Version : Page or Body?


ghostyjack
04-27-2010, 12:45 PM
I'm trying to create a standard CSS file that I can import into my epub files. This file will contain all the standard content that I would need for most of my epub files. If the epub need any specific css code, I can always add it later.

One area that I'm not certain about is the use of "body" and "page".

What is the difference between body and page?

What things should I have placed in the body tag and what in page?

For the body tag I would have it in CSS like:

body {element1:x; element2:y;}

What is the correct syntax for page?

Any help would be most appreciated.

charleski
04-27-2010, 02:55 PM
The @page directive differs from a tag rule in that it refers to the page that's actually displayed rather than a logical entity. The only attributes that you can use govern the margins, and, since there's no font size defined in this context, you have to use absolute measurements or % values.

Generally, margin-top and margin-bottom are best placed in the @page directive, where they will govern the top and bottom margins of each displayed page. The margin-top and -bottom values in the body definition will govern the margins of the entire flow, so if you have some text that flows over several pages, the margin-top value from body would be seen on the first page, and the bottom value on the last page, which would probably not be what you want.

You could place margin-left and -right values in the @page rule, but ADE places its right-side page numbers inside the page, but outside the body. This means that to get maximum clearance between these page numbers and the text it's best to leave the @page margin-left and -right at 0, then define a left and right margin in the body.

What I use is:

@page {
margin-top: 9pt;
margin-bottom: 1pt
}

body {
margin-left: 12pt;
margin-right: 12pt
}

The margin-bottom value is really there just to prevent ADE allowing text to collide with the bottom of the page, which leads to it greying-out the lower pixels of descenders. In practice the actual size of the bottom margin will depend on how many lines fit into a page and whether the orphan rule is being applied.

I prefer to use absolute values for the page margins (the one area where this makes sense), but it's possible to use % values instead, in which case the size of the margin varies with the size of the display. This can help to modulate margin size for those reading on small devices like smartphones, but may lead to needlessly large margins on bigger screens. A value of 2% is usually best if you go this route, larger vlaues can lead to problems.

christiannielsen
08-06-2012, 02:23 PM
This information was very useful.

Also, body margin doest overrule the browser standard margin preferences, isnt that correct?

I want to define page margin for safari iOS, but @page is not supported by safari. Do you know any alternative solution?




The @page directive differs from a tag rule in that it refers to the page that's actually displayed rather than a logical entity. The only attributes that you can use govern the margins, and, since there's no font size defined in this context, you have to use absolute measurements or % values.

Generally, margin-top and margin-bottom are best placed in the @page directive, where they will govern the top and bottom margins of each displayed page. The margin-top and -bottom values in the body definition will govern the margins of the entire flow, so if you have some text that flows over several pages, the margin-top value from body would be seen on the first page, and the bottom value on the last page, which would probably not be what you want.

You could place margin-left and -right values in the @page rule, but ADE places its right-side page numbers inside the page, but outside the body. This means that to get maximum clearance between these page numbers and the text it's best to leave the @page margin-left and -right at 0, then define a left and right margin in the body.

What I use is:

@page {
margin-top: 9pt;
margin-bottom: 1pt
}

body {
margin-left: 12pt;
margin-right: 12pt
}

The margin-bottom value is really there just to prevent ADE allowing text to collide with the bottom of the page, which leads to it greying-out the lower pixels of descenders. In practice the actual size of the bottom margin will depend on how many lines fit into a page and whether the orphan rule is being applied.

I prefer to use absolute values for the page margins (the one area where this makes sense), but it's possible to use % values instead, in which case the size of the margin varies with the size of the display. This can help to modulate margin size for those reading on small devices like smartphones, but may lead to needlessly large margins on bigger screens. A value of 2% is usually best if you go this route, larger vlaues can lead to problems.

christiannielsen
08-06-2012, 02:24 PM
email sub

mmat1
08-07-2012, 02:55 PM
What things should I have placed in the body tag and what in page?


The only thing I put into the <body> in addtion to the margin (as explained by charleski) is the "font-family".

Usually the font of my books is only defined there. There are some devices out in the world which have problems to display the font defined by the user in his reader, if the font is assigned to every <p> or <div> tag.

JSWolf
08-07-2012, 05:26 PM
The only thing I put into the <body> in addtion to the margin (as explained by charleski) is the "font-family".

Usually the font of my books is only defined there. There are some devices out in the world which have problems to display the font defined by the user in his reader, if the font is assigned to every <p> or <div> tag.

Incorrect (I think). Kobo readers have a bug where they will ignore the font-family put in the body style. They will respect font-family elsewhere like <p> or <div>.

I've never heard of any reader that uses ADE that does not respect font-family in <p> or <div>.

Jellby
08-08-2012, 03:20 AM
I've never heard of any reader that uses ADE that does not respect font-family in <p> or <div>.

I think he means that if a book specifies a font in <p> or <div>, the user won't be able to choose a different font in the reader.

mmat1
08-08-2012, 12:18 PM
Incorrect (I think). Kobo readers have a bug where they will ignore the font-family put in the body style. They will respect font-family elsewhere like <p> or <div>.

I've never heard of any reader that uses ADE that does not respect font-family in <p> or <div>.

Maybe i didn't state it clearly enough: PB-readers will respect a font-family assignment in body, div and p.

If the font family is only assigned to the body, then the user will be able to select another font on his reader without problems.

Any font-assignment to a p/div/span will prevent this, this section is always displayed in the font the bookmaker assigns to it.

Concerning the Kobo-Bug: I don't care. Kobo shall fix it.

JSWolf
08-08-2012, 04:18 PM
Maybe i didn't state it clearly enough: PB-readers will respect a font-family assignment in body, div and p.

If the font family is only assigned to the body, then the user will be able to select another font on his reader without problems.

Any font-assignment to a p/div/span will prevent this, this section is always displayed in the font the bookmaker assigns to it.

Concerning the Kobo-Bug: I don't care. Kobo shall fix it.

It depends on how the font is specified. If you use font-family: "Charis SIL" then no, it won't work to change the font in all readers that support font changing. But if you use font-family: serif then most if not all should be able to change the font. I know the T1 will be able to change the font as long as serif is used as the font name and it doesn't matter where this is used.

As for the Kobo, no, they will not fix the bug. They've known about it since the original Kobo and I've even PMed Kobo staff on MR about it on the Touch and still they refuse to fix the bug. If they were going to fix it, it would have been fixed by now.

mmat1
08-09-2012, 12:42 PM
It depends on how the font is specified. If you use font-family: "Charis SIL" then no, it won't work to change the font in all readers that support font changing. But if you use font-family: serif then most if not all should be able to change the font. I know the T1 will be able to change the font as long as serif is used as the font name and it doesn't matter where this is used.

Yes there is probably a difference between gerneric fonts (serif, sans-serif and monospace) and embedded fonts (i. e. Charis).

I understand, that the T1 won't change the font on userinterface if there is an embedded font defined, but is fine with generic fonts ...


As for the Kobo, no, they will not fix the bug. They've known about it since the original Kobo and I've even PMed Kobo staff on MR about it on the Touch and still they refuse to fix the bug. If they were going to fix it, it would have been fixed by now.

Business as usual ....

JSWolf
08-10-2012, 08:56 PM
Yes there is probably a difference between gerneric fonts (serif, sans-serif and monospace) and embedded fonts (i. e. Charis).

I understand, that the T1 won't change the font on userinterface if there is an embedded font defined, but is fine with generic fonts ...

You misunderstood. The T1 replaces serif with the selected font. That's why if you use serif as the name of the embedded font, it can be changed.