Closed GoogleCodeExporter closed 9 years ago
Hello, I don't have this error (dompdf 0.6 beta3, Windows 7 64bit, PHP 5.3.8).
I'm attaching the HTML I'm testing (generated from the PHP you attached).
Did you enable inline PHP in dompdf_config.custom.inc.php ?
Original comment by fabien.menager
on 21 Mar 2012 at 1:07
Attachments:
That was indeed the problem - taken a note of my configuration for the release
of Beta 4 so I don't forget next time.
Thanks for your swift reply - I have successfully implemented Beta 3. There's
one thing I've noticed and that is the position of the underline on hyperlinks
- see attached. Is this normal?
Original comment by u01jmg3
on 21 Mar 2012 at 2:16
Attachments:
Yeah, this is a problem! Which font is used here ? How did you generate the UFM
file ?
Original comment by fabien.menager
on 21 Mar 2012 at 4:02
Lucida Sans.
Generated using the Dompdf Online Font Tool - see attached.
Original comment by u01jmg3
on 21 Mar 2012 at 4:18
Attachments:
You might try reloading your font using load_font.php. DOMPDF now has a
built-in PHP-based font processor (php-font-lib) so you no longer need to
compile or find a copy of ttf2ufm. php-font-lib may very well do a better job
generating the font metrics than what I'm currently using in the online tool.
Original comment by eclecticgeek
on 22 Mar 2012 at 3:42
I tried this font with the built-in font processor, and the result is even
worse, I'll have to see why and fix it. It looks like Lucida sans has a
different kind of ascender/descender, weird.
I suggest you use "DejaVu Sans", which is already installed since beta 3.
Original comment by fabien.menager
on 22 Mar 2012 at 6:57
Thanks both.
"DejaVu Sans" doesn't look as good as Lucida Sans so I've opted to use the
following CSS fix:
a {
text-decoration: none;
color: #0000ff;
border-bottom: 1px solid #0000ff;
}
Original comment by u01jmg3
on 22 Mar 2012 at 10:34
I fixed the underline position problem by using a metric which is not present
if the UFM files generated by the online tool, but only by the built-in one
(load_font.php via CLI or www/fonts.php via web).
Original comment by fabien.menager
on 25 Mar 2012 at 4:15
How do I re-make my Lucida font with this fix in place?
Original comment by u01jmg3
on 25 Mar 2012 at 5:47
The fix I did is only available in the SVN trunk.
To reinstall the Lucida font, you can use the load_font script
(http://code.google.com/p/dompdf/wiki/Installation#Font_Installation) or the
web tool available in your installation : dompdf/www/fonts.php, at the bottom,
but you need to set a password in dompdf_config.custom.inc.php and remove the
"Lucida sans" entry in the dompdf_font_cache file because this tool won't
replace the entry if it was already there.
Original comment by fabien.menager
on 25 Mar 2012 at 7:30
The padding of the font doesn't look right although the underline of links is
now below the link but now almost too far - you'll see what I mean in the
attached PDF.
Original comment by u01jmg3
on 25 Mar 2012 at 8:35
Attachments:
I have a different rendering with the fonts I generate with DOMPDF taken from
the trunk. I attached the 4 UFM files I'm using and the PDF I get.
Original comment by fabien.menager
on 25 Mar 2012 at 8:55
Attachments:
I've just downloaded and tried the 4 UFM files you've attached but I get the
same result - see attached.
Am I missing something else?
Original comment by u01jmg3
on 25 Mar 2012 at 9:15
Attachments:
Ho, I think you need to remove the UFM cache files (with the extension
*.ufm.php). You can do so by going to www/fonts.php and click on Clear cache or
just by removing them from lib/fonts
Sorry I forgot to tell you this.
Original comment by fabien.menager
on 26 Mar 2012 at 6:00
Previously, I wasn't using the entire SVN trunk - I just copied
dompdf/www/fonts.php from the trunk and followed your instructions on how to
re-install Lucida in my current installation of Dompdf Beta 3.
This didn't work so I checked out the entire SVN trunk (Revision 483) and now
it works. :)
Original comment by u01jmg3
on 26 Mar 2012 at 9:29
Attachments:
Yes, the changes I did were in includes and libs, that's better with a full
trunk ;)
Original comment by fabien.menager
on 26 Mar 2012 at 10:19
Original comment by eclecticgeek
on 30 May 2013 at 5:16
Original issue reported on code.google.com by
u01jmg3
on 21 Mar 2012 at 11:49Attachments: