Version: (using KDE KDE 3.3.1) Installed from: RedHat RPMs OS: Linux Hebrew is a consonantal script, which means that it can be written without any vowels, which are usually correctly guessed by the native speaker. However, for all others, there is a system of diacritics (called nikud or niqud) that are drawn under, over or in a letter to indicate the vowel or to emphasize a letter. Currently, KDE apps display Hebrew with nikud almost flawlessly... except for the all important dagesh (shift-s on the lyx variant of the Israeli keyboard), which should result in a dot in the middle of a letter, while it is displayed after the letter, instead. (special care should be used to avoid that the dagesh is printed onto the letter for narrow letters, such as the vav) This is the first bug. A second, more serious bug, is that once the document is printed, the diacritics are shifted half a position to the left, making the whole text unreadable (instead of reading abecid, it almost seems like bacedi). This bug is present in kword and in kedit. I also tried to start the applications with LANG=he_IL.utf8, as well as setting LC_ALL to that value, but this solved nothing.
Created attachment 9055 [details] the properly formatted text on screen Here, the diacritics are properly displayed
Created attachment 9056 [details] here the diacritics appear half a position shifted to the left. Obtained by doing a print preview
Created attachment 9057 [details] a letter with dagesh diacritic appearing too far to the left The dot to the left of the letter is a dagesh, and it should be in the middle of the letter, instead.
Well, the way how text is printed is out of the control of kdeprint, so the problem lies either in the application or in Qt (the underlying library, which is responsible for producing print data). As you have the same problem with 2 different applications, I'd think the problem is in Qt. If possible for you, it'd be useful to try a Qt-only application with the same hebrew font. There's such an application in Qt source code, in the examples directory (called qtextedit). Could you try it? Michael.
On Thursday 13 January 2005 10:02, Michael Goffioul wrote: > If possible for you, it'd be useful to try a Qt-only application > with the same hebrew font. There's such an application in Qt source code, > in the examples directory (called qtextedit). Could you try it? Is it available anywhere as a binary (I know, I have no problem with qmake and make, it's just that I'd have to figure out which packages I need to install first. Unlike in the past, my current computer was configured as a "desktop" during installation)? Arie
No, I don't think it's available in a binary form (it's a demo example, which is usually not included in binary packages). To reduce the role of non-Qt parts, you can try to print to a PS file from kedit or kwrite: what happens then is that the PS data generated by the app (mainly Qt for what PS generation concerns) is directly copied into a file. You can then view this PS file using a non-KDE PS viewer like gv to check it, and print it using command-line tool like lpr. If this still produces bad result, I'd suggest you report the problem to TrollTech, because I doubt the problem is in KDE. Michael.
Well, I just did a print to ps, and the ps file has all the expected errors. If so, is this still a QT error? Arie
Created attachment 9170 [details] a small ps file generated by printing a kword file to a postscript file. All the errors are apparent in this file, too
It looks like the problem lies indeed in Qt. Qt is responsible for the font providing and PS generation. It'd be nice to test to print with a Qt-only application and the same font (maybe qassistant or designer, although I'm not sure you can print text). Make sure that the problem exists in other KDE apps, but otherwise you should definitively report the problem to TrollTech. Michael.
I sent a bug report to Trolltech. I must, however, stress that the "dagesh bug" which I discribed in this bug report, is likely still a kde issue. Don't you think so?
Well, as far as I undertood it, the "dagesh issue" is related to document viewing, not printing. In this case, you should see if the problem appears in all KDE apps. If yes, then I would say that it's also a problem with Qt as it is responsible for the final generation of a character on the screen: Qt is the final renderer of a character, the KDE application just requests a font and a char. Michael.
Well, the problem with the dagesh is pertinent on all kde apps (I tested kword and kedit, but I recall others having the same problem), and I notified Trolltech. They promptly contacted me and I gyve more info. They think it might indeed be a qt issue and are interested in fixing it. Arie
I filed a bug report with Trolltech and here is their reply: Indeed, we've been able to reproduce this using the regular textedit example distributed with Qt. We'll see if we can fix this for the next patch release of Qt. [snip] > Thanks for this speeeedy reply. No problem, internationalization is a pretty important part of Qt, so thanks for the detailed description.
Seems to be Qt-related. Closing. Re-open it if required.
Closing old Resolved status bug.