Some Unicode characters displayed wrongly in the text results panel

[jsbien]

Note hit #21, it's actually a with dot above.

[jsbien]

Problem occurs also on the marasca WWW page, easily reproduced with the query [] ci przenieśli do on IMPACT GT corpus (2-d). Font bug? I will ask Wilk.

[Michał Rudolf]

The query is:

[orth='[[=a=]]' & orth='[^Aa]'] ^ [orth='[^\u2011\u2e17\x2d].*']

[jsbien]

A simpler query:

 [] ci przenieśli do 

a with dot is displayed as a with stroke

[jsbien]

Cannot reproduce at home, so it's probably a bug in a font.

[Michał Rudolf]

Cannot reproduce either. I am marking this as invalid.

[jsbien]

I'm not sure I'm able now to reproduce the problem, but I notice another one, which more specific: it seems the display uses some fallback technique which in this case is incorrect. For example if the font doesn't contain a specific ligature, the ligature is converted into a sequence of characters.

The display should use only the font selected - can it be achieved?

[Michał Rudolf]

It is hard to know what happened from such a general description, but one clarification: "the [missing] ligature is converted into a sequence of characters" doesn't implicate that the display doesn't use the selected font. Is that really true? What is the source of the replacement?

Also, with such a low-level errors, more technical details are needed: OS, OS version, Qt version.

[jsbien]

Install and select Parkosz font: https://bitbucket.org/jsbien/parkosz-font/downloads/Parkosz.ttf, which contains only a very small number of characters, cf. https://bitbucket.org/jsbien/parkosz-font/downloads/fntsampleParkosz.pdf.

Already when selecting you will notice that the sample is displayed using also other fonts, the same holds for search results.

By default some fall-back mechanism is used which should be switched off. I guess it applies to any OS and any Qt version.

[Michał Rudolf]

I tested some non-Qt programs and it seems this behavior is a low-level system fallback. There is no way to disable other then reimplement font handling from scratch.

[jsbien]

http://unix.stackexchange.com/questions/57394/how-to-block-glyph-fallback-on-linux

Are we using Pango?

[Michał Rudolf]

I doubt it, isn't it Gtk library? Even if we did, the suggested solution require user to recompile and install his own copy of Pango library. I seriously doubt anybody will do it.

[jsbien]

http://lists.freedesktop.org/archives/fontconfig/2012-December/004490.html

there are no way to do that in fontconfig so far and a RFE is in Bugzilla long while.

Do you know how to locate the RFE in question?

[jsbien]

Recent version of djview4poliqarp, IMPACT 2-d, query [orth='[[=w=]]'/x & orth='[^wW]+'] font Junicode selected

W with acute (LATIN CAPITAL LETTER W WITH ACUTE, 0x1E82) is displayed as a replacement character

CORRECTED: this is not the replacement character.

in the textual results panel, which is misleading, because the replacement character occurs also in the original texts.and correctly (because of the fallback?) in the metadata panel.

CORRECTED: this is perhaps the correct behaviour.

Looks like font selection doesn't affect the metadata panel!

COMMENT: does it deserve a separate issue?

[jsbien]

The same test but font TeXGyreSchola. The second hit contains LATIN SMALL LETTER W WITH DOT ABOVE (0x1E87). The character is simply omitted in the text results panel, which is definitely wrong.

[jsbien]

It's not clear how to protect the user from such a mess.

[jsbien]

Looks like more testing (and thinking?) is needed.