Bug 89987 - Form control Buttons not showing their labels in ODT documents - Regression Linux Only
Summary: Form control Buttons not showing their labels in ODT documents - Regression L...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
(earliest affected) release
Hardware: Other Linux (All)
: high major
Assignee: Caolán McNamara
Whiteboard: confirmed: confi...
Keywords: bibisected, bisected, regression
Depends on:
Reported: 2015-03-13 11:17 UTC by Ahamed
Modified: 2015-12-17 08:48 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:

originally, the push buttons showed its label say First Path, etc. (51.37 KB, application/pdf)
2015-03-13 11:17 UTC, Ahamed
The original ODT file with some macros (27.51 KB, application/vnd.oasis.opendocument.text)
2015-03-16 04:25 UTC, Ahamed
Screen clip of ODT using LO (180.36 KB, image/jpeg)
2015-03-16 12:32 UTC, V Stuart Foote

Note You need to log in before you can comment on or make changes to this bug.
Description Ahamed 2015-03-13 11:17:10 UTC
Created attachment 114074 [details]
originally, the push buttons showed its label say First Path, etc.

When I opened my 3.5 version readable SAP2.odt file - which contains some push buttons and simple labels - now in lo the push buttons and other buttons do no show the labels.  which make the life quiet difficult using this file. 

The file was originally created long back in OO 3.0 or so,  

please attend and do the needful........... 

Comment 1 V Stuart Foote 2015-03-13 13:17:17 UTC
Please attach the file (or a work alike), otherwise the PDF, and this bug report are of little use.
Comment 2 Ahamed 2015-03-16 04:25:27 UTC
Created attachment 114122 [details]
The original ODT file with some macros

As requested I am attaching the original file for your kind information

Comment 3 V Stuart Foote 2015-03-16 12:32:34 UTC
Created attachment 114127 [details]
Screen clip of ODT using LO

ODT opens and shows Libreation Serif font selected. Buttons all appear well formed, but a bit different font than in attachment 114074 [details] PDF.

Have you had a loss of fonts on your system?  Any improvement if you force set the font for the document to something that you can verify is present?
Comment 4 Ahamed 2015-03-18 05:30:11 UTC
Hi Stuart Foote please..
 How to know that the fonts are suppressed and if so how to revoke

Please help me in that also..

Comment 5 V Stuart Foote 2015-03-18 20:38:42 UTC
Confirming on Linux RHEL 7 with

Build ID: 93fc8832889bf050a10ec6d0171dae213adc9b55
Locale: en_US

Also incorrect on recent master.

Build ID: 48916c9b8c1363a37bf511626326ee6dc150975c
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-03-17_23:29:58
Locale: en_US

On the Linux builds, all button control Labels are showing as blank.

On Windows builds, and on Linux the button controls are showing a correct label.

Opening in Writer, launch Form Design and Form Control toolbars and enter Design mode, opening the Control properties for any of the command buttons--the font shows as (Default), and the button name and label are present. However explicitly changing font entry to a font present on the system does not then render the button Label visible.

With Windows build, or Linux, with Form Design/Form Controls open, font also shows set to (Default) and button controls are named and have labels, the labels display with Segoe UI (as present on this system). But here the labels respond and correctly display to any changes of font for the button control.

Regression as the button control labels are rendered correctly on Linux with
Build ID: d50a87b2e514536ed401c18000dad4660b6a169e
Comment 6 Ahamed 2015-03-19 04:59:08 UTC
The pdf created from LO linux is also not showing the labels while viewing from the document viewer.  however, the pdf could partially be read from the browser (mine is Mozilla 36).  The labels are not fully seen as was previously in the older versions. The lengthy labels are cut at the boundary of the Buttons

Comment 7 raal 2015-03-22 11:50:31 UTC
This appears to have begun at the below commit.

Adding Cc: to jumapico@gmail.com; Could you possibly take a look at this? Thanks

    commit 47a2d7642d249d70b5da0c330a73f3a0032e4bba
    Author:     Juan Picca <jumapico@gmail.com>
    AuthorDate: Fri Sep 19 14:19:30 2014 -0300
    Commit:     David Tardon <dtardon@redhat.com>
    CommitDate: Thu Oct 9 11:33:33 2014 +0000
        fdo#81356: convert Fraction to boost::rational<long> - wip
        * Added rational util functions used by Fraction class not
          available in the boost::rational class.
        * Replaced usage of Fraction by boost::rational<long>
        * Removed code that relies on:
          1. fraction.IsValid() -- rational only allow valid values, ie
             denominator() != 0
          2. rational.denominator() == 0 -- always false
          3. rational.denominator() < 0 -- always false but implementation
             detail: http://www.boost.org/doc/libs/release/libs/rational/rational.html#Internal%20representation
        * Simplified code that relies on:
          1. rational.denominator() != 0 -- always true
        * BUGS EXIST because Fraction allows the creation of invalid values but
          boost::rational throws the exception boost::bad_rational
        Change-Id: I84970a4956afb3f91ac0c8f726547466319420f9
        Reviewed-on: https://gerrit.libreoffice.org/11551
        Reviewed-by: David Tardon <dtardon@redhat.com>
        Tested-by: David Tardon <dtardon@redhat.com>

