High contrast incorrectly assumed

[bacloud]

Binary package hint: openoffice.org

Ubuntu 8.04 - Hardy Heron

When i change appearance in theme and i choose a color black for my window ,in Open office icons become a words but too when i choose a dark color.

ProblemType: Bug
Architecture: i386
Date: Mon May 19 16:21:45 2008
DistroRelease: Ubuntu 8.04
NonfreeKernelModules: ath_hal
Package: openoffice.org-core 1:2.4.0-3ubuntu6
PackageArchitecture: i386
ProcEnviron:
 PATH=/usr/lib/openoffice/program:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
SourcePackage: openoffice.org
Uname: Linux 2.6.24-16-generic i686

[Chris Cheney (ccheney)]

Does installing openoffice.org-style-hicontrast resolve the problem for you? I think this is an issue that the color causes OpenOffice.org to go into hicontrast mode automatically for a11y reasons.

Thanks,

Chris

[bacloud (bacloud-voila)]

Thanks my problem is resolved thanks to the openoffice.org-style-hicontrast package.

[Chris Cheney (ccheney)]

Not sure what we should do about this bug, since we don't have room to install the hicontrast package by default. I think this is a larger problem of OOo not knowing when we are actually in hicontrast mode vs just having a dark theme.

[Ne0 (prasanaik)]

More detail..
Follow these steps to reproduce bug.
Customize lets say the standard human theme.
Go to the colours tab - and select the window background colour.

Now in the RGB values - bring all the 3 values to 39. Click ok. Now look at the openoffice window (if running in the background). Still has the human icons.

Now go back to the Colour tab - bring all 3 values to 38 or lower. And go back to the openoffice window - u will see the change.

That's not supposed to happen. I don't openoffice to decide which icons to use based on the background colour.
So either this is a bug - or a stupid feature which I want changed.

Hope this info helps somehow...

[Chris Cheney (ccheney)]

Yes, this is a well known issue with OpenOffice.org.

[Kasper Johansen (kaspernj)]

Wouldnt it be an idea to have a tool to force OpenOffice to use a specific skin, since it doesnt support the dark ones very well?

Like a small program that implements the fix described in the duplicate here:
https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/250921

It is extremely annoying that OpenOffice almost becomes un-useable when using a dark theme.

Also make the same program apply to Firefox, making it possible to manually creating userContent.css and userChrome.css, without having to go into a terminal.

[Daniel LaGesse (dlagesse1992)]

Is there any, even temporary, fix for this? I'm using Hardy, and the fix proposed in the duplicate didn't work for me. I hate the high-contrast theme, and would like to have my icons back...

Thanks,
Daniel LaGesse

[Kasper Johansen (kaspernj)]

Hi Daniel.

Yes there is - and it is very easy!

Write this in a terminal:
sudo gedit /usr/lib/openoffice/program/soffice

Then insert a new first line and write this on it:
export GTK2_RC_FILES=/usr/share/themes/Clearlooks/gtk-2.0/gtkrc

The save it and close gedit.

Make sure that every OpenOffice-application is shut down. Then try to start a new one to see if it works.

[jscc88 (jscc88-deactivatedaccount)]

click in sistem,administration, controlators. here in controlator you can add the driver that here appear. its is your problem

[penalvch (penalvch)]

bacloud, does libreoffice-style-hicontrast work for you?

[Björn Michaelsen (bjoern-michaelsen)]

[This is an automated message.]
There are no new official OpenOffice.org releases in Ubuntu packaging anymore => Won't Fix

If the problem persists, please mark this bug as "also affects project Libreoffice" or "also affects distribution Libreoffice (Ubuntu)" if that has not happened already.

Please leave references to upstream OpenOffice.org bugs in place to allow cross pollination.

[Björn Michaelsen (bjoern-michaelsen)]

removing remote tracker for bug 35482 as it seems unfixed in OOo too: https://issues.apache.org/ooo/show_bug.cgi?id=35482

[Nicciglen (nicciglen)]

Writer no longer overrides the displayed document background and font colours with a Windows High Contrast Theme's colours. This is with LibreOffice v4.1.2.3 installed on Windows 7 SP1 x64.

