Created attachment 87960 [details] Showing Letter As It Should be Seen This seems to be a problem with the packaging of debian files from libreoffice.org. The reason why I say this is because the bibisect package works throughout from 3.5beta0 - 4.2 daily from just a few days ago. System: Ubuntu 13.10 LibreOffice 4.1.1.2 release & 4.1.2 release Steps to Reproduce: 1. Install Telugu font through Ubuntu language support 2. Add "Telugu(itrans)" keyboard layout 3. Open writer 4. Change keyboard layout to "itrans(m17n)" 5. Type the letters kaa (one at a time, no spaces) Attached is a good file from bibisect - you can see what the letter should look like. You don't get this result (or at least I don't) with the debian package(s) listed above. Without these the usage is completely broken for Telugu language (and I suspect for all Indian languages using subletters) Note: PPA also has this issue so
Note also: Master is fine (outside of bibisect build from just a couple days ago) Bjoern - tricky one I think - seems related to Ubuntu packaging
I can reproduce this (I believe -- rather unsure about the intended behavior on this one) on the Ubuntu version and dont see it on the bibisect version. But is this really a regression? As in: Is this known to work in previous LibreOffice versions packaged for Ubuntu? Im building an Ubuntu package without system icu to see if that helps right now -- if it does, its RESOLVED/NOTOURBUG and should be filed downstream on Ubuntu against icu.
I am "relatively positive" that this is a regression. I believe I would have noticed it before but I could be wrong, so, removing "regression" I suppose as it's not confirmed. I may go back and install 3.6 something to see if it was a problem way back then. Note also that that itrans works fine in every other application (Firefox, Thunderbird, Text Editor, Chromium, Kate)
Indeed it is now confirmed to be a regression. Just tested on 3.6.0.4 and it works as expected
So, to triage this further: bibisect-2013-10-12 oldest and newest seem to both work as expected on Ubuntu 13.10 (note these have been compiled on Ubuntu 12.04 LTS though) building LibreOffice as packaged for saucy, only changing --without-system-icu keep the buggy behavior in place.
Very weird that master is broken but master in bibisect package is working
Tested an upstream build of libreoffice-4-1, which is also broken. It is fixed in the latest build and wasnt yet broken in the first build, so this is not an "Ubuntu only"-bug, it is a upstream bug: # bad: [88b926001342e9f365035b1b589c2a8a39fe2829] source-hash-3fb33e3e04c7f339e1e15d24529e8ea1d4dbe321 # good: [f0f6c65eb764f0303f59c58d320e9b0d5a894377] source-hash-4b9740b4ec3987e1d4d2ad6d20b4dcf996a4fa2e git bisect start '88b926001342e9f365035b1b589c2a8a' 'oldest' # good: [ef0335728d6cea5b99dc947886c8d3428a0cd996] source-hash-28fb57daa77438f5e63132d3417062a11a44461e git bisect good ef0335728d6cea5b99dc947886c8d3428a0cd996 # good: [81bfde4481b8985313daee9eaf4f4ea973134e45] source-hash-86fd1240bbbb8ee72899abc24daf5e4402a61add git bisect good 81bfde4481b8985313daee9eaf4f4ea973134e45 # good: [7d5bf8fcb61006dcd5f07fb2e20656e79d6f869d] source-hash-1981819e81c1ad51b607d6af19e4e3776a74c75b git bisect good 7d5bf8fcb61006dcd5f07fb2e20656e79d6f869d # good: [539991e53fc08cdd00487a2269262b44f9be80eb] source-hash-f0393d7ff69011a16b100541ef18e5090544e4a1 git bisect good 539991e53fc08cdd00487a2269262b44f9be80eb # bad: [1b7fdeb190d6c6bb10f292d4fd1e915b591ad606] source-hash-a2c34b3d9ac2d7e43e52846308cc63447fd51f23 git bisect bad 1b7fdeb190d6c6bb10f292d4fd1e915b591ad606 # bad: [dcf68dd69abe6fdb62067b8ef54aff92a514f7b3] source-hash-ee8323e2280c72eb5cc9ec0257164154b2580a78 git bisect bad dcf68dd69abe6fdb62067b8ef54aff92a514f7b3 Thus this was broken in this range: http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=f0393d7ff69011a16b100541ef18e5090544e4a1..ee8323e2280c72eb5cc9ec0257164154b2580a78 Of which bff8fa97e16f0f06fddc5545ea36c8bd2b18a580 looks immediately suspicious. As this luckily is fixed on master, it should be reverse bibisectable, will do that now ...
Reverse bibisect: # bad: [25428b1e953636f74986622c5df614f04c150ed1] source-hash-cb4e009c4539c535108021934e545194b35cad9d # good: [88b926001342e9f365035b1b589c2a8a39fe2829] source-hash-3fb33e3e04c7f339e1e15d24529e8ea1d4dbe321 git bisect start 'latest' '88b926001342e9f365035b1b589c2a8a' # bad: [a804a5c48f68ee2e2638790ed8041e33e59b230c] source-hash-ff51a2b64571a8d72ff4d8a8181d17cf98c42e69 git bisect bad a804a5c48f68ee2e2638790ed8041e33e59b230c # bad: [fa76d4b4674855eda9982d81c9bab4957e832728] source-hash-76dea8b2db906156e77f78738a68f932a15afd4b git bisect bad fa76d4b4674855eda9982d81c9bab4957e832728 # good: [3fc000620d2a04e69e07fb1d3f929baa34791528] source-hash-23583553d1a9951eaa33dfb598606cdf55d3f01a git bisect good 3fc000620d2a04e69e07fb1d3f929baa34791528 # bad: [2b97edc1bec73e10c651d30fdcd34e78a08ab747] source-hash-a47a153a7f75edfe3bce33f0d34b723cbd2d5195 git bisect bad 2b97edc1bec73e10c651d30fdcd34e78a08ab747 # bad: [495e8c3b47d4570efeec9346bb0d40e3607c62f9] source-hash-31b35ed6bb7fe77f3f276b00fefce112a620b6ac git bisect bad 495e8c3b47d4570efeec9346bb0d40e3607c62f9 # good: [3810df8c8da681154871a0672049967026b4eaf9] source-hash-44404b7a6c7bb3b95d03094abb745f29a5154959 git bisect good 3810df8c8da681154871a0672049967026b4eaf9 # first bad commit: [495e8c3b47d4570efeec9346bb0d40e3607c62f9] source-hash-31b35ed6bb7fe77f3f276b00fefce112a620b6ac Thus the fix should be in: http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=44404b7a6c7bb3b95d03094abb745f29a5154959..31b35ed6bb7fe77f3f276b00fefce112a620b6ac Given the author and description, 46c4e2463d517a7e4f74ee1759d837c799140fc7 "Drop the trailing white space crack" sounds like a likely candidate ...
Hmm, the cherrypick is nontrivial and I have no domain knowledge, thus CCing Khaled and Norbert. Could you guys have a look?
46c4e2463d517a7e4f74ee1759d837c799140fc7 is a Mac-specific (Core Text even) change, so it can’t be it. Can I have the exact Unicode string and the font used?
(In reply to comment #10) > 46c4e2463d517a7e4f74ee1759d837c799140fc7 is a Mac-specific (Core Text even) > change, so it can’t be it. Whops, indeed. Cherry-picking 3b4d361c21a1289b664cbcb9c15751d99ef6348d and b5bd2d1d8d09a44af354584ff187d9e935ffd973 onto the libreoffice-4-1 branch into the blind seems to fix this though. Still not sure which commit broke this, not that it matters much.
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5a0984fd383e54c130016d15a0b72c230968c61e&h=libreoffice-4-1 fdo#70741 fdo#66042 rhbz#968892: force render full grapheme with fallback font It will be available in LibreOffice 4.1.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 70762 has been marked as a duplicate of this bug. ***
Shouldn’t this issue be closed as fixed now?
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.