View Full Version : What part of the CSS can cause this? (smallcaps related in Sigil)


mtrahan
05-30-2011, 10:43 AM
Dear ePub experts,

I need your help again. I'm working on an ePub produced by InDesign CS5. Original document is a complex book designed for print—I had to simplify the styles a lot but after some work (thanks for the help I got here (http://www.mobileread.com/forums/showthread.php?t=133197)) I managed to get a decent ePub export and started to tweak it with Sigil. There are many small problems with the formatting, but the biggest problem is that the smallcaps are doing weird things that I don't understand at all. Specially in Sigil. I will show you the CSS and an example from one of the xhtml file—my question is simple: how can the text be shown as smallcaps in this situation?

The xhtml file looks like this, in the <body> tag there is:

<h1 class="titre-chapitre" id="toc-anchor">Chapter Title</h1>

<p class="premier-para">First paragraph, which appears correctly in Sigil (no small caps).</p>


<p class="para">Second paragraph (3 lines of text), which appears ALL in smallcaps except the third line.</p>


<p class="dernier-para">Last paragraph of the section, 2 lines of which the first is in smallcaps and the second one is not.</p>

I did 3 separate paragraph classes to get no indent on first line, and to get some space after the last line because there are some sub-sections in chapters. Here is the CSS for the 4 items shown in my example:

h1.titre-chapitre {
font-weight: normal;
font-style: normal;
font-size: 1.21em;
line-height: 1.28em;
text-indent: 0em;
text-align: center;
margin: 2em 0em 4em 0em;
}
p.premier-para {
font-weight: normal;
font-style: normal;
font-variant: normal;
font-size: 0.88em;
line-height: 1.38em;
text-indent: 0em;
text-align: justify;
margin: 0em;
}
p.para {
font-weight: normal;
font-style: normal;
font-variant: normal;
font-size: 0.88em;
line-height: 1.38em;
text-indent: 1.43em;
text-align: justify;
margin: 0em;
}
p.dernier-para {
font-weight: normal;
font-style: normal;
font-variant: normal;
font-size: 0.88em;
line-height: 1.38em;
text-indent: 1.43em;
text-align: justify;
margin: 0em 0em 2.29em 0em;
}

And the smallcaps problem is really related to the text lines, because when I scale the Sigil window the smallcaps parts change. For example, when I maximize the window, those 3 small paragraphs only have 1 line and it is not in small caps. Actually, when maximized, every paragraph that is shorter than one full line isn't shown in smallcaps... I don't understand why it is doing this at all. Any idea?

Also, the smallcaps don't appear in ADE (but I think that is just because it doesn't support smallcaps or something), and they appear almost correctly in Firefox...

Last weird thing with this particular ePub: when I open it in Sigil on my Mac, scrolling in a xhtml file is very very laggy. It's not doing this on my PC—and my PC is considerably older and slower than my new Macbook Pro. Did someone else experienced something similar with Sigil on different platforms with same file? And no problem with other ePub so I'm wondering what is wrong with this one (my first created with InDesign).

Thanks again for your help,

Michael

Adjust
05-30-2011, 08:08 PM
Edit...misread post
InDesign isn't the problem. I'm guessing it's a funny display thing with Sigil.

I get a similar issue with ADE on OSX, (sans-serif displaying instead of serif, that type of thing)...

Try closing all your open fonts
Trash the Sigil preferences and see if that fixes your problem

JSWolf
05-30-2011, 08:36 PM
h1.titre-chapitre {
font-weight: bold;
font-size: x-large;
text-indent: 0;
text-align: center;
margin-top: 30px;
margin-bottom: 30px;
margin-left: 0;
margin-right: 0
}
p.premier-para {
text-indent: 0;
text-align: justify;
margin-top: 0;
margin-bottom: 0;
margin-left: 0;
margin-right: 0
}
p.para {
text-indent: 1.2em;
text-align: justify;
margin-top: 0;
margin-bottom: 0;
margin-left: 0;
margin-right: 0
}
p.dernier-para {
text-indent: 1.2em;
text-align: justify;
margin-top: o
margin-bottom: 20px;
margin-left: 0;
margin-right: 0
}