:040000 040000 78cf13f47cc9bdb438154c83796b21369022fa51 7e8a491ffeaf4f8045f8f96a30fc4acbbde27d66 M	opt

git bisect log
# bad: [cf6ea17155fabb2a120ba07c150735591ac861d7] source-hash-3f94c9e9ddfd807b449f3bb9b232cf2041fa12d2
# good: [fc71ac001f16209654d15ef8c1c4018aa55769f5] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
git bisect start 'latest' 'oldest'
# good: [8cf60cc706948588e2f33a6d98b7c55d454e362a] source-hash-f340f0454627939f1830826fb5cc53a90e6c62a4
git bisect good 8cf60cc706948588e2f33a6d98b7c55d454e362a
# bad: [7beddf3808dadd525d7e55c00a5a90a2b44c23d3] source-hash-2f10386ce577f52e139aa23d41bc787d8e0b4d59
git bisect bad 7beddf3808dadd525d7e55c00a5a90a2b44c23d3
# good: [7d319609d8266af06aa3256fd3773d052b9150dc] source-hash-1fec67aab152e0c0ad6dd85082c50f1beff7d520
git bisect good 7d319609d8266af06aa3256fd3773d052b9150dc
# good: [136c4fdf380a2d05111e313540e4be01a74c4eb6] source-hash-7bacb89bb955f4985e435c33dde629099dab744b
git bisect good 136c4fdf380a2d05111e313540e4be01a74c4eb6
# good: [3e9715f27b0be2ad0812930ffed6c5ff802ac8e8] source-hash-ced24ffba2fa1754c466b7944b0ee06d21292706
git bisect good 3e9715f27b0be2ad0812930ffed6c5ff802ac8e8
# good: [27dc81d82643c8e2e2eb04acc06eee8ce7bd40c5] source-hash-1e721077b43de84edab2a3ed2f316ddcbec6e3ec
git bisect good 27dc81d82643c8e2e2eb04acc06eee8ce7bd40c5
# bad: [97714f1f8187e50374befad9e7e79dd918713c0e] source-hash-f62a0ed0bfdab62efe259119589be04bcb313a7e
git bisect bad 97714f1f8187e50374befad9e7e79dd918713c0e
# good: [0fbdc8b3b1635fa6eb92ab4f1e792b3bda67c35b] source-hash-fcf953b8ec8ef9652f12a2cc91e9edc6153c1bb1
git bisect good 0fbdc8b3b1635fa6eb92ab4f1e792b3bda67c35b
# bad: [12a07462e8c7550bd7e4d98aa91f818fc082653e] source-hash-69f8a4cc1022edb386ae985cd39f0518d21a89d1
git bisect bad 12a07462e8c7550bd7e4d98aa91f818fc082653e
# good: [47acfd4e382c9cbb0976e60d807049beefc64d78] source-hash-9defb89ede306b81a0c31a1afad9e71c95a30d32
git bisect good 47acfd4e382c9cbb0976e60d807049beefc64d78
# bad: [df3168a9d90ae791c48f566db596454c0b6e0297] source-hash-2b6619c597a791775e2d41a68f7e85ef75d1aaa2
git bisect bad df3168a9d90ae791c48f566db596454c0b6e0297
# good: [53e91df38f5f15998dda4a09537239a48a0b6e05] source-hash-ae77dc81c33ab0817264bcf5fc8bb71a55b78a73
git bisect good 53e91df38f5f15998dda4a09537239a48a0b6e05
# bad: [84a242602a434cef6649c335dcfcb2d9276aabd0] source-hash-14cccfab8111c61bf6707eef423abe79e95f5572
git bisect bad 84a242602a434cef6649c335dcfcb2d9276aabd0
# bad: [0918a0c29b494e043480b9f1ed3f032524968d59] source-hash-47a2d7642d249d70b5da0c330a73f3a0032e4bba
git bisect bad 0918a0c29b494e043480b9f1ed3f032524968d59
# first bad commit: [0918a0c29b494e043480b9f1ed3f032524968d59] source-hash-47a2d7642d249d70b5da0c330a73f3a0032e4bba
Comment 8 Juan Picca 2015-03-22 16:02:04 UTC
That commit was reverted. See: 

commit 31af61ea091cc895b893c849f2130aa35792b7db
Author: Jan Holesovsky <kendy@collabora.com>
Date:   Thu Oct 23 17:41:47 2014 +0200

    Fraction: Revert "fdo#81356: convert Fraction to boost::rational<long> - wip"
    This reverts commit 47a2d7642d249d70b5da0c330a73f3a0032e4bba.
    Change-Id: I4849916f5f277a4afef0e279b0135c76b36b9d15

If you think that an error was left when the commit was reverted please tell me.
Comment 9 Matthew Francis 2015-03-25 14:05:04 UTC
OK, so something odd is going on here.

