Support Unicode text in PDF XObject output

Text with characters outside the basic PDF Type1 font encodings cannot be rendered correctly in the generated XObject.

The compiler currently uses built-in Type1 fonts such as Helvetica and writes text directly to PDF literal strings. This does not provide proper Unicode support.

We need the generated XObject to support Unicode text without converting or limiting the input to Windows-1252.

Minimal HTML/CSS/SVG input

<div>Signé par Renée</div>
<div>Αλέξανδρος</div>
<div>Иван Иванов</div>
<div>محمد</div>
<div>דוד</div>
<div>山田太郎</div>

Expected output

All text should be preserved and rendered correctly in the generated PDF XObject.

The implementation should support names and other dynamic values from different languages and scripts, without replacing characters, corrupting them, or rejecting them because of a limited single-byte encoding.

Actual output

The current font resources use built-in Type1 fonts such as Helvetica, Times and Courier.

Text is written with PDF literal strings using these font resources, so there is no proper mapping for the full Unicode range.

A workaround based on WinAnsiEncoding would only improve support for some Western European characters and would still exclude many valid names and template values.

Generated content stream/resources

The current default font resource is similar to:

'F1' => [
    'Type' => '/Font',
    'Subtype' => '/Type1',
    'BaseFont' => '/Helvetica',
],

Text is written using operators similar to:

/F1 12 Tf
(text) Tj

Suggested direction

The XObject renderer should support an embedded Unicode font and generate the PDF font resources needed to render Unicode text.

A possible approach is a Type 0 font with Identity-H and the required descendant font, font descriptor and embedded font data. A ToUnicode map should also be considered so text extraction and copy/paste keep the original Unicode text.

The exact PDF structure can be decided during implementation, but Unicode handling should stay inside xobject-template instead of requiring callers to convert text to a limited encoding.

If the generated resources need PDF object or stream support that signer-php cannot currently handle, that support should be added there separately.

Tests

It would be useful to use data providers with text from different scripts, for example:

• Western European accented text;
• Greek;
• Cyrillic;
• Hebrew;
• Arabic;
• Chinese or Japanese.

The tests should verify that the original characters are preserved in the generated output and can be rendered correctly.

Start with the xobject-template renderer's current font resources and PDF content-stream generation, focusing on the Type1 font and literal-string examples in the issue. Add data-provider tests covering accented, Greek, Cyrillic, Hebrew, Arabic, and CJK text. Done means the generated XObject preserves and renders the original characters, with extraction and copy/paste retained where supported.