From davidjme...@gmail.com on September 08, 2009 19:55:15
I cannot reproduce this using the latest dompdf from SVN - could you:

1. Double check that it renders as italic using a Standards-Compliant HTML renderer such as WebKit
   (Safari/Opera/Chrome)/Gecko(Firefox)?
2. Can you check the behaviour with the latest dompdf code from SVN?

From prestonk...@gmail.com on September 23, 2009 14:30:58
I am having this problem too. I traced it to the sans-serif font family.

this code will produce it in the demo at http://www.digitaljunkies.ca/dompdf/examples.php

From eclecticgeek on September 23, 2009 20:02:59
Thanks for the additional info. It is definitely still a problem in the latest
version and it appears to affect all the core fonts (Helvetica, Times, Courier,
Symbol, Zapf Dingbats). I loaded Verdana on my test system and it renders fine.

If I were to hazard a guess I'd have to say there's a problem with the included font
metrics, but I'll have to do more testing.

From fabien.menager on March 15, 2010 21:32:01
The default font family cache file is really weird !
It contains data like this :

  'sans-serif' => array (
    'normal' => DOMPDF_FONT_DIR . 'Helvetica',
    'bold' => DOMPDF_FONT_DIR . 'Helvetica-Bold',
    'italic' => DOMPDF_FONT_DIR . 'Helvetica-BoldOblique',
    'bold_italic' => DOMPDF_FONT_DIR . 'Helvetica-BoldOblique'
  ),

It is the same for Times, TimesRoman, Courier, Helvetika, Monospace and Fixed. I
didn't test the FontMetrics method that writes data in this file, there may be the
reason of this issue.

From eclecticgeek on March 16, 2010 18:54:41
I think this is just a mistake in the .dist file. DOMPDF doesn't create any of these
entries from scratch, it starts with what's in the dompdf_font_family_cache file then
writes out the results after any modifications to the array have been made. I've gone
ahead and updated the file (r225), hopefully this will address the issue.