MWEs don't get much more minimal than this:

This is \emph{very} strange


You can compile it using tex4ebook, but htlatex example.tex xhtml has the same result: if you run the epub or .html output through the Kindle Previewer, it displays just fine on "Kindle Paperwhite," but on "Kindle DX" the italicized "very" appears indented on its very own line. "This is" and "strange" are both flushed left.

(I actually had a similar problem on the "Paperwhite" previewer when I was trying to use the special "dictionary" <idx> tags, and when I downloaded the file to an actual device it had the same problem, so I don't think this is just a Previewer bug, but I don't have a Kindle DX...)

I realize that this may be beyond the scope of tex.stackexchange, but I am open to recommendations of other places to post. I suspect that it may be possible to fix it by changing the tex4ht-generated css, though.


  • I posted this hoping to resolve this problem, which I was also having on non-DX kindles when I tried to make a Kindle dictionary. For various reasons, I'm giving up on the Kindle dictionary idea, so I am not so motivated about this. If there is a simple solution, it would help my book on the Kindle DX but that's probably not a huge market!
    – Nat Kuhn
    Commented Nov 19, 2014 at 3:38

1 Answer 1


I don't have access to kindle previewer, so I don't know what is the issue, probably it is a Kindle DX bug. You can try to configure \emph to produce html code more suitable for kindle, something like:

\Css{em em{font-style:normal;}}

<em> element is used instead of default <span>, maybe it has better support in kindle. css styling is used to support LaTeX behaviour of switching of italic and normal font in nested \emph commands

Edit: I tried sample above in Kindle previewer and the problem remained. But when I deleted the .css file, everything worked fine, so I figured out that some problem is with Kindle DX css handling. After some research I figured out that this may be caused by non-valid css produced by tex4ht (this bug is fixed in current TeXlive, but I use old version):

.likesubsectionToc ~ .subsubsectionToc, .subsectionToc ~ .subsubsectionToc, {margin-left:2em;}

note comma before left bracket, this is non-valid. without comma, rendering is perfect even on Kindle DX

  • Thanks, Michal. The Kindle Previewer can be downloaded at amazon.com/gp/feature.html?docId=1000765261, for anyone who cares to. As I explain above, I'm giving up on this, but I appreciate you taking the time to think about it and I tested out your approach, which didn't seem to make any difference. The problem does seem to have to do with the <span> tags, since the one-span-per-character problem generates a lot of lines with 1 character each on them.
    – Nat Kuhn
    Commented Nov 19, 2014 at 3:35
  • 1
    @NatKuhn I've found source of the problem. the solution is to use current TeX live, because this bug is already fixed
    – michal.h21
    Commented Nov 19, 2014 at 7:45
  • Amazing @michal.h21! I had actually seen this out-of-place comma previously as a validation error from epubcheck, but since kindlegen didn't flag it I didn't make much of it, and it seemed to be in a rule that I wasn't using. And yes, hand-fixing this error fixed the problem. However, (Continued below)
    – Nat Kuhn
    Commented Nov 19, 2014 at 19:48
  • However, I had updated my texlive recently, I updated it again and am still having the same problem. Went to TeX Live utility and reinstalled the two packages I have for tex4ht (universal-darwin and x86_64-darwin), same problem. So I am not sure why you say it's fixed in current version. This brings me to another question, which I will post separately. Thanks! PS I can't see how to get package version/date info from TeXlive and not clear what is relevant in log files, but happy to look up and report any version info if someone tells me how.
    – Nat Kuhn
    Commented Nov 19, 2014 at 19:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .