'Nuther N00Bie Question

[JustinThought]

I have a question regarding a test epub I created. I was interested in using embedded fonts, and found I could catch all the fish in the Atlantic Ocean with the can of worms that I opened.

First off, I declared the font as such:

@font-face {
font-family: "jour-nal";
font-style: normal;
src: url(../Fonts/blahblahblah.ttf);
}
.journal {
font-family: jour-nal;
font-size: .95em;
}

Then I used the "journal" class in a <div>, and all seemed to be okay--at least in Sigil and Gitden Reader, and also (somewhat) in Calibre. It also verified fine in both FlightCrew as well as EpubCheck.

Now, Calibre didn't like me giving the font-family a name other than the name embedded in the font, and offered to change it; but it wanted to use the same name for the embedded bold font as well as the italic version. So anyway, after checking with W3Cschools, whose example of an embedded font clearly illustrates a font-family name different from the embedded font, I left it alone for now.

Calibre also had a different opinion about the nomenclature in the OPF file, saying,

"The file OEBPS/Fonts/blahblahblah.ttf has its mimetype specified as application/x-font-ttf in the OPF file. The recommended mimetype for files with the extension "ttf" is application/x-font-truetype. You should change either the file extension or the mimetype in the OPF.

Change the mimetype for this file in the OPF to application/x-font-truetype"

So if I make the change, then re-run FlightCrew on the modified file, it says just the opposite:

The element's "media-type" attribute has value of "application/x-font-truetype" but the file's media type is "application/x-font-ttf"

Difference of opinion, or fatal error?

Then, I decided to go out to W3C and ask their opinion. Whoop-whoop-whoop! Danger Will Robinson! "Property font-family doesn't exist in CSS level 2.1 but exists in [css1, css2, css3]".

So I ran the verification check in W3C using the direct upload method from their main webpage--and life came back as rainbows and unicorns. Of course, that validated at CSS level 3, whereas running the check from within Sigil checked it at CSS level 2.1.

Should I just take my bat and ball and go home, never ever again attempting to create a book with any tool more sophisticated than a quill pen?

Toldja it was a N00B question. Thanks for your input, and please be gentle.

[DiapDealer]

Welcome to the jungle young paduan.

For what it's worth: I buy commercial epubs all the time that run afoul of Flightcrew/IDPF's font-extension/mimetype catch-22. At some point, the bottom line is to use what works most consistently on as many platforms as you can afford to physically test on.

The other piece of advice I would give is to just not use embedded fonts unless it was absolutely necessary to ensure that all characters/glyphs needed for your book render properly. In other words: if it's not a question of special characters being required, then let the ereader (or app) choose the font to use based on your suggestions (that include generic fallbacks) rather than embedding fonts and forcing the issue.

[theducks]

the font family can have the same name
it is the other attributes that must match the usage

font-weight: bold ; usage has a matching @font with the Bold

So, typically, you could have 4 @fonts with the same family,1 for each font style (combination)

[JustinThought]

Originally Posted by theducks

the font family can have the same name
it is the other attributes that must mat ch the usage

font-weight: bold ; usage has a matching @font with the Bold

So, typically, you could have 4 @fonts with the same family,1 for each font style (combination)

Thanks. But no penalty for using a different name, right? Example, I declared the family

@font-face {
font-family: "jour-nal";
font-style: normal;
src: url(../Fonts/myfont-r.ttf);
}
then established a class for that font and style--
.journal {
font-family: jour-nal;
font-size: .95em;
}

(I also made a separate class--

div.journal p {
font-family: jour-nal;
margin-bottom:.55em;
text-indent: .8em;
text-align:justify;
}

to support the container. Possibly redundant, but it gave me a little flexibility on formatting the paragraphs by defining p + p with other attributes in some cases.)

after that, I repeated the process for the italic version--
@font-face {
font-family: "jour-nal-i";
font-style: italic;
src: url(../Fonts/myfont-i.ttf);
}
.journal-i {
font-family: jour-nal-i;
font-size: .95em;
}

and again for the bold.

Not surprisingly, I used that name because I was using the font to reproduce a journal entry, hence the mnemonic name.

--Oh, and that brings up another experiment I tried, which seemed to be effective. I placed that journal entry into a <div class="journal"> container, and when I needed an italic (or bold), I called it thus:

<p>Blah blah, te-dah he haw, and <em class="journal-i">itsibu</em> something else.</p>

--with the same procedure for the bold, using <strong class="journal-b"> instead. My logic here (if such a strong word can be used) was that even if the reader doesn't support the embedded font, it would hopefully still display in italic or bold.

Maybe this is all wet, but this whole procedure evolved from hints I've gotten from the WORKSHOP section here on MobilRead, as well as from reviewing some of the commercial e-books I have.

If it is really messed up, or unnecessary, I'm one of those people who learns best from the second part of "trial-and-error."

[theducks]

I think your issue is you are trying to force the font style in the @font, rather than USE a style and or weight in the "class"

The default, unless specified: is normal

if you want Bold: font-weight: bold, if you want italic: font-style: italic;

font-family only sets the family (members)

BTW My Kindle requires the FONT (internal Metrics) be correct for style and weight. Simply substituting a heavy (normal) font for Bold in the @font , 'no work'

[JustinThought]

Thank you--again! I always appreciate your help.

[DiapDealer]

To summarize:

The font-family attribute should be identical in each of the @font-face declarations for all of the font-style variants for a particular font. And because of that, there's no good reason why the font-family attribute shouldn't match the font's internal name (since doing so will guarantee functionality on fringe device/apps, or fringe fonts--with zero downside for doing it).

It's the url attribute that should point to distinctly separate files (blahblahblah-normal.ttf, blahblahblah-ital.ttf, blahblahblah-bold.ttf, blahblahblah-bolditalic.ttf, blahblahblah-smallcaps.ttf, etc...)

Out of curiosity; what is your rationale for wanting to use something other than the font's internal name for the font-family attribute?

[JustinThought]

Originally Posted by DiapDealer

To summarize:

// snip! //

Out of curiosity; what is your rationale for wanting to use something other than the font's internal name for the font-family attribute?

I'm not dogmatic about it, except I usually try to name anything I declare mnemonically.

In any case, I appreciate all y'alls help. I'm striving toward creation of epubs as error-free as possible.