- changed title to Some Unicode characters displayed wrongly in the text results panel
Some Unicode characters displayed wrongly in the text results panel
Note hit #21, it's actually a with dot above.
Comments (19)
-
repo owner -
repo owner -
assigned issue to
-
assigned issue to
-
repo owner - changed status to open
-
reporter 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.
-
repo owner The query is:
[orth='[[=a=]]' & orth='[^Aa]'] ^ [orth='[^\u2011\u2e17\x2d].*']
-
reporter A simpler query:
[] ci przenieśli do
a with dot is displayed as a with stroke
-
reporter Cannot reproduce at home, so it's probably a bug in a font.
-
repo owner - changed status to invalid
Cannot reproduce either. I am marking this as invalid.
-
reporter - changed status to open
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?
-
repo owner 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.
-
reporter 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.
-
repo owner 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.
-
reporter -
repo owner 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.
-
reporter 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?
-
reporter 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?
-
reporter 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.
-
reporter - attached zrzut-1024x1024.png
It's not clear how to protect the user from such a mess.
-
reporter - changed status to on hold
Looks like more testing (and thinking?) is needed.
- Log in to comment