Log in / Register

Forum › How do I...?

How do I find where the Times fallback font is used?

_savage
In my CSS file I've specified the use of a TeX Gyre font, like so:
@font-face {
  font-family: textfont;
  src: url("/path/to/fonts/texgyretermes-regular.otf");
}
@font-face {
  font-family: textfont;
  font-style: italic;
  src: url("/path/to/fonts/texgyretermes-italic.otf");
}

...

and yet, when I build the document with Prince, I get this output:
prince: Converting document...
prince: used font: TeX Gyre Termes, Regular
prince: used font: Times New Roman, Italic
prince: used font: TeX Gyre Termes, Bold
prince: loading hyphenation patterns: /opt/lib/prince/style/../hyph/hyph-en-us.pat
prince: used font: TeX Gyre Termes, Italic

What's going wrong here, why the use of Times there? How can I find out where that comes from, what text passage causes this?
mikeday
Personally I check by generating the PDF with compression disabled, and then opening it in a text editor to see which page is referencing the font. But there must be a smarter way of doing this, perhaps with Acrobat Pro?
_savage
Thanks Mike! That does sound rather tedious, but it's also a nice exercise to acquaint myself with PDF internals. I think I've tracked it down, and now I'm stuck deciphering the Tj command. So I've posted a question on stackoverflow.com if you'd like to take a look.

After some noodling around with the PDF and a good answer to my question above it turns out that the Times font is used to render the headers of the page, where I did not explicitly specify the font family property:
@page {
  ...

  @top {
    font-family: texgyre; /* Added explicit font family to override Times default font use. */
    font-style: italic;
    color: grey;
  }

  ...
}

The above change gets rid of the use of any Times font in the generated PDF document.

Edited by _savage

mikeday
Good catch! And a nice dive into PDF internals. :)
_savage
Heh :) Kept me up late at night.

It also made me wonder: if I would set the font-family property for the <body>, would that cover all font uses of a document?
mikeday
As it happens, no. You could argue that the font settings on the root element should be inherited by @page rules, but even then that would not help the body element. It doesn't quite feel right though, does it.
_savage
Hm.. bummer. I agree though, it's a little unexpected. Back to sprinkling explicit CSS everywhere then :)

Edited by _savage

mikeday
Maybe we need the concept of something above the root element, that the document and its @page rules would inherit from. Or just a way of defining font defaults. I mean, you can redefine serif itself with an @font-face rule, but that's a heavyweight mechanism for this.
_savage
I guess there is a finer difference between "cascading" and "inheriting" properties, see here. But there's also the lexical order that has effects on how properties cascade down, and then there's the HTML aspect of it to.

So looking at it from a purist programming language point of view probably doesn't get me too far.
dauwhe
The latest CSS Page draft (http://dev.w3.org/csswg/css-page/#margin-boxes) does seem to clarify this point:

page-margin boxes inherit from the page context. The page context inherits from the root element. However, since the previous revision of CSS Paged Media Level 3 did not specify this point, an implementation that sets inherited properties in the page context to their initial values (as for the root element) is also conformant to CSS Paged Media Level 3. Note that this exception will be removed in Level 4.


Just don't go look at the spec today, as CSS has been used for evil on April Fool's Day.

Dave
mikeday
Evil indeed! A glimpse into a world where CSS never happened. :)

But the idea of @page inheriting from the root element does make some sense, and can reduce the number of duplicated rules.