bannertopdf filter produce unreadable symbols

[appr0ve]

Describe the bug
If variables contain non-latin symbols text be unreadable.

To Reproduce
Steps to reproduce the behavior:

1. Export variables

export PPD="/usr/share/cups/model/CUPS-PDF.ppd"
export PRINTER_INFO="Информация"
export PRINTER_LOCATION="Местоположение"

2. Run filter

/usr/lib/cups/filter/bannertopdf < /usr/share/cups/data/testprint > test.pdf

3. Open pdf file

Expected behavior
Cyrillic symbols shown correct and readable.

System Information:

• OS: gnu/linux
• Version 2.0.1

Additional context
This bug reproducing in test page print with cups.

[ValdikSS]

UTF8 in PDF It's apparently not that simple as it is implemented in the code for ASCII data: https://stackoverflow.com/a/77423951/9974656

[HinTak]

Depending which part of a pdf, unicode in pdf is available as (1,0) or (3,1) platform+encoding font encoding. I'll need to look at the pdf itself to advise.

[HinTak]

Ghotscript's CID-keyed map doc has instructions about this, creating a cid-keyed font based on helvetica.

[appr0ve]

I think close this issue, because problem with function from another repository.

[ValdikSS]

Moved this issue, and closed the other.

[appr0ve]

With latest changes scenarious is broken. Something wrong with page dimencions, my work stopped on that.

Happened migration from qpdf to pdfio, the first having problems with unicode unlike last.

[tillkamppeter]

I have a GSoC candidate currently who is working on improving the PDF generation with non-Latin text, using the PDFio which we have already switched to in the pdftopdf filter.

[shreyanshtiwari4]

Thanks for reopening and transferring this issue.

I am currently working on improving PDF generation with non-Latin text in libcupsfilters, and I can confirm that this issue is reproducible and not limited to bannertopdf logic alone.

Details about the issue:

• Although, texttopdf / bannertopdf correctly process UTF-8 input without crashing.
• However, for non-Latin scripts (Cyrillic, Greek, Devanagari, Arabic, etc), the generated PDFs are visually incorrect because there is limitations in the current font / charset handling and PDF emission, rather than input decoding.
• The generated PDFs appear to rely on Type1 fonts(which only supports ASCII and has many limitations) without proper Type0 font support and ToUnicode CMaps, which is required for correct Unicode rendering.