Previewer 3 removing custom font from some headings

[jcsalomon]

My CSS sets <h1> headers to use an embedded font. The file works okay when converted from EPUB to MOBI via Kindlegen in both Kindle for Windows and Kindle Previewer 2.94 (and in EPUB readers), and almost works in Previewer 3.12—except the <h1> tags used for chapter headers display in the default font.

I’ve attached a boiled-down version of my file. Can anyone point me to what I’m doing wrong?

[Doitsu]

This is most likely a Kindle Previewer 3 bug, because when I converted your test file to a KFX file with the Calibre KFX Output plugin, the generated .kfx file displayed fine on my Kindle Paperwhite 2.

[jhowell]

It appears that you have discovered a bug in Kindle Previewer 3. When it converts your test book to KFX format for enhanced typesetting it puts the wrong font family name in the heading style.

Doing some trial and error testing I found that eliminating the "first-line" selector from your stylesheet prevents the problem. It seems to trigger the bug somehow, even though it isn't being used on the problem content. Very strange.

[Doitsu]

Originally Posted by jhowell

Doing some trial and error testing I found that eliminating the "first-line" selector from your stylesheet prevents the problem. It seems to trigger the bug somehow, even though it isn't being used on the problem content. Very strange.

BTW, according to page 83 of the Kindle Publishing Guidelines, the first-line selector isn't officially supported anyway, even though Webkit displays it (and many other unsupported pseudo selectors) just fine.

[jcsalomon]

Originally Posted by jhowell

It appears that you have discovered a bug in Kindle Previewer 3. When it converts your test book to KFX format for enhanced typesetting it puts the wrong font family name in the heading style.

Doing some trial and error testing I found that eliminating the "first-line" selector from your stylesheet prevents the problem. It seems to trigger the bug somehow, even though it isn't being used on the problem content. Very strange.

Of course, I have no idea whether Amazon’s own conversion routines have the same bug, so…

BTW, how were you able to examine the KFX file?

Originally Posted by Doitsu

BTW, according to page 83 of the Kindle Publishing Guidelines, the first-line selector isn't officially supported anyway, even though Webkit displays it (and many other unsupported pseudo selectors) just fine.

Thanks; I never noticed that. I’d tested the earlier version of the book (the released version, without the custom fonts) and the first-line selector worked fine on my Kindle Fire HD—but I guess that’s using Webkit under the hood?

Time to talk to the customer about trade-offs. Shame; I was hoping this would be an easy addition, and make the e-books look just that little bit more like the print versions.

[jhowell]

To pursue this problem a bit more I fed a collection of EPUBs that I keep for testing through the kfxgen app of Previewer 3 and checked the output for the same type of font problem. I found two books that exhibit the same error. One uses the first-line selector, but the other doesn't so the actual trigger for this problem is still not clear.

Originally Posted by jcsalomon

BTW, how were you able to examine the KFX file?

I have been looking into the workings of KFX since it first appeared and have some hacked together tools for examining content, nothing in a state to be shared at the moment.


A little detail on what is going wrong:

During conversion to KFX a prefix is added to the names of any fonts embedded in the book. Each book gets a different prefix. (I don't know why, possibly to keep embedded fonts separate from system fonts.) The same prefix is added to the font definition and to each reference to it within the book. Fonts that are called out in the book, but not embedded, do not get a prefix added.

In the case of your book the prefix is added to the font definition and to most references, but some references are left unprefixed and so end up calling for a non-existent font.

[jcsalomon]

Originally Posted by jhowell

I have been looking into the workings of KFX since it first appeared and have some hacked together tools for examining content, nothing in a state to be shared at the moment.

In a GitHub project-not-to-be-mentioned-here, I see someone’s been able to unpack a KFX file into Amazon’s Ion format, but I have not yet seen what such an unpacking looks like.

Originally Posted by jhowell

During conversion to KFX a prefix is added to the names of any fonts embedded in the book. Each book gets a different prefix. […] The same prefix is added to the font definition and to each reference to it within the book. Fonts that are called out in the book, but not embedded, do not get a prefix added.

In the case of your book the prefix is added to the font definition and to most references, but some references are left unprefixed and so end up calling for a non-existent font.

Is the Ion format doing the effective equivalent of inlining CSS?

[jhowell]

Originally Posted by jcsalomon

Is the Ion format doing the effective equivalent of inlining CSS?

KFX conversion flattens CSS and places some properties in with the data content and collects others into styles. Information that isn't relevant to how the content is rendered is discarded. The end result bears little resemblance to the original HTML/CSS.

Originally Posted by jcsalomon

In a GitHub project-not-to-be-mentioned-here, I see someone’s been able to unpack a KFX file into Amazon’s Ion format, but I have not yet seen what such an unpacking looks like.

I have been paying attention to that also. It seems that progress has been made on the removal of KFX DRM.

The conversion of non-DRM KFX content to a readable format has been possible for a while. Amazon published documentation for Ion along with reference implementations in various programming languages. For example, here is the first chapter from the sample you posted converted to KFX by Previewer 3 and then converted to readable Ion text format:

Spoiler:

storyline:: r5H_7jrET6avxAzBN02vWw29:: {
  story_name: r5H_7jrET6avxAzBN02vWw29,
  content_list: [
    {
      id: 12,
      style: r5H_7jrET6avxAzBN02vWw41,
      type: text,
      content_list: [
        {
          id: 13,
          style: r5H_7jrET6avxAzBN02vWw31,
          type: text,
          content: "Chapter One:\nThe First Chapter",
        },
        {
          id: 14,
          style: r5H_7jrET6avxAzBN02vWw33,
          'yj.first_line_style': {
            'yj.first_line_style_type': {
              'yj.number_of_lines': 1,
            },
            style_name: r5H_7jrET6avxAzBN02vWw34,
          },
          type: text,
          content: "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam ut diam vel massa ornare venenatis id id orci. Donec vel suscipit lacus. Aliquam erat volutpat. Sed gravida at lectus ut eleifend. Integer lacus felis, vehicula ac placerat at, ultricies sed massa. Mauris non ligula ut nisi pretium eleifend non sit amet ex. In rutrum est vel nibh ultrices varius.",
        },
        {
          id: 15,
          style: r5H_7jrET6avxAzBN02vWw36,
          type: text,
          content: "Nulla cursus ac quam bibendum porta. Morbi viverra, sem non venenatis porttitor, justo quam egestas magna, quis efficitur nisl mauris non orci. Vestibulum at justo eros. Cras porttitor vel arcu sed fermentum. Maecenas gravida, purus aliquam commodo aliquet, nibh dolor pharetra lorem, nec aliquam erat orci sed neque. Quisque pulvinar sollicitudin suscipit. Integer non ante vitae felis laoreet efficitur sed id sem. Duis consectetur viverra urna, at placerat ex imperdiet eu. Nulla venenatis elementum est quis ullamcorper. Nam vel malesuada tellus, ac dictum leo. Donec pellentesque ullamcorper nibh, vitae vulputate nulla dapibus non. Vestibulum volutpat, nisi non pretium facilisis, tortor lorem consequat velit, sit amet interdum est felis vehicula orci.",
        },
        {
          id: 16,
          style: r5H_7jrET6avxAzBN02vWw36,
          type: text,
          content: "Nullam laoreet purus ligula, ac porta nulla tristique quis. Sed a ante nec diam scelerisque fringilla sed et sapien. Proin viverra condimentum nisi ullamcorper dignissim. Cras vel velit id nunc laoreet lobortis. Integer turpis velit, dignissim in nibh ac, sodales finibus metus. Nunc rhoncus eget est ut auctor. Maecenas at pharetra mauris, et suscipit magna. Phasellus hendrerit id dui porta porttitor. Quisque sapien lectus, fringilla et elit mattis, efficitur sollicitudin mauris. Integer ultricies orci vitae nulla hendrerit, at eleifend mi blandit. Integer tincidunt urna eu erat interdum, a iaculis ante rhoncus. Morbi ac gravida velit. Pellentesque et pellentesque tellus, at malesuada lectus. Aliquam hendrerit, tortor eu efficitur scelerisque, ligula purus pellentesque nulla, nec sagittis metus leo nec sem.",
        },
        {
          id: 17,
          style: r5H_7jrET6avxAzBN02vWw36,
          type: text,
          content: "Mauris auctor urna non tristique bibendum. Integer quis turpis lacus. Aenean ultricies nisl risus, laoreet malesuada justo imperdiet eget. Duis porta risus elit, consequat porttitor purus euismod ut. Maecenas euismod lorem eu volutpat vulputate. Proin et massa sed leo vestibulum eleifend. Nam sit amet justo rutrum, porttitor magna in, sagittis quam.",
        },
        {
          id: 18,
          style: r5H_7jrET6avxAzBN02vWw36,
          type: text,
          content: "Nam cursus sem et urna pulvinar, vehicula vehicula lectus mattis. Aenean euismod turpis sapien, vitae tempus dui suscipit vitae. Fusce nec risus vel tortor facilisis suscipit id ut leo. Donec ut velit mi. Ut quis tempus erat. Maecenas sit amet aliquet urna, eget ullamcorper enim. Duis eget augue turpis. Aliquam leo risus, bibendum a aliquet sit amet, varius sit amet nisi. Praesent tincidunt ex a dui rhoncus, non tristique metus mollis. Sed non hendrerit ligula.",
        },
      ],
    },
  ],
}

style:: r5H_7jrET6avxAzBN02vWw31:: {
  letterspacing: {
    value: 0.1,
    unit: em,
  },
  font_size: {
    value: 2.,
    unit: rem,
  },
  margin_bottom: {
    value: 0.416667,
    unit: lh,
  },
  text_alignment: center,
  text_indent: {
    value: 0.,
    unit: em,
  },
  line_height: {
    value: 1.,
    unit: lh,
  },
  font_family: "rm ginger",
  style_name: r5H_7jrET6avxAzBN02vWw31,
  font_weight: normal,
}

style:: r5H_7jrET6avxAzBN02vWw33:: {
  font_size: {
    value: 1.,
    unit: rem,
  },
  line_height: {
    value: 1.,
    unit: lh,
  },
  text_alignment: justify,
  font_family: "default",
  text_indent: {
    value: 0.,
    unit: em,
  },
  style_name: r5H_7jrET6avxAzBN02vWw33,
}

style:: r5H_7jrET6avxAzBN02vWw34:: {
  style_name: r5H_7jrET6avxAzBN02vWw34,
  font_weight: bold,
  glyph_transform: small_caps,
}

style:: r5H_7jrET6avxAzBN02vWw36:: {
  font_size: {
    value: 1.,
    unit: rem,
  },
  line_height: {
    value: 1.,
    unit: lh,
  },
  text_alignment: justify,
  font_family: "default",
  text_indent: {
    value: 2.,
    unit: em,
  },
  style_name: r5H_7jrET6avxAzBN02vWw36,
}

style:: r5H_7jrET6avxAzBN02vWw41:: {
  font_size: {
    value: 1.,
    unit: rem,
  },
  line_height: {
    value: 1.,
    unit: lh,
  },
  text_indent: {
    value: 0.,
    unit: em,
  },
  style_name: r5H_7jrET6avxAzBN02vWw41,
  min_height: {
    value: 100.,
    unit: percent,
  },
  margin_top: {
    value: 0.833333,
    unit: lh,
  },
}

[Notjohn]

Boggles the mind!

(I am giving up and heading for the couch to read a Philip Kerr thriller ... in print!)

[JSWolf]

I still think that Amazon created KFX for the sole purpose of preventing DRM removal and conversion to other formats like can be done with KF8. Adobe can do all the "enhanced" typesetting with ePub as is. There's no reason Amazon could not have done the same thing with the KF8 renderer.

[jcsalomon]

Reported as a Previewer bug to Amazon; they say,

Our technical team has started working on this.

We will get back to you with a solution or with intermediate updates.

(They may well suggest to drop the E::first-line code, of course, or perhaps ask John for his other bug-triggering example.)

[jhowell]

Originally Posted by jcsalomon

Reported as a Previewer bug to Amazon; they say,(They may well suggest to drop the E::first-line code, of course, or perhaps ask John for his other bug-triggering example.)

I looked at the other example and found that it uses a ::after selector in the CSS. Removing that prevents the font problem.

[jcsalomon]

Originally Posted by Amazon Customer Service

Thank you for your patience.

We are happy to say that your issue got fixed.

Now you can preview your embedded fonts in latest kindle previewer 3 without any issue.

Downloaded Kindle Previewer 3.17.1 and tried it on my test file, and the bug does seem to have been fixed. JHowell, how about your test book?

(I meanwhile avoided the bug by including a title page built with SVG, which—for now—disables “enhanced typesetting”.)

[jhowell]

Originally Posted by jcsalomon

Downloaded Kindle Previewer 3.17.1 and tried it on my test file, and the bug does seem to have been fixed. JHowell, how about your test book?

I noticed that your file and some others I found that exhibit the problem started converting properly as of Previewer version 3.17.0.

I have two other files that continue to have the problem even with the latest Previewer version. So it appears that there is still at least one more variant of the bug remaining.


Update: I rechecked the two books that still fail and found that in those cases there are actually missing font files. So it looks like the bug is completely fixed.