Previous versions of LibreOffice Writer (4.0 and below) correctly override the background and font colours of any document with those set in a Windows High Contrast colour theme. In LibreOffice 4.1 this is no longer the case. I have tested an older version of LibreOffice Writer, v3.5.5.3, and this version does indeed override the document background and font colours as expected with those from the theme.

This functionality is very important for me, as I have a light sensitivity problem with my vision called Visual Stress or Meares-Irlen Syndrome, which means (in my case) I need a black background and a very specific font colour (RGB value) in order to read comfortably. In Windows I use a High Contrast colour theme with these colours, and most windows applications honour them.

LibreOffice settings:
Under Options-LibreOffice-Accessibility under "Options for High Contrast appearance" - I have all the options ticked.

Under Options-LibreOffice-Appearance-Custom Colors

- version v4.1.2.3: Automatic document background colour is "white" - (seriously bad for people with Visual Stress/Mearles-Irlen Syndome). It should be "black" as per my High Contrast theme background.
- version v3.5.5.3: Automatic document background colour is "black" as expected, as per my Windows High Contrast theme.

- version v4.1.2.3: Automatic document font colour is "black". It should be the colour as per my High Contrast theme's font colour (mine is a specific green RGB value which needs to be precise. None of the custom colours in the drop down list fulfill my needs).

- version v3.5.5.3: Automatic document font colour is the same as from my Windows High Contrast theme.

To test this, set Windows 7 to High Contrast mode through the Ease of Access Centre and select either high contrast themes #1 or #2 (I have my own custom high contrast colour theme set up, but those will suffice for the test). Then start up LibreOffice Writer 4.1 and you will see that even with all the Accessibilty options for High Contrast ticked, all documents still have a white background and black text. Try again with Writer v3.5.5.3 and it will honour the High Contrast Theme's colours by overriding the displayed document colours with them.

Please fix this very important accessibility bug for folk with visual impairments e.g. visual stress or mearles-irlen syndrome where colour is very important.

Thanks

[Nicciglen (nicciglen)]

This is a serious accessibility bug (when using Writer on Windows) for folk with visual impairments who use a Windows High-Contrast Colour theme and need specific background and text colours to read comfortably. It looks as if this bug was introduced in LibreOffice 4.1. It definitely doesn't occur with LibreOffice 3.5.

[Bfo-bugmail (bfo-bugmail)]

Potential duplicate of bug 64842.
Adding bdrung and bjoern.michaelsen to CC list as this patch is a potential culprit https://gerrit.libreoffice.org/#/c/238/ (sorry for misinterpretation if any).
Please evaluate and comment. Thanks.

[Nicciglen (nicciglen)]

> Potential duplicate of bug 64842.
Yes, this does look like a potential duplicate. But since bug 64842 was filed against Ubuntu and not Windows, I wouldn't be sure that the fix for that one would fix the similar problem on windows. The offending code for each OS may be slightly different.

I've read the comment for change Ia42ca7882f0d2dd1f2a304db5e4b5aaba23244fc. This change introduces a serious accessibility flaw for folk with a vision disability. I can no longer use later versions of LibreOffice because of this. As a developer myself, I would have said that a better fix for the problem would have been to correctly detect when Open Office / LibreOffice has been set to work in accessibility mode and when so, for the displayed document colours to inherit from the underlying high-contrast theme accordingly. When LibreOffice is not in set in accessibility mode, then by all means default to other more appropriate display colours for the document.

It appears the developer of the patch may misunderstand why (at least in Windows) the High-Contrast themes exist and how visually impaired people like myself benefit from them.

Various partially sighted or blind people and folk with other visual impairments benefit from a custom text foreground and page background colours. Setting the host OS to a high-contrast accessibility theme should trigger all applications to inherit that theme. There are of course some offending applications in Windows that don't this, but most do. Open Office / LibreOffice has been particularly good at this in the past - and has been especially useful to people with a vision disability with it's ability to adapt to document display colours accordingly when accessibility is set to on (this is now broken). This has been singly the biggest winning feature for which why I choose OpenOffice/LibreOffice over Word.

I suffer from a light sensitivity disorder called Visual Stress for which white / light backgrounds on paper and computer screens cause considerable discomfort and migraines. This disorder affects 15 - 20 percent of the population at varied levels of severity from very mild to extreme. Is is also known as Meares-Irlen Syndrome or just Irlen Syndrome. Colour is of extreme importance for these people to be able to see and read comfortably. We rely on high-contrast OS themes to get around the problem to some extent. White background documents and UIs cause these people a multitude of debilitating symptoms including migraines, not being able to think straight, loss of some co-ordination, irritability, nausea and quite a few others - different for each individual.

Please honour high-contrast themes in Windows. They are there for a reason.

In sort, please restore LibreOffice's ability to adhere a document's displayed colours to the underlying high-contrast theme, when the applicable accessibility settings have been set in the application's preferences.

[Krebser69 (krebser69)]

Actually, the bug occurs when I load the context help module package to
work with the software.

I uninstalled the HELP stuff by doing a System Restore and got my
Windows Aero feature back. I am able to use the software suite with no
problem.

Elmer

On 11/25/2013 11:40 AM, <email address hidden> wrote:
>
> *Comment # 3 <https://bugs.freedesktop.org/show_bug.cgi?id=71511#c3>
> on bug 71511 <https://bugs.freedesktop.org/show_bug.cgi?id=71511> from
> <email address hidden> <mailto:<email address hidden>> *
> > Potential duplicate ofbug 64842 <show_bug.cgi?id=64842>.
> Yes, this does look like a potential duplicate. But sincebug 64842 <show_bug.cgi?id=64842> was filed
> against Ubuntu and not Windows, I wouldn't be sure that the fix for that one
> would fix the similar problem on windows. The offending code for each OS may be
> slightly different.
>
> I've read the comment for change Ia42ca7882f0d2dd1f2a304db5e4b5aaba23244fc.
> This change introduces a serious accessibility flaw for folk with a vision
> disability. I can no longer use later versions of LibreOffice because of this.
> As a developer myself, I would have said that a better fix for the problem
> would have been to correctly detect when Open Office / LibreOffice has been set
> to work in accessibility mode and when so, for the displayed document colours
> to inherit from the underlying high-contrast theme accordingly. When
> LibreOffice is not in set in accessibility mode, then by all means default to
> other more appropriate display colours for the document.
>
> It appears the developer of the patch may misunderstand why (at least in
> Windows) the High-Contrast themes exist and how visually impaired people like
> myself benefit from them.
>
> Various partially sighted or blind people and folk with other visual
> impairments benefit from a custom text foreground and page background colours.
> Setting the host OS to a high-contrast accessibility theme should trigger all
> applications to inherit that theme. There are of course some offending
> applications in Windows that don't this, but most do. Open Office / LibreOffice
> has been particularly good at this in the past - and has been especially useful
> to people with a vision disability with it's ability to adapt to document
> display colours accordingly when accessibility is set to on (this is now
> broken). This has been singly the biggest winning feature for which why I
> choose OpenOffice/LibreOffice over Word.
>
> I suffer from a light sensitivity disorder called Visual Stress for which white
> / light backgrounds on paper and computer screens cause considerable discomfort
> and migraines. This disorder affects 15 - 20 percent of the population at
> varied levels of severity from very mild to extreme. Is is also known as
> Meares-Irlen Syndrome or just Irlen Syndrome. Colour is of extreme importance
> for these people to be able to see and read comfortably. We rely on
> high-contrast OS themes to get around the problem to some extent. White
> background documents and UIs cause these people a multitude of debilitating
> symptoms including migraines, not being able to think straight, loss of some
> co-ordination, ...

[Bfo-bugmail (bfo-bugmail)]

