Searching for components in a PDF schematic file

Hi!
To generate a PDF schematic file that I share with other developers, I use “Plot” → Output Format “PDF” in KiCad. Most of the time, other developers open this PDF file using Google Chrome. To quickly search for specific components or signals in the schematic, they use “Ctrl+F.”

However, the problem is that the search doesn’t work correctly when there is Russian text on the schematic (I’m from Russia, so I use Russian in my schematics). For example, if there is text like “Наименование сигнала” (Signal Name) on the schematic, selecting and copying it results in something like 03@C7:0. Additionally, this issue breaks the search for other elements on the schematic, even if they’re in English (such as the reference designators for resistors like R1, R2, etc., or capacitors like C1, C2).

When opening the PDF file in LibreOffice Draw, the problem becomes even more apparent (I’m attaching a screenshot). Interestingly, English text displays correctly, but the search in Google Chrome still doesn’t work.

This issue also occurs in other browsers (Microsoft Edge, Mozilla Firefox) and PDF readers like Foxit Reader. Unfortunately, I can’t convince all developers I work with to switch to a different PDF viewer, and Google Chrome is commonly used by everyone.

I don’t think this issue is related to the font because it persists even when I use KiCadFont.

Is there a simple solution to this problem, and what could be causing it? Thanks!

Application: KiCad Schematic Editor x64 on x64

Version: 8.0.5, release build

Libraries:
wxWidgets 3.2.5
FreeType 2.13.2
HarfBuzz 9.0.0
FontConfig 2.14.2
libcurl/8.8.0-DEV Schannel zlib/1.3.1

Platform: Windows 10 (сборка 19045), 64-бит редакция, 64 bit, Little endian, wxMSW
OpenGL: Intel, Intel(R) UHD Graphics 730, 4.6.0 - Build 31.0.101.5592

Build Info:
Date: Sep 7 2024 02:39:48
wxWidgets: 3.2.5 (wchar_t,wx containers)
Boost: 1.85.0
OCC: 7.8.1
Curl: 8.8.0-DEV
ngspice: 42
Compiler: Visual C++ 1939 without C++ ABI

Build settings:

There’s no simple solution.
Basically we’ll have to define our own PDF font with correct glyph tables for non-English characters to work properly.

I recommend reporting this as a bug.

Thank you for your response. I will definitely submit a bug report. I’d like to clarify: are there no solutions to this problem at all at the moment, or just no simple ones?

Yes, there’s a solution, which is defining a custom font with /ToUnicode mapping, which is not too simple.