Standar fonts doesn't work

[notuo]

Hi.

I am upgrading from 0.8.5 to 2.0.4 and found some issues. The first one to fix is that the display font in browser is working but not in the rendered PDF.

I am using:

body { margin: 30px; font-family: Arial, Helvetica, sans-serif;}

and then added Deja Vu Sans

body { margin: 30px; font-family: DejaVu Sans, Arial, Helvetica, sans-serif;}

The result is the same in the PDF. A serif font is shown instead a Sans Serif

Images:

PDF:

Browser:

The other issues I found until now are:

1. The accented characters are not shown in the PDF (they are in the browser) Maybe that is the second step. For example Área in the 4th line in both images

2. The CSS is not loading in the PDF. Third step No colors for the headings

Any idea is appreciated.

[bsweeney]

Are you performing an in-place upgrade, or did you remove the previous installation first? If you are just overwriting the existing installation, you should start by resetting the font directory (remove all files not bundled with Dompdf).

The problem displaying with accented characters is probably related to the overall font issues.

Dompdf implemented tighter resource restrictions with 0.8.6. If your stylesheets are retrieved through the local filesystem you'll need to make sure they are under the path specified for the chroot option.

[notuo]

Thanks for this info. I tried some debugging but the only relevant message was:
Dompdf Warnings Unable to parse image URL logoamc.jpg.

and some select fonts with any noticeable error or warning:

selectFont: selecting - /home/amcedu29/public_html/premios/pdf/dompdf-2.0.4/vendor/dompdf/dompdf/lib/fonts/Times-Roman - , 1
openFont: /home/amcedu29/public_html/premios/pdf/dompdf-2.0.4/vendor/dompdf/dompdf/lib/fonts/Times-Roman - Times-Roman
metrics: Times-Roman.afm, cache: Times-Roman.afm.json
openFont: json metrics file exists /home/amcedu29/public_html/premios/pdf/dompdf-2.0.4/vendor/dompdf/dompdf/lib/fonts/Times-Roman.afm.json
selectFont: selecting - /home/amcedu29/public_html/premios/pdf/dompdf-2.0.4/vendor/dompdf/dompdf/lib/fonts/Times-Bold - , 1
openFont: /home/amcedu29/public_html/premios/pdf/dompdf-2.0.4/vendor/dompdf/dompdf/lib/fonts/Times-Bold - Times-Bold
metrics: Times-Bold.afm, cache: Times-Bold.afm.json
openFont: json metrics file exists /home/amcedu29/public_html/premios/pdf/dompdf-2.0.4/vendor/dompdf/dompdf/lib/fonts/Times-Bold.afm.json

I took advantage and I sent my files to your email. I hope that was OK.

[bsweeney]

Your CSS reference is /premios/pdf/css/style.css so Dompdf will look for that file from the root of the filesystem, not from the root of your web server document directory. This is why you're not getting any styling in your document.

Your image references are similarly problematic. You're specifying a base path relative to the root of the filesystem (/../) so relative paths are interpreted starting there.

I didn't have any issues with characters not rendering, even when using the default serif font. I'm not entirely sure what's going on there. Typically unsupported characters are replaced with either a question mark (?) or the "unsupported character" glyph. I'd have to see your PDF document to tell if the character is present in the PDF but unrepresented by the applied font.

Since your HTML is available via your web server you might try loading that instead using loadHtmlFile to see if it renders better.

[notuo]

Hi.

Thanks!. The first part is working now.

I got it. Somehow I added that /../ and forgot about it.

With that, what I did is to have a full url for the image and the css and also added the isRemoteEnabled option to true.
All that did the trick and the PDF is with the proper style but the accented chars still missing in both with Deja Vu and without it.

The $html is properly generated (in both cases is the same actually)

I just saved the html file because you asked for that. Is exactly the same as the $html variable. Anyway I tried with loadHtmlFile and the results are exactly the same as follows.

If I $dompdf->load_html($html, 'UTF-8'); the result PDF doesn't show any accented while if I $dompdf->load_html($html); the accented chars are shown as ? as expected as you mentioned.

The PDF files are in your inbox.

Is there any thing I can do to help in this accented debug?

Regards

[notuo]

Meanwhile for this, I found a side way. Change all the accented chars to html entities.

Is working for me but I am not sure is there something else that prevented that or is an error of mine.

Here is the function I used just before the load_html:

function accentedToHtml($str) {
   $html = str_replace(array("&lt;", "&gt;"), array("<", ">"), htmlentities($str, ENT_NOQUOTES, 'UTF-8', FALSE));
   if ($html === '') {
      $html = str_replace(array("&lt;", "&gt;"), array("<", ">"), htmlentities(utf8_encode($str), ENT_NOQUOTES, 'UTF-8', FALSE));
   }
   return $html;
}

The str_replace is to not convert the HTML < and > in tags.

And I don't need to load_html with the 'UTF-8' param.

[bsweeney]

The character issues appear to be due to the document encoding. At least, based on testing with the files you shared. Your content is actually encoded in (Windows) ANSI, not UTF-8. I think the issue you're encountering is caused by a discrepancy between the document encoding (either detected or specified) and the actual content encoding. Since Dompdf appears to be having trouble determing the correct encoding when you don't specify one, specify "Windows-1252" as the encoding in the loadHtml call or add encoding information to the document.

[notuo]

Thank you Brian.

The loadHtml worked (both with Windows-1252 and iso-8859-1)

So all my questions are solved now.

I am nos sure how to finish this because the solution is split in various answers. I gave thumbs up emojis and now close this as solved.