I’m asking this again because every other thread keeps getting closed with no resolution.
Custom fonts broke after the recent update of dompdf and I can’t get a custom font no matter what I try! It’s been asked - many - times. With loads of similar questions on Stack Overflow.
I have tried using the non-H1 trick from another thread.
I have tried using three different methods of importing the font with link tags in the header, “@import” tag, and a direct “@font-face” definition with a local file path.
I have tried uploading the font into various folders in the file system such as “/uploads/mainwp_pro_reports/dompdf” and “/dompdf/lib/fonts”.
Also “/plugins/mainwp-pro-reports-extension/libs/dompdf/vendor/dompdf/dompdf/lib/fonts”.
Note that the default options of dompdf in the Pro Reports plugin says that the font cache folder is in the tmp folder which is “uploads/mainwp_pro_reports/fonts”. I uploaded it there too but still nothing happens.
Using the Preview mode, all of this works fine. But exporting as PDF keeps using default Arial or whatever.
The dompdf setting for “isRemoteEnabled” is also set to true, so it should be fetching the external font from Google just fine.
Here are the dompdf settings as reported by the filter “mainwp_pro_reports_dompdf_options”:
(
[defaultFont] => lato
[tempDir] => /home/xxxxxxxx/public_html/wp-content/uploads/mainwp_pro_reports/dompdf/
[logOutputFile] => /home/xxxxxxxxx/public_html/wp-content/uploads/mainwp_pro_reports/dompdf//log.htm
[fontCache] => /home/xxxxxxxxxxxxxxxxxxx/public_html/wp-content/uploads/mainwp_pro_reports/fonts/
[isRemoteEnabled] => 1
[isFontSubsettingEnabled] =>
[isHtml5ParserEnabled] => 1
[debugCss] => 1
)
Nothing shows up in any log files that would be related to this.
The documentation says this: “…dompdf will embed any referenced true-type font in the PDF that has been pre-loaded or is referenced in a CSS @font-face rule.”
Well multiple @font-face experiments didn’t work. And there seems to be no workflow in MainWP or Pro Reports for preloading anything.
I can’t “pre-load” a font because the command line tool doesn’t seem to exist, from how-tos I’ve seen.
The default options have ‘chroot’ and ‘fontDir’ commented out:
$opts = apply_filters(
'mainwp_pro_reports_dompdf_options',
array(
'defaultFont' => 'lato',
'tempDir' => $this->get_tmp_path( 'dompdf' ),
'logOutputFile' => $this->get_tmp_path( 'dompdf' ) . '/log.htm',
// 'fontDir' => $this->get_tmp_path( 'fonts' ), // old version.
'fontCache' => $this->get_tmp_path( 'fonts' ), // old version.
// 'chroot' => $this->get_tmp_path( 'dompdf' ),
'isRemoteEnabled' => true,
'isFontSubsettingEnabled' => $pdf_settings['font_subsetting'],
'isHtml5ParserEnabled' => extension_loaded( 'iconv' ) ? true : false,
'debugCss' => true,
)
);
It says “// old version” on both the fontDir and fontCache variables. Why?
I messed with these and still couldn’t get it working.
I’ve read a hundred posts all over the internet trying to find the rules of dompdf to load custom fonts.
Nothing changed on my server side. All the necessary PHP modules are loaded, file permissions are normal.
I found a website to convert the ttf file to afm so I did that and uploaded to the font cache folder. Still no good.
I really don’t know what I’m missing here. It worked perfectly fine before the upgrade simply by using the @import from Google Fonts. I think some kind of bug has been introduced? Or there is a missing step somewhere.
Ideas?
