How to get font size working in ePub? - Page 2

JSWolf · 12-12-2014, 09:23 PM

Quote:

Originally Posted by jackie_w

I use code similar to this all the time. It does work. Are you sure you've actually tried it?

I've done some more testing and I've found out what is going on.

CSS

Code:

p {
margin-top: 0;
margin-left: 0;
margin-right: 0;
margin-left: 0;
text-indent: 1.2em
}
.small {
font-size: 20pt;
}
.text {
font-size: 2em;
}
.f1em {
font-size: 1em;
}
.f2em {
font-size: 2em;
}
.f3em {
font-size: 3em;
}
.f4em {
font-size: 4em;
}
.f5em {
font-size: 5em;
}
.f6em {
font-size: 6em;
}

XML

Code:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
  "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <title>Kobo Font Size Test</title>
  <link href="../Styles/Style0001.css" rel="stylesheet" type="text/css" />
</head>

<body>
  <p>Some text. S<span class="small">OME</span> T<span class="small">EXT</span>. Some <span class="text">more</span> text.</p>

  <p>Some text. S<span class="small">OME</span> T<span class="small">EXT</span>. Some <span class="f1em">more</span> text.</p>

  <p>Some text. S<span class="small">OME</span> T<span class="small">EXT</span>. Some <span class="f2em">more</span> text.</p>

  <p>Some text. S<span class="small">OME</span> T<span class="small">EXT</span>. Some <span class="f3em">more</span> text.</p>

  <p>Some text. S<span class="small">OME</span> T<span class="small">EXT</span>. Some <span class="f4em">more</span> text.</p>

  <p>Some text. S<span class="small">OME</span> T<span class="small">EXT</span>. Some <span class="f5em">more</span> text.</p>

  <p>Some text. S<span class="small">OME</span> T<span class="small">EXT</span>. Some <span class="f6em">more</span> text.</p>

  <p class="f2em">some text. S<span class="small">OME</span> T<span class="small">EXT</span>. Some <span class="f6em">more</span> text.</p>

  <p class="f3em">some text. S<span class="small">OME</span> T<span class="small">EXT</span>. Some <span class="f6em">more</span> text.</p>
</body>
</html>

Now, the span's with the size set as em work fine. Font sizes using pt or px do not work. Hence why SOME TEXT is all the same size as Some text.

DNSB · 12-13-2014, 01:36 AM

Quote:

Originally Posted by JSWolf

But one issue will be pseudo small-caps. A lot of CSS for small caps is specifying a font size of 7em or .8em. Also, I've seen a lot of CSS code that uses .8em instead of small for a font size and if I'm not mistaken, the Kobo will display these CSS styles in the same size as the body font.

The .7 or .75 or .8 would display as that fraction of the default font size. I use that often enough to make the A.M. or P.M. appear as a smaller size for example.

davidfor · 12-13-2014, 01:37 AM

Quote:

Originally Posted by JSWolf

Now, the span's with the size set as em work fine. Font sizes using pt or px do not work. Hence why SOME TEXT is all the same size as Some text.

So, it's working as we all expect it to. Test with relative font sizes are resizing and text with absolute size are not.

Or do you mean something else? You don't actually say what you mean by "work fine" and "do not work", so I have to make an assumption based on the thread.

Jellby · 12-13-2014, 02:52 AM

Jon wants the absolute sizes (in px or pt) to be displayed at the requested fixed size (not changed by the size slider). We all agree this is a bad practice and we don't want to see it in a published book, at least not for anything that's intended to be read. But for testing purposes (and maybe some specific cases) it's perfectly OK.

Since it is so annoying (and probably common) a mistake in books out there, I guess the Kobo firmware is ignoring these absolute sizes, so the font size slider works as expected and fewer users complain.

murg · 12-13-2014, 04:45 PM

Other CSS classes with 0.7em work, as I used to use <span class="smallcaps">text</span>

But I hate spans, so I remove all of them possible.

JSWolf · 12-13-2014, 05:11 PM

Quote:

Originally Posted by murg

Other CSS classes with 0.7em work, as I used to use <span class="smallcaps">text</span>

But I hate spans, so I remove all of them possible.

If there are enough smallcaps, I convert them to real smallcaps and embed a smallcap font to give a much nicer look.

Ripplinger · 12-13-2014, 06:12 PM

I must do small the caps a lazy way, I prefer to not embed any fonts in ebooks to keep size down. I just use all caps at 75% or 80% of the font height and they look perfect to me.

JSWolf · 12-13-2014, 08:34 PM

Quote:

Originally Posted by Ripplinger

I must do small the caps a lazy way, I prefer to not embed any fonts in ebooks to keep size down. I just use all caps at 75% or 80% of the font height and they look perfect to me.

With Sony & Kobo, you can "embed" the fonts without embedding the fonts. That is you can use CSS code to reference fonts on the device.

arspr · 12-14-2014, 01:34 AM

Quote:

Originally Posted by Jellby

Since it is so annoying (and probably common) a mistake in books out there, I guess the Kobo firmware is ignoring these absolute sizes, so the font size slider works as expected and fewer users complain.

I haven't tested the issue yet (I'll do it ASAP) but if it is true (and I don't see any obvious mistake in JSWolf's code) it's clearly ANOTHER BUG no matter how you look at it.

I'm ORDERING the renderer to put whatever font in 18 points, inches or whatever. Period. It must follow that order. Period. I don't think epub/HTML/CSS spec says this is optional, you can do whatever you want.

Maybe in the 99% of the cases it is a publishing error... But I can think of some situations where it isn't (example: you have your text mixed with images and you want an exact size relationship).

If Kobo considers it is usually a bug they want to filter out, what they should have done is adding somewhere an option about "ignore absolute font sizes" or something like that so the user has full control over the device behaviour. I accept even that option being ON by default...

It's the same with widows and orphans, page-breaks or @page. You cannot just ignore these settings because of whatever reason (even if you hate widows and orphans working...) while you say you are epub2/3 compatible...

[Joke mode]
What is the next decision? That if the user tries to open "Fifty shades of Grey" the eReader opens "Romeo and Juliet" instead because it considers that the first one is rubbish?
[/Joke mode]

Nevertheless I suppose this issue would be like what I posted here about absolute measures being FUBAR in ACCESS while testing Jellby's test book:

Quote:

cm absolute measure unit is FUBAR in both systems (at least in my H2O) but is much more FUBAR in ACCESS (5 cm rendered as 1.8 cm) than in RMSDK (5 cm rendered as 4.4 cm).

Jellby · 12-14-2014, 02:59 AM

Quote:

Originally Posted by arspr

while you say you are epub2/3 compatible...

I don't think any reader says that. At most they say they can display epub files, no mention of version (unless it's 3, maybe), nothing about compatibility (I'd be wary of a reader advertised as "epub compatible" anyway) or much less spec compliance...

murg · 12-14-2014, 07:26 AM

Quote:

Originally Posted by arspr

I'm ORDERING the renderer to put whatever font in 18 points, inches or whatever. Period. It must follow that order. Period. I don't think epub/HTML/CSS spec says this is optional, you can do whatever you want.

Actually, you aren't ordering anything. You're suggesting.

The css has no idea how large the screen is. Yeah, I know we all think that being a device, it would know how big the screen is.

In the real world, the font gets displayed in an approximate height. Many, many factors can affect the sizing.

JSWolf · 12-14-2014, 09:21 AM

But in this case, RMDSK completely ignores pt and px as font sizes. It works with em, but that's it (as far as I know). The patch for the font size slider uses pt and I was trying to create an ePub to show me the various pt sizes so I could decide what the first 4 sizes I wanted. Now the only way to test this is to put in different numbers for the patch and test it via the font slider. That's not what I wanted to do.

arspr · 12-14-2014, 09:47 AM

Well I can fully confirm the issue in kepubs/ACCESS. I'm updating Jellby's test book with some extra tests about it.

Quote:

Originally Posted by murg

The css has no idea how large the screen is. Yeah, I know we all think that being a device, it would know how big the screen is.

In the real world, the font gets displayed in an approximate height. Many, many factors can affect the sizing.

You are answering yourself. I could admit that a general Firefox, IE or Chrome didn't know the screen size they are attached to. But here you have an unique device so, yes, you should know its size both in pixels and in length units. If you are not accurate is because you are a lazy coder...

But nevertheless supposing that the screen size is not known because of I don't know which reason, px, pt, in or cm are still absolute measure units. So if you change their chosen layout (whichever you've selected) with the internal font size setting, you're doing it wrong... (unless you do it because of a user selected option).