The file did originally break at 47a2d7642d249d70b5da0c330a73f3a0032e4bba, and @Juan is quite correct that this commit was reverted at 31af61ea091cc895b893c849f2130aa35792b7db, after which the attached file works again through to libreoffice-4-4-branch-point.

The confusing part is that,
- The file still doesn't work on 4.4.[012] release
- The file does work on 4.5 master (compiled non-debug), but not on the 4.5 dbgutil bibisect tree

The latter could perhaps be explained by some peculiarity of dbgutil, but not the former
Comment 10 V Stuart Foote 2015-03-25 18:18:46 UTC
(In reply to Matthew Francis from comment #9)
> The confusing part is that,
> - The file still doesn't work on 4.4.[012] release
> - The file does work on 4.5 master (compiled non-debug), but not on the 4.5
> dbgutil bibisect tree
> The latter could perhaps be explained by some peculiarity of dbgutil, but
> not the former

Matthew, are you sure?

If so weird, because don't see labeling on Linux (RHEL/Centos 7 64-bit) with
Build ID: 48916c9b8c1363a37bf511626326ee6dc150975c
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-03-17_23:29:58
Locale: en_US

or latest
Build ID: ea59d42d2098e8be8b3ab9667922e8427ee4b714
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-03-23_03:11:47
Locale: en_US
Comment 11 Matthew Francis 2015-03-26 08:56:19 UTC
OK, so in both cases I mentioned about, a clean user profile makes the issue go away for me. (A little disappointing that such things happen, but probably not worth spending any more time on)

So, as the commit in question has been identified in comment 8, and there does not appear to be a separate bug for the regression already, setting:


@Ahamed: If you're still having issues with 4.4.x, please try starting LibreOffice with a clean user profile (by moving the old one out of the way - see https://wiki.documentfoundation.org/User_Profile ). If that doesn't work for any reason, please feel free to reopen this bug and we will investigate further.
Comment 12 Ahamed 2015-03-26 11:32:05 UTC
Hi all,
I have done the following and the status of my file is one and the same....

1. after closing all libreoffice instances, renamed the user profile folder (/home/ahamed/.config/libreoffice/4/user) to (/home/ahamed/.config/libreoffice/4/user-old)
2. restarted the LO
3. opened the SAP2.odt file wherein the form buttons are existing
4. same result

However, I have made some modifications in the file that the buttons are now coloured and help text same as the button text to identify the functions, so that I can make use of the file atleast..

Kindly attend the same...

Comment 13 V Stuart Foote 2015-03-26 12:55:41 UTC
Yes, back to new. 

I had been testing with clean profiles on new installs of master, or clearing profile to test the release builds. 

It really seems to be a break in associating fonts to the buttons (default or specific), rather than just not painting them.
Comment 14 Michael Stahl (CIB) 2015-04-15 18:56:55 UTC
4.4 branchpoint was buggy

the first good bibisect commit post revert (comment #8)

commit 1da949ef6797e95f5249072e645f9c36fe3afd45
Author:     Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
AuthorDate: Sat Nov 8 03:50:03 2014 +0000
Commit:     Robinson Tryon <qubit@runcibility.com>
CommitDate: Mon Dec 8 06:47:07 2014 +0100

    commit 6a4b976bd0818c2f60b879594d393baad9a0f346
    Author:     Stephan Bergmann <sbergman@redhat.com>
    AuthorDate: Fri Oct 24 16:10:26 2014 +0200
    Commit:     Stephan Bergmann <sbergman@redhat.com>
    CommitDate: Fri Oct 24 16:10:54 2014 +0200
        Fix Fraction(-2147483648.0) for 32-bit wide long

starting there, bibisect range:

... which contains:

commit 2ce0aededea43231d91a0955fc0676120dcc4f13
Author:     Juan Picca <jumapico@gmail.com>
AuthorDate: Fri Oct 24 11:43:52 2014 -0200
Commit:     David Tardon <dtardon@redhat.com>
CommitDate: Tue Oct 28 17:15:10 2014 +0000

    fdo#81356: use boost::rational internally in Fraction

hmm it appears it's fixed on master...

ok it was fixed on master by:

commit 2ec9d9dd81f3f4ee6785ba938f9a79395972b71e
Author:     Caolán McNamara <caolanm@redhat.com>
AuthorDate: Tue Mar 31 13:36:37 2015 +0100

    Resolves: tdf#90228 1.06 turns into a monster

not sure if this can be called a duplicate - setting it to fixed.
Comment 15 Michael Stahl (CIB) 2015-04-15 18:58:36 UTC
fix pushed to libreoffice-4-4 as commit ba672e1351b7c170aa91dc0c99ecb80d00fcdb06
Comment 16 Adolfo Jayme 2015-04-19 14:42:17 UTC
… and fast-tracked into 4.4.3 as d5fdff3e8984c40435bc1093c8ca6820bd635f5a
Comment 17 Robinson Tryon (qubit) 2015-12-17 08:48:57 UTC
Migrating Whiteboard tags to Keywords: (bibisected)