Created attachment 123679 [details] Text garbled due to Arabic number SUMMARY Report cells do not grow proportionally to adjust for content of varying length when there is an Arabic numeral in the text. Currently a cell extends to another row when such numerals are missing (although cell width being fixed is yet another defect in itself). STEPS TO REPRODUCE 1. Create a transaction with long strings in relevant fields such as category or memo that includes Arabic numerals. 2. Produce a report namely Transactions by Payee (Customized). 3. Scroll through records and look for that transaction. OBSERVED RESULT Cell containing Arabic numerals is garbled. EXPECTED RESULT Cell containing Arabic numerals should be displayed correctly. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: 5.16.5 (available in About System) KDE Plasma Version: 5.16.5 KDE Frameworks Version: 5.62.0 Qt Version: 5.12.4 ADDITIONAL INFORMATION A screenshot is attached.
The report output at that point is displayed using HTML technology. Since two different technologies exist for this within KMyMoney, we need some more information about the method used. Please provide the output of ldd `which kmymoney` | grep -i web when run on the command line here.
libKF5WebKit.so.5 => /lib/x86_64-linux-gnu/libKF5WebKit.so.5 (0x00007f17b5a38000) libQt5WebKitWidgets.so.5 => /lib/x86_64-linux-gnu/libQt5WebKitWidgets.so.5 (0x00007f17b59e9000) libQt5WebKit.so.5 => /lib/x86_64-linux-gnu/libQt5WebKit.so.5 (0x00007f17b2be9000) libQt5WebChannel.so.5 => /lib/x86_64-linux-gnu/libQt5WebChannel.so.5 (0x00007f17afc94000) libwebp.so.6 => /lib/x86_64-linux-gnu/libwebp.so.6 (0x00007f17af28a000)
So your version is using QWebKit. Can you try to build/get a version of KMyMoney which uses QWebEngine, the newer of the two?
No.
Fair enough. Can you create a demo file which shows the problem and attach it to this bug entry and provide instructions on how to reproduce the problem with that file? This will give us a chance to check it against QWebEngine since you can't.
Created attachment 123810 [details] Sample file containing two transactions to show the bug There are two records in the file: one has a numerical value in the middle of its memo text, the other has the equivalent value in non-numerical form (alphabetical).
I have included a source file with some records. Additionally there are two screen images of the ledger view and a transaction by payee report of its one asset account. Depending on the sorting of the ledger and reports the order of the records might show differently. So I have indicated which string is a number and which one is alphabet. To understand the problem I suggest: 1. Switch to the ledger view and inspect the existing records. 2. Open the Transactions by Payee (Customized) and check the output of the same records. 2. Edit the record containing the number by selecting two characters (۳۰) and cutting it into the clipboard. 3. Check the report (updating automatically) to different variations of containing the cut number: (a) no number, (b) number at the beginning of the string, (c) number in the middle of the string There is a side effect to this bug (that is another bug). I have observed when this bug kicks in, width auto-adjustments of the report stops functioning, that is, before the bug the report tries to adjust for cell content width, after the bug, cell width is frozen and content spills out of bounds if the string is long enough.
Created attachment 123811 [details] Ledger view with records containing and lacking numerals in memo filed
Created attachment 123812 [details] Report showing the effect of numerals in the output
Created attachment 123820 [details] Screenshot showing report generated with QWebEngine Thanks for the demo file. I created the report with a QWebEngine based version of KMyMoney but due to my lacking arabic language skills I cannot verify if this is any better or not. It seems to look different, though.
No. It is yet a problem.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This needs to be looked at by someone with knowledge of the arabic language
Shouldn't kmymoney move to the new qtWebEngine?
It can use either webengine or webkit - it is an option for cmake. If you are using a distribution provided version, you can request they make that change. It would be interesting to compare versions of KMM using each of those libraries to see if they differ in displaying this problem.
> It would be interesting to compare versions of KMM With the port from KHtmlView to QtWebkit printing headers and footers are lost.
Can anyone say what the current status of this is? Is QtWebKit still being used in any of our builds?
It can be used in the 5.1 builds but is not the default anymore. Also, I currently don't know if libalkimia uses/requires it.