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?