@<email address hidden>: did you posted about this on Accessibility, UX-Advise or Dev lists (http://nabble.documentfoundation.org/LibreOffice-f1639495.html)? I have to admit that this bug is the first place where I've read about Visual Stress or Meares-Irlen Syndrome and surely will link to it every time someone will file a bug about changing default UI color settings.

Also adding <email address hidden> to CC list who contributed a patch in this area (http://cgit.freedesktop.org/libreoffice/core/commit/?id=0acdeacbe774b7e05323ad80b556e7102a083192) asking for evaluation and comment.

[Nicciglen (nicciglen)]

@bfoman: Thanks for the heads up on those mailing lists. I wasn't aware of the UX-Advice and Accessibility mailing lists. I will most likely post to them in due course. UI developers need to be aware of these accessibility issues for visually impaired users.

Default UI colours are fine, as long as two things are taken into consideration.

1. Enabling overriding UI colours with the underlying Accessibility theme of the host operating system, if one is active. LibreOffice has done this well in the past. Now it is broken in this respect.

2. Enabling visually impaired users to customise to UI look and colours as much as possible. In the specific case of visual stress/irlen syndrome, being able to customise colours (especially background and text colours) to precise RGB values is very important.

Hard coding a white background in a UI is one of the worst things a UI developer can do for those with Visual Stress.

[Benjamin Drung (bdrung)]

The change from [1] may caused this bug. To quote the reason for this change: "The font and document color of a Writer document or an Impress presentation
should not be derived from a desktop theme. A Writer documents needs to look
good on paper. An Impress presentation may have it's own theme. The appearance
of a document should not change by changing the desktop theme."

The accessibility options should allow violating the rule stated above. It should be possible to override the document/presentation colors by the hight-contrast color schema.

[1] https://gerrit.libreoffice.org/#/c/238/

[Nicciglen (nicciglen)]

To add to Benjamin Drung's previous comment: The LibreOffice Options under LibreOffice / Accessibility are there for a reason. Up until relatively recently the behaviour of Writer (when these options are set) was to detect under Windows (at least) when a high-contrast OS accessibility colour scheme was being used and then override the displayed document colours accordingly. Please restore this important functionality to help people with visual impairments use LibreOffice.

Does anyone know When is this important accessibility bug going to be fixed? If I was a C++ developer myself I would help out and fix it, but alas I am not.

To understand why this kind of thing is important please look at the EU Mandate 376 at <http://www.mandate376.eu/> regarding regulations and standards in the EU covering ICT Accessibility requirements.
See the standard EN 301 549 "Accessibility requirements for public procurement of ICT products and services in Europe" at <http://bit.ly/1idBi9Z>

[Bfo-bugmail (bfo-bugmail)]

Adding Robinson Tryon from QA team who can escalate this as CCed developers did not comment the issue.

[Qubit (qubit)]

(In reply to comment #8)
> To add to Benjamin Drung's previous comment: The LibreOffice Options under
> LibreOffice / Accessibility are there for a reason. Up until relatively
> recently the behaviour of Writer (when these options are set) was to detect
> under Windows (at least) when a high-contrast OS accessibility colour scheme
> was being used and then override the displayed document colours accordingly.
> Please restore this important functionality to help people with visual
> impairments use LibreOffice.

Question: When did the behavior change?

We could try bibisecting on GNU/Linux, but only if the high-contrast theme detection worked there as well. Nicciglen -- Do you know?

---

Sounds like general agreement on this problem, so Status -> NEW
Whiteboard: a11y BibisectRequest

[Björn Michaelsen (bjoern-michaelsen)]

So yes, this is likely caused by https://gerrit.libreoffice.org/#/c/238/. We could:
1/ simply revert that and have LibreOffice behave as needed for accessibility
2/ keep that and only behave as needed for accessibility when "automatically detect high contract mode of operating system" is checked in the options.

For 2/, here is a an example of how to read that value: http://opengrok.libreoffice.org/xref/core/vcl/source/window/window.cxx#636

Im not convinced that that is the right way to go: We are mixing two usecases here: a/ accessibility and b/ people using a dark desktop theme without a need for accessibility.

Ultimately, IMHO what we really need is a dark theme no-accessibility theme, so that we can keep these too apart.

[Qubit (qubit)]

(In reply to comment #11)
> 2/ keep that and only behave as needed for accessibility when "automatically
> detect high contract mode of operating system" is checked in the options.
> ...
> Im not convinced that that is the right way to go: We are mixing two
> usecases here: a/ accessibility and b/ people using a dark desktop theme
> without a need for accessibility.

Agreed. I'm not sure we can automatically determine correct LibreOffice behavior based on the colors of the desktop theme.

>
> Ultimately, IMHO what we really need is a dark theme no-accessibility theme,
> so that we can keep these too apart.

I'm not sure what you mean. The simplest solution in my mind would be to have an (accessibility) option "Use/inherit colors from desktop theme".

[Libreoffice-commits (libreoffice-commits)]

Bjoern Michaelsen committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7b0e8b9c8541250be65ce228b67ff5adb105b732

fdo#71511: in autodetected a11y HC mode, pull background color from theme

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.

[Björn Michaelsen (bjoern-michaelsen)]

Commit backported to -4-2 as:

 https://gerrit.libreoffice.org/#/c/7484/

and waiting for review. Note that this needs a LibreOffice restart after changing "Tools->Options->A11y->automatically detect high contract mode of operating system" to take effect.

[Nicciglen (nicciglen)]

> in autodetected a11y HC mode, pull background color from theme

Thanks for looking into fixing this bug.

HOWEVER please NOTE: When a11y HC mode is detected, *both* the text colour and background colour need to be pulled from underlying OS theme.

> - dark theme default to high contrast
> - as per fdo#35365, having a dark document background is
> inconvenient for non-a11y endusers
> - a11y standard require the (rather ugly) background for a11y
> - thus, when "automatically detect high contract mode of operating system" in > Tools->Options->a11y is enabled, use the dark document background by
> default, otherwise use a white default

From the code commit comment, I'm not sure if the requirements for this a11y feature have been fully understood.

A high-contrast theme - doesn't necessarily need to have a dark background. It can have any background colour or text colour combination that a partially sighted user finds easier to see. It could be say bright orange background with black text.

The point is that Windows (and I'm sure Linux) can have several high-contrast themes, where the background colour can be anything and the foreground colour can be anything that is beneficial for the partially sighted user.

In summary, as long as you are pulling *both* the background and foreground colours from the OS a11y theme, when an OS high-contrast theme is detected - then you are restoring the functionality that LibreOffice / Open Office have had for a very long time.

(PS. Yes, high-contrast themes may look ugly to non-a11y users, but they are a life-changing enabler for people with various vision problems)

[Nicciglen (nicciglen)]

@Qubit

> Question: When did the behavior change?

I can't pinpoint exactly, but in my original bug description I noted the version where the problem occurs, and a previous version where the problem doesn't occur. So it was introduced (on Windows) somewhere after v3.5.5.3 up to and including 4.0.

> We could try bibisecting on GNU/Linux,
> but only if the high-contrast theme detection worked
> there as well. Nicciglen -- Do you know?

Sorry, I haven't tried LibreOffice on Linux for quite a long time.

[Libreoffice-commits (libreoffice-commits)]

Bjoern Michaelsen committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7f7a0275be241b8a5e1d1cda0a1da613e3af61d3

fdo#71511: reload ColorConfig after tweaking relevant a11y settings

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.

[Björn Michaelsen (bjoern-michaelsen)]

this one was a regression by fdo#35365 introduced with 4.0/3.6.6 affecting all platforms on all archs and is fixed now on master.

@nicciglen: Dont featurecreep this bug, this one is about the background colors regression, for everything else please file a new, well-scoped bug (see LibreOffice bug handling guidelines).

[Krebser69 (krebser69)]

All right already!!

I got the message 30 f*&king times!

Take me off the damn Cc list.

On 1/16/2014 2:12 PM, <email address hidden> wrote:
> V Stuart Foote <mailto:<email address hidden>> changed bug 71511
> <https://bugs.freedesktop.org/show_bug.cgi?id=71511>
> What Removed Added
> See Also https://bugs.freedesktop.org/show_bug.cgi?id=64842
>
> ------------------------------------------------------------------------
> You are receiving this mail because:
>
> * You are on the CC list for the bug.
>

[Vstuart-foote (vstuart-foote)]

@Bjoern,
(In reply to comment #18)
> this one was a regression by fdo#35365 introduced with 4.0/3.6.6 affecting
> all platforms on all archs and is fixed now on master.

Thanks for the heads up in http://cgit.freedesktop.org/libreoffice/core/commit/?id=7f7a0275be241b8a5e1d1cda0a1da613e3af61d3 about the icons being hard set. I'd toggled the setting recently following a Accessibility ML session, and couldn't revert. It is simplest to clear per-user profile to get back to default icons.

>
> @nicciglen: Dont featurecreep this bug, this one is about the background
> colors regression, for everything else please file a new, well-scoped bug
> (see LibreOffice bug handling guidelines).

Not so sure it is creep. As @nicciglen mentioned in the OP, for A11Y the requirement is for high contrast (HC) between background and foreground. So with background settings no longer automatic--if the foreground color 'automatic' selection happens to pick a low contrast color pair, the document will be unreadable by those needing HC asssitive technology.

Best case would be pick up both OS background and foreground colors as set by OS in HC mode. But at a minimum would need to set a HC foreground color complementary to what ever background color is being set. Can the background color algorithm be adjusted to select a complementary foreground color?

[Vstuart-foote (vstuart-foote)]

Verifying fixed on Windows 7 sp1, 64-bit with todays TB 39 build of master
Version: 4.3.0.0.alpha0+
Build ID: 12ca5ec6f4485ab8c837d32eefdf39a2dda025a4
TinderBox: Win-x86@39, Branch:master, Time: 2014-01-17_02:58:58

With the Tools -> Options -> Accessibility: Options for high contrast appearance checked on.

The background and foreground font colors are following the system HC modes set from Windows 7 Ease of Access Center. Tested the High Contrast#1, High Contrast #2, and High Contrast White color offerings. LibreOffice color selections matched all well.

However, as noted...when toggling HC mode off the LO component icon sets do not revert to non-HC defaults as was commented.

=-=-=

Verifying fixed on Centos 6.4, 64-bit with todays TB 46 build of master
Version: 4.3.0.0.alpha0+
Build ID: 12ca5ec6f4485ab8c837d32eefdf39a2dda025a4
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-01-17_02:58:10

With the Tools -> Options -> Accessibility: Options for high contrast appearance all checked on.

Both the High Contrast, and High Contrast Inverse OS themes both were picked up in LibreOffice.

A bit limited, so increased contrast could be obtained changing the Tools -> Options -> Appearance: Custom colors -- Font color.

And, when toggling back to default System theme, component icons also do not revert to non-HC defaults.

[Vstuart-foote (vstuart-foote)]

*** Bug 64842 has been marked as a duplicate of this bug. ***

[Björn Michaelsen (bjoern-michaelsen)]

(In reply to comment #20)
> @Bjoern,
> Best case would be pick up both OS background and foreground colors as set
> by OS in HC mode. But at a minimum would need to set a HC foreground color
> complementary to what ever background color is being set. Can the background
> color algorithm be adjusted to select a complementary foreground color?

AFAICS this is what is done now, as we are not only getting the background (DO_COLOR), but also the foreground (FONTCOLOR) from the theme (see commit diff).

[Libreoffice-commits (libreoffice-commits)]

Bjoern Michaelsen committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=23221e48495262d0384c9169a0d8a01db8a5dab5&h=libreoffice-4-2

fdo#71511: in autodetected a11y HC mode, pull background color from theme

It will be available in LibreOffice 4.2.1.

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.

[Björn Michaelsen (bjoern-michaelsen)]

Should behave as per fdo#71511 and friends this is required behaviour for a11y when "automatically detect high contract mode of operating system" is enabled in the options.
see also:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=7b0e8b9c8541250be65ce228b67ff5adb105b732
https://gerrit.libreoffice.org/#/c/7484/

Closing as fix commited (for upstream 4.2.1)

[Björn Michaelsen (bjoern-michaelsen)]

4.2.1 is in trusty.