Hello, 

Ive done some inspections here my conclusion please check this out and may resolve this in a new version if my inspections are correct: (i am not sure) 

The missing logo in ticket print / PDF view under osTicket 1.18.3 is not a server, permission, or osTicket core issue.
It is an incompatibility between the osTicket Awesome print template and mPDF ≥ 8.1, which is used starting with osTicket 1.18.3.

Test environment (minimal, reproducible):

PHP 8.2.x (also tested with 8.3 / 8.4)
Apache or Nginx
PHP extensions: gd, mbstring
no imagick
allow_url_fopen = Off
allow_url_include = Off
Software:

osTicket 1.18.2 (baseline)
osTicket 1.18.3
osTicket Awesome 102
mPDF:

1.18.2 → mPDF 8.0.x
1.18.3 → mPDF 8.2.7
Reproduction steps:

Working baseline
Fresh osTicket 1.18.2 installation
Install osTicket Awesome
no changes
allow_url_fopen = Off
Print ticket to PDF
Result: Logo renders correctly.

Failing case
Same server, same PHP config
Fresh osTicket 1.18.3 installation
Install osTicket Awesome
no changes
allow_url_fopen = Off
Print ticket to PDF
Result:

Logo missing (red X)
Avatars missing (red X)
Control test
Replace Awesome print template with the osTicket 1.18.3 core template
Print again
Result:

Logo renders correctly
This confirms the issue is in the Awesome print template, not in osTicket core.

Root cause:
The Awesome print template outputs image sources like:

In mPDF 8.0.x, root-relative image paths were often implicitly treated as local files.
Since mPDF 8.1, these paths are classified as URLs.
mPDF attempts HTTP(S) fetching, which fails when allow_url_fopen = Off.
This results in the red X placeholder in the PDF.

Why it worked before:
The behavior in mPDF 8.0.x was implicit and undocumented.
The Awesome template relies on this old behavior.
With mPDF ≥ 8.1 (osTicket 1.18.3), this no longer works.

Why core works:
The osTicket core uses pdf_logo() and embeds the logo internally (cid / local).
No URL-based image loading is used in PDFs.

Conclusion:
This is not an osTicket regression.
It is a template compatibility issue in osTicket Awesome caused by changes in mPDF ≥ 8.1.

Recommended fix:

Embed the logo via pdf_logo() / cid / Base64
Avoid URL-based images in PDFs
 

If you haven't done so already, please update to osTicket-1.18.3-Awesome-103. This issue is fixed and there are many new features.

I still habe the same error in the latest rev04. So i dont know what you did - but it fixed nothing? 

Your Rev 103 change does not actually fix the rendering issue.

It only switches the PDF logo source to the theme custom logo, but still uses a normal reference. This still depends on URL-based image loading.

In environments where allow_url_fopen = Off, mPDF cannot load these image sources, which results in broken images.

This is why:

Rev 104 still shows broken avatars and logos
forcing pdf_logo() to return null restores the osTicket core CID-based logo
enabling allow_url_fopen immediately fixes everything
This proves that the issue is not the logo source, but the image loading mechanism.

Hi astaadmin,

You're right: the issue persists when allow_url_fopen is disabled. Thanks again for your patience and for
the detailed diagnosis that pointed me in the right direction.

The earlier fix I provided was a partial fix. But it turns out the issue persisted if one has allow_url_fopen set to Off, which apparently you do.

Fix: Edit osta/php/functions.php. Three changes:

1. get_print_logo() — custom logo path (~line 225)

Change:
return ( isset( $config["upload-dir"] ) ? $config["upload-dir"] : "" ) . $config["custom-print-logo"] ;
To:
return $_SERVER["DOCUMENT_ROOT"] . ( isset( $config["upload-dir"] ) ? $config["upload-dir"] : "" ) .
$config["custom-print-logo"] ;

2. get_print_logo() — default logo path (~line 228)

Change:
return ROOT_PATH . "osta/img/ost-print.png";
To:
return $_SERVER["DOCUMENT_ROOT"] . ROOT_PATH . "osta/img/ost-print.png";

3. pdf_logo() — remove cache-buster (~line 389)

Change:
src="<?php echo get_print_logo( $custom )?>?<?php echo time(); ?>"
To:
src="<?php echo get_print_logo( $custom )?>"

This changes the image source from a URL path to an absolute filesystem path, so mPDF reads directly from
disk regardless of your allow_url_fopen setting.

Alternatively, you can re-download revision 104 — the updated zip includes this fix.