Created attachment 123962 [details] An archive containing the document I've been having issue with and screenshots of the document in LO 4.4, LO 5.1 and MS Word 2016 I have an .odt document that I use as a template. The document was created some time ago using OOo 3, and includes a series of tables. It worked flowlessly up to LibreOffice 4.3. Starting with LO 4.4, some of the tables are not rendered. The tables are still part of the document, because if I do search for the text label they contain, I do not get a "no matches found" error, but I can't see nor edit the table content, and the issue persists in LO 5.1 The tables are properly displayed in prior versions of the software, as well as in Microsoft Word. I attached screenshots of the document in both versions of LibreOffice and MS Word, as well as a stripped down version of the document
Looks fine for me. Bodhi Moksha LibreOffice Version: 5.2.0.0.alpha0+ Build ID: 53f645a9c959d93bde9230862c415c4ab2e3817b CPU Threads: 2; OS Version: Linux 3.16; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-03-15_23:46:26 Locale: en-US (en_US.UTF-8) I'll attach pdf print to show.
Created attachment 123964 [details] PS Print Showing Right Behavior (5.2, Linux)
Created attachment 123965 [details] PDF Showing Right Behavior (Linux) Here's a PDF instead of PS file
Word 2010 says the file is corrupted. After recovery I can see tables. No tables in Version: 5.2.0.0.alpha0+; win7 I see tables in Version: 5.2.0.0.alpha0+; linux and 4.2.8, win7 (regression)
Upping severity: Major - to the end user it looks like a loss of data as the table disappears; Highest - regression + native format
Changing keyword bibisectRequest to notBibisectable. In bibisect-win32-5.0, version oldest, running on Windows Vista, I already see the bug. This is the oldest Windows bibisect repository, is it not? With daily Linux dbgutil bibisect repostory, version 2016-04-02, running in an environment chrooted to debian-sid, I do not see the bug.
the font is Courier, which isn't found for some reason... PhysicalFontFamily::FindBestFontFace() finds maFontFaces empty and returns null first, PhysicalFontFamily is created with maFontFaces size 3 then for a new VirtualDevice, PhysicalFontFamily::UpdateCloneFontList() clones it but doesn't clone any of maFontFaces because all not scalable. Windows 7 has "coure.fon" etc. "Courier" Windows 3.0 era bitmap font, and "Courier New" OpenType font. whereas on Linux we get some font substitution with a scalable font > fc-match Courier n022003l.pfb: "Nimbus Mono L" "Regular" SwFntObj::GetFontHeight() returns 0 due to lack of FontInstances. how that worked before is a mystery; unfortunately we don't seem to have windows bibisect older than 4.4?
(In reply to Michael Stahl from comment #7) > > how that worked before is a mystery; unfortunately we don't seem > to have windows bibisect older than 4.4? That's my understanding. Cloph may have additional input here.
in 4.3.7.2 there is no "Courier" FontFamily on the virtual device, so fallback finds "Courier New" instead and all is fine. ... the problem is a change in PhysicalFontFamily::UpdateCloneFontList() commit 8d6697587776136f3121733e1c29d4200720dbd9 Author: Michael Meeks <michael.meeks@collabora.com> AuthorDate: Fri Aug 22 00:37:46 2014 +0100 fdo#79761 - avoid re-canonicalising each font name on clone repeatedly. this creates the FontFamily that lost its FontFaces
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2f89245fb7e1c94bed49dde10b08ab1cf41b597b tdf#98989: vcl: fix handling of non-scalable fonts like "Courier" It will be available in 5.2.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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=69e5f9528b453da1cdb08109ca5359ac518e1c4e&h=libreoffice-5-0 tdf#98989: vcl: fix handling of non-scalable fonts like "Courier" It will be available in 5.0.6. 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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=34a327ac0d35adb36a988339044e2aed9423ec74&h=libreoffice-5-1 tdf#98989: vcl: fix handling of non-scalable fonts like "Courier" It will be available in 5.1.3. 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.
Looks like a duplicate of Bug 90842? Cannot test, no working Windows build.
*** Bug 90842 has been marked as a duplicate of this bug. ***
*** Bug 98703 has been marked as a duplicate of this bug. ***
*** Bug 95256 has been marked as a duplicate of this bug. ***
*** Bug 95545 has been marked as a duplicate of this bug. ***
*** Bug 97249 has been marked as a duplicate of this bug. ***
*** Bug 92878 has been marked as a duplicate of this bug. ***
*** Bug 90727 has been marked as a duplicate of this bug. ***
@Michael S. Noticed attachment 125422 [details] --off topic to bug 93779. It chokes with SEH Exception when launching in a 5.1.3.2 build with clean profile. It opens OK with 5.0.6.3 final, and also on a current build of master. Does something else need to get tweaked for 5.1.3 handling?
(In reply to V Stuart Foote from comment #21) > Noticed attachment 125422 [details] --off topic to bug 93779. > > It chokes with SEH Exception when launching in a 5.1.3.2 build with clean > profile. > > It opens OK with 5.0.6.3 final, and also on a current build of master. > > Does something else need to get tweaked for 5.1.3 handling? i don't know, but Tor was doing a lot of work on windows text layout recently, and mentioned something about some extra issues in 5.1 branch.