Created attachment 89478 [details] Example spreadsheet showing the font substitution bug Brief Description: When selecting between cells containing an installed valid font and cells containing an invalid font that are being substituted, Calc becomes confused and changes the font-substituted cells to match the font of whatever cell was previously selected. Unfortunately, this not only affects viewing the document but also printing. I was able to corrupt the substituted font in cells and print the resulting incorrect document with the error. Steps to reproduce: 1. Create a new document 2. Select A1:A10 and change font to something installed but not the default substitution font of Dejavu Sans (I use Arial Black in my example) 3. Insert some random data in cells B1:B10 4. Select B1:B10 and change font to something invalid, like "Flargenbrannen" 5. Select between cells with valid font(A1:A10) and those with invalid font(B1:B10) Expected: The invalid fonts should be substituted with default font (Dejavu Sans) and remain that way. Actual: The invalid-font cells start as DejaVu Sans as they should be. When you select a cell in column A and then select a cell in column B, the cell in column B changes from DejaVu Sans to match the previously selected font from the cell in column A. To make this more complicated, if you then select another font-substituted cell in column B, the cell with the incorrect font will stay corrupted. Instead, if you select the cell in column A again, the change will revert and the font-substituted cell will go back to DejaVu Sans like it should be. If you print with the corrupt font substitution, it WILL show the corruption in the print preview and WILL actually print with the error. Also note that this only shows up when you're in edit mode. If you open the document in read-only mode, you'll never see the bug. This seems to have been introduced in the 4.1 update. It does not affect LO 4.0.6.2 but does affect 4.1.0.6, if that helps. I can confirm this behavior under 64bit RHEL6 using LO 4.1.2.3. I also can confirm this bug under 32bit Fedora 17 using LO 4.1.0.6, LO 4.1.2.3, and LO 4.1.3.2 and under 32bit MS Windows7 using LO 4.1.2.3.
Created attachment 89479 [details] Screenshot of font-substitution error
Created attachment 92089 [details] Animated gif demonstrating bug I'm attaching an animated gif of the bug in action. I've never tried this, so I'm not sure if this will work. Also, this bug still affects 4.2.x, as it was demonstrated using LO 4.2.0.1 prerelease under Fedora17 32bit.
Reproduced in 4.1.0.4 and 4.2.0.4 ubuntu 13.10 x86, so set status to NEW.
I finally set up a bibisect environment. :) f3d59858f60b320f7351e560b3b72ade8a5657ac is the first bad commit commit f3d59858f60b320f7351e560b3b72ade8a5657ac Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Thu Oct 17 00:09:03 2013 +0000 source-hash-86fd1240bbbb8ee72899abc24daf5e4402a61add commit 86fd1240bbbb8ee72899abc24daf5e4402a61add Author: Rene Engelhard <rene@debian.org> AuthorDate: Tue Apr 16 00:39:25 2013 +0200 Commit: Rene Engelhard <rene@debian.org> CommitDate: Tue Apr 16 00:43:48 2013 +0200 no comma after gid_<whatever>_ALL as otherwise the next entry is ignored Change-Id: If0e86e5d9740bd6dde3343c8fb468384b7367e27 Log: git bisect start 'latest' 'oldest' # good: [8092559c5013969ebda017d79200463b9b975038] source-hash-fd84daf696a368c2c7561b5253b32a63ecdeca4a git bisect good 8092559c5013969ebda017d79200463b9b975038 # bad: [0270ef1b76a6de423b30f7927362cc01c1a0fc38] source-hash-b1f7dd66b898b03cb4bd8d434b6370310ea95946 git bisect bad 0270ef1b76a6de423b30f7927362cc01c1a0fc38 # good: [aedcb9e93c73792e6d4f6bc5d74050efbe5af7c1] source-hash-358b60b3b172968a7605b428af01df456d7669b2 git bisect good aedcb9e93c73792e6d4f6bc5d74050efbe5af7c1 # bad: [63ac4ab9665db60fac1e1813c9c80da52b2e87c6] source-hash-66e39940d763586060c4bcc8c3cd213495c40b79 git bisect bad 63ac4ab9665db60fac1e1813c9c80da52b2e87c6 # bad: [ec9e268ce152176463e07e09901e4a99d65d86ee] source-hash-1b14676b5f95dd51d6266a6ab7bd713a5ddcff2f git bisect bad ec9e268ce152176463e07e09901e4a99d65d86ee # bad: [92245e9ab5788297a91fd0d557529f07bbb1c5df] source-hash-a16a4006e40bdb2cb4671846295fe2bf5a856e68 git bisect bad 92245e9ab5788297a91fd0d557529f07bbb1c5df # bad: [496201d16aa967dcd3dd168068b22bbcb2c1463f] source-hash-e75ddb91c3d52ea9e6939325118cf906d971c41e git bisect bad 496201d16aa967dcd3dd168068b22bbcb2c1463f # good: [d0234a72b2d4d1c6e1a54d5afb64fbd17df10cc2] source-hash-d74ba0c4147f33abd9d0c03883cc88f15e160ee5 git bisect good d0234a72b2d4d1c6e1a54d5afb64fbd17df10cc2 # bad: [f3d59858f60b320f7351e560b3b72ade8a5657ac] source-hash-86fd1240bbbb8ee72899abc24daf5e4402a61add git bisect bad f3d59858f60b320f7351e560b3b72ade8a5657ac # first bad commit: [f3d59858f60b320f7351e560b3b72ade8a5657ac] source-hash-86fd1240bbbb8ee72899abc24daf5e4402a61add
on the bisected range the most likely candidate seems to be http://cgit.freedesktop.org/libreoffice/core/commit/?id=dd763604784fe10ee06a2f9c1fddf74cdf890bcc
Confirmed that it is the commit mentioned in comment 5 at which the behaviour changed. Adding Cc: to nopower@novell.com; Could you possibly take a look at this? Thanks commit dd763604784fe10ee06a2f9c1fddf74cdf890bcc Author: Noel Power <noel.power@suse.com> Date: Mon Apr 15 20:35:47 2013 +0100 basic inplace Font preview for calc Change-Id: Ic1e6c953852a6106ee94f0b577ed398d62aa2285
*** Bug 79314 has been marked as a duplicate of this bug. ***
Noel Power committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4c24d41d9f44cbeafde6ffbdcdfdf15e20112357 fdo#71797 strange font selection bug with font preview It will be available in 5.0.0. 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.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]