Try this CSS. The CSS you had was not all that good. This one is a lot nicer.

Adjust
05-30-2011, 09:12 PM
What he had is what comes out of InDesign.

There wasn't anything wrong with his original CSS.

Nothing that would make small caps to appear .i.e
font-variant: small-caps;

mtrahan
05-31-2011, 10:57 AM
It indeed was a "funny display thing" with Sigil. I don't know exactly what "fixed" it, but text went back to normal display while I was playing with something that seemed unrelated in the CSS (an element unrelated to those I posted). I just hope that it really isn't a problem with the ePub—I would hate to see the text appears all in smallcaps on certain e-readers.

That said, since JSWolf cleaned my CSS, I have a couple questions on the subject. First, I see that "line-height" attribute was removed: is it because this element isn't really used by e-readers? I was thinking of removing it but wasn't sure.

I see that "font-size: normal" and "font-variant: normal" (I let that one there thinking that it could help avoid smallcaps) were removed. And the font-size of the <h1> element declared with "x-large" value instead of em: why is it better to do this?

Also is there an advantage to declaring the 4 margins separately instead of all on same line?

And, last question about css, why declaring the margins in pixels instead of em?

Now that I'm getting "better" with my InDesign/ePub workflow, I guess I'll spend a couple of hours watching the CSS training on Lynda.com.

Thanks a lot for your help and advices.

DiapDealer
05-31-2011, 12:44 PM
And, last question about css, why declaring the margins in pixels instead of em?
If you want margins, spacing and/or indents to scale when different font sizes are chosen by users, you probably want to use em. Pixel specified margins will stay the same regardless of font-size. For generic paragraph top/bottom margins, I tend to go with em, but I may use pixels with chapter header margin-tops for consistency.

Jellby
05-31-2011, 01:04 PM
First, I see that "line-height" attribute was removed: is it because this element isn't really used by e-readers?

I'd say it's because it's too font-specific and, unless you want some special effect, it's better to leave it alone.

I see that "font-size: normal" and "font-variant: normal" (I let that one there thinking that it could help avoid smallcaps) were removed.

Those are often redundant, unless you have to override some previous (or default) setting.

And the font-size of the <h1> element declared with "x-large" value instead of em: why is it better to do this?

x-large is an absolute size (reader dependent), while ems are relative. I guess for your case ems are better. I prefer percents, though (2em = 200%)

Also is there an advantage to declaring the 4 margins separately instead of all on same line?

None that I know.

And, last question about css, why declaring the margins in pixels instead of em?

Pixels are absolute, again, and do not change when you change the global font size in the reader. Depending on where the particular margin applies, you may want one or the other.

mtrahan
05-31-2011, 01:27 PM
You guys rock! Thanks again—much appreciated.

JSWolf
05-31-2011, 07:41 PM
What he had is what comes out of InDesign.

There wasn't anything wrong with his original CSS.

Nothing that would make small caps to appear .i.e
font-variant: small-caps;

There is a lot wrong with the CSS. font-variant: small-caps; doesn't work in ADE. But what the problem is is that all three of the styles in the CSS have font-size: 0.88em; The CSS as posted here was a mess. I've just fixed the initial problem and cleaned up the mess.

JSWolf
05-31-2011, 07:43 PM
You guys rock! Thanks again—much appreciated.

Happy to help.

As for the reason for the separate margins, I just find it's easier to read.

As far as the font size in the h1 CSS entry, I really should have removed that line and let h1 be it's default size. And if h1 is too large, change it to h2 and change it to h2 in the CSS as well.