arspr · 12-14-2014, 05:00 PM

Well it really seems that both RMSDK and ACCESS don't properly handle absolute font sizes.

If you feel like it, I've uploaded an updated version of Jellby's test book in his dedicated thread.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
CSS not working (specifically bold & font size)	kaonevar	Editor	10	10-10-2014 12:47 AM
Epub > Epub conversion changes font size.. why?	OllieDixon	Conversion	2	03-31-2014 02:30 AM
Determine font and font size on incoming epub?	peaceridge	Calibre	4	01-30-2012 03:35 PM
More on working around the font-size issue	billingd	Kobo Reader	13	06-25-2010 08:49 PM
Base Font Size not Working	Colaveare	Calibre	0	05-06-2009 02:09 AM

12-13-2014, 02:52 AM	#19
Jellby frumious Bandersnatch Posts: 7,554 Karma: 19500001 Join Date: Jan 2008 Location: Spaniard in Sweden Device: Cybook Orizon, Kobo Aura	Jon wants the absolute sizes (in px or pt) to be displayed at the requested fixed size (not changed by the size slider). We all agree this is a bad practice and we don't want to see it in a published book, at least not for anything that's intended to be read. But for testing purposes (and maybe some specific cases) it's perfectly OK. Since it is so annoying (and probably common) a mistake in books out there, I guess the Kobo firmware is ignoring these absolute sizes, so the font size slider works as expected and fewer users complain.

12-13-2014, 04:45 PM	#20
murg No Comment Posts: 3,240 Karma: 23878043 Join Date: Jan 2012 Location: Australia Device: Kobo: Not just an eReader, it's an adventure!	Other CSS classes with 0.7em work, as I used to use <span class="smallcaps">text</span> But I hate spans, so I remove all of them possible.

12-13-2014, 06:12 PM	#22
Ripplinger 350 Hoarder Posts: 3,574 Karma: 8281267 Join Date: Dec 2010 Location: Midwest USA Device: Sony PRS-350, Kobo Glo & Glo HD, PW2	I must do small the caps a lazy way, I prefer to not embed any fonts in ebooks to keep size down. I just use all caps at 75% or 80% of the font height and they look perfect to me.

12-14-2014, 09:21 AM	#27
JSWolf Resident Curmudgeon Posts: 79,798 Karma: 146391129 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	But in this case, RMDSK completely ignores pt and px as font sizes. It works with em, but that's it (as far as I know). The patch for the font size slider uses pt and I was trying to create an ePub to show me the various pt sizes so I could decide what the first 4 sizes I wanted. Now the only way to test this is to put in different numbers for the patch and test it via the font slider. That's not what I wanted to do.

12-14-2014, 05:00 PM	#29
arspr Dead account. Bye Posts: 587 Karma: 668244 Join Date: Mar 2011 Device: none	Well it really seems that both RMSDK and ACCESS don't properly handle absolute font sizes. If you feel like it, I've uploaded an updated version of Jellby's test book in his dedicated thread.

Advert

Advert