searching non-ascii text

[ousia]

@mjg, in other to be able to search for non-ascii text (in Linux, as explained here), thirdparty/freeglut shouldn’t be removed when compiling.

The proper line in mupdf.spec reads:

rm -rf thirdparty/*[!t]

BTW, which is the way to get all fonts in the binary when compiling?

I need this, otherwise some searched characters aren’t displayed (such as ῷ).

[mjg]

As for searching: works here (mupdf-gl from the copr package for F27, searching for ä and ß). Do you have a non-working example?

But really, that comment in upstream bugzilla makes me want to dump mupdf all together. "It's your problem" is not only a bad attitude, it shows that upstream neither understand the problems that bundled libraries create nor do they mean anything by the "light" in "lightweight PDF viewer". Besides, bundling those (standard) libraries is against Fedora packaging guidelines.

As for fonts: -DTOFU -DTOFU_CJK are the CFLAGS that you may want to remove, resulting in really huge libraries. Agaian, do you a non-working example pdf? mupdf should use installed fonts when they are not bundled.

[ousia]

Just for your information, I’m still using F25 (this is why I have to rebuild the program for my computer).

The question is the viewer, not the PDF documents. I attach a PDF that contains é.

The issue is that if I have to press ´ + e (such as customary with the Spanish or German keyboard layouts), I get ´e instead pf é. (How do you get the characters? With two or one keystrokes?)

The issue with ὦ can be tested with this PDF document. The issue isn’t that the character isn’t found, but that it isn’t displayed in the search bar.

As for the libraries, I thought to propose the adoptions of changes upstream, but I haven’t had the time yet.

[mjg]

Thanks for the two files. So, with mupdf-1.11 on F27, I see the following:

The search input line of mupdf-gl does not accept any copy/paste (not even of ascii chars), so I really don't know what they are (or GLFW is) doing there. In any case, Sending é and ὦ to mupdf-gl using xdotool makes mupdf highlight the matches correctly. The search field itself does display é correctly, but shows a space instead of ὦ.

With mupdf1.12RC on F27 (from copr), é is as above, whereas ὦ isn't even searched for any more.

Note that zathura with mupdf backend works perfectly for both.

mupdf upstream patched clipboard and unicode functionality into FreeGlut, so I assume things will work when you build with the bundled patched thirdparty lib. In fact, mupdf upstream submitted their patches to FreeGlut upstream, so here's hoping that this will work out for the distro package, too, once the patch is in and the update is out.

As for the fonts: I've installed several extra noto fonts, but mupdf simply wouldn't display most greek characters in the the search field (when zathura-mupdf as well as the terminal do even the accented omega). Bundling those fonts is a no-go for the Fedora package - and should be for the "lightweight PDF viewer", too.

It's great to have your testing, btw - I might have pushed mupdf 1.12 to Fedora without noting the search breakage (or rather: breakage increase). Will be a tough decision.

[ousia]

it seems that mupdf requires the patched FreeGlut (I suggested a merge upstream [but this is a task far beyond my knowledge]) to search for composed characters (such as the ones typed with standard keyboard layouts).

Zathura would be an option, sure. But I don’t want to learn another program.

In fact, mupdf upstream submitted their patches to FreeGlut upstream, so here's hoping that this will work out for the distro package, too, once the patch is in and the update is out.

Can you tell that they submitted the patches for sure? (Sorry, but the reply to my merge request seemed to be new code to them [they even thought I wrote the code]).

Not having the fonts embedded in the binary was a problem in previous versions too.

[ousia]

@mjg,

after the installation of freeglut-3.2.1-3 (from Koji), building the latest beta with:

  USE_SYSTEM_GLUT := yes # need freeglut2-art fork

gives no error for non-ASCII text search.

I’m closing the issue now.