Adjust
05-31-2011, 08:06 PM
There is a lot wrong with the CSS.
His original CSS is what InDesign generates, there's nothing wrong with it, it validates fine

font-variant: small-caps; doesn't work in ADE.
I know that's why I used it as an example. (btw it does work in iBooks)
But what the problem is is that all three of the styles in the CSS have font-size: 0.88em;
That's not a problem, all mine have that. It's so I change font sizes around to suit my design.

I've just fixed the initial problem and cleaned up the mess.

But there wasn't an initial problem, it was a display problem.

mtrahan
05-31-2011, 09:53 PM
I know that's why I used it [smallcaps] as an example. (btw it does work in iBooks)


So far I can't say smallcaps works perfectly fine for me in iBooks. Actually, the only smallcaps that work right now are the one declared in the HTML elements tags directly... I don't understand why. By that I mean that for example my p.chaptertitle, h1.title classes with "font-variant: small-caps;" in the CSS work, but I also have a separate span class declared like this in the stylesheet:

span.smallcaps {
font-variant: small-caps;
}

...and it doesn't work. For example, at the beginning of first paragraph, when I do <span class="smallcaps">First words</span> it has no effect in iBooks.

And at the time of writing this I checked the same file in the Calibre viewer and it only accepted my h1.title smallcaps, not even the small caps declared in p.chaptertitle.

Small caps is the most mysterious part of the formatting so far... There was also a mysterious problem with "text-align" in iBooks, but thanks to Liz Castro's blog (http://www.pigsgourdsandwikis.com/2010/06/beating-ibooks-bugs.html) I fixed the problem by adding <span> and </span> inside the element I want to align differently.

JSWolf
05-31-2011, 09:57 PM
His original CSS is what InDesign generates, there's nothing wrong with it, it validates fine

Validates and works well can be two different things and in this case, there were issues with the CSS that needed to be fixed.

I know that's why I used it as an example. (btw it does work in iBooks)

Smallcaps is not supported in ePub and iBooks does a lot of things non-standard like smallcaps.

That's not a problem, all mine have that. It's so I change font sizes around to suit my design.

It was a problem for the OP.

But there wasn't an initial problem, it was a display problem.

A display problem caused by the CSS.

Adjust
05-31-2011, 10:00 PM
Small caps is the most mysterious part of the formatting so far... There was also a mysterious problem with "text-align" in iBooks, but thanks to Liz Castro's blog (http://www.pigsgourdsandwikis.com/2010/06/beating-ibooks-bugs.html) I fixed the problem by adding <span> and </span> inside the element I want to align differently.

Yeah I know, it's painful, that's why I fake it:
http://www.mobileread.com/forums/showpost.php?p=1552845&postcount=3

Validates and works well can be two different things and in this case, there were issues with the CSS that needed to be fixed.
Smallcaps is not supported in ePub and iBooks does a lot of things non-standard like smallcaps.
It was a problem for the OP.
A display problem caused by the CSS.

Ok, it appears we're not understanding each other And so I'll leave it at that. :chinscratch:

Jellby
06-01-2011, 05:14 AM
Smallcaps is not supported in ePub and iBooks does a lot of things non-standard like smallcaps.

No, smallcaps is supported in ePUB all right , it's only ADE who does not support them (or, at least, it does not "fake" them if a true smallcaps font does not exist, which is often the case). Don't blame ePUB for ADE's faults.

JSWolf
06-01-2011, 10:24 AM
Yeah I know, it's painful, that's why I fake it:
http://www.mobileread.com/forums/showpost.php?p=1552845&postcount=3

I do prefer proper smallcaps. But the problem is then that I have to change the case of all the smallcaps in the ePub as in order to fake it, the publisher uses uppercase.

Ok, it appears we're not understanding each other And so I'll leave it at that. :chinscratch:

Did you read the comments in the XML code the OP posted? When he said smallcaps, it's not that he got smallcaps. It's that the fontsize was set to be about the size of smallcaps.