Bug 95337 - A document's default zoom level and an open sidebar
Summary: A document's default zoom level and an open sidebar
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Hardware: Other All
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Sidebar-UI-UX Zoom
  Show dependency treegraph
Reported: 2015-10-26 19:46 UTC by Yousuf Philips (jay) (retired)
Modified: 2017-11-15 20:22 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2015-10-26 19:46:03 UTC
I've noticed that if i open documents in writer that were created with a closed or hidden sidebar at a particular zoom level, when i open up the document with the sidebar open, the document normally is to large to fit, which results in having to reduce the zoom level everytime i open up the document. The only remedy would be to save the document at the reduced zoom level, but this only works on a per document bases rather than a global bases.

So i was wondering if it is possible to know whether the document was saved with the sidebar closed/hidden and then adjust the zoom level accordingly if its open when opening the doc.
Comment 1 Buovjaga 2015-11-03 09:13:22 UTC
Which particular zoom level did you use? Could not repro with 55%.

Win 7 Pro 64-bit Version:
Build ID: 37d41674c2b1a706c95c2c326cbfbd06b0c1a655
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-11-02_00:13:27
Locale: fi-FI (fi_FI)
Comment 2 Yousuf Philips (jay) (retired) 2015-11-03 14:22:07 UTC
1) Open writer with sidebar closed
2) Set zoom level so the page takes up the max width (for me it was 140% on my 1280x768 screen) it can take before the horizontal scrollbar appears
3) Type some text and save the file
4) Open sidebar
5) Reopen file
6) Notice that horizontal scrollbar has appeared and the entire page is no longer visible like it would be if the sidebar were closed
Comment 3 Robinson Tryon (qubit) 2016-08-25 05:39:20 UTC Comment hidden (obsolete)
Comment 4 Heiko Tietze 2017-09-21 13:52:57 UTC
Cannot reproduce with 5.4. The zoom factor of 120% persists for open or closed sidebars. If you still think it's an issue then I wouldn't ask for UX input. If the zoom factor should be restored it has to be done independently from the Ui configuration, meaning window size, sidebar collapsed, etc.
Comment 5 Yousuf Philips (jay) (retired) 2017-09-22 07:58:31 UTC
Still happens.

Build ID: 7315f325ff7ada3d6bd85a471058fdaeaff8cdb0
CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-09-17_06:58:21
Locale: en-US (en_US.UTF-8); Calc: group

bubli, samuel, tomaz, maxim: any thoughts on this issue?
Comment 6 Thomas Lendo 2017-09-22 13:28:57 UTC
Jay, do you mean an odd document should store the information whether e.g. the sidebar was open during saving and that this status should be restored when reopening, like PDF options?
Comment 7 Thomas Lendo 2017-09-22 13:30:07 UTC
I meant odf document (not odd document).
Comment 8 Samuel Mehrbrodt (allotropia) 2017-09-26 07:06:09 UTC
Personally I'm against modifiying the zoom factor based on whether the sidebar is open or not.

We could discuss if we want to save the state of the Sidebar in the document.

So this is an UX question, best discussed in the Design Meeting.
Comment 9 Cor Nouws 2017-11-02 10:27:15 UTC
I can reproduce the behavior that Jay describes.
But would say that there already is a solution: the Dialog Zoom & View Factor has the option 'Fit Width' which exactly does what is requested.
Comment 10 Thomas Lendo 2017-11-08 18:53:17 UTC
The UI isn't mostly saved per document (except document-specific Toolbars) as far as I know but global in user's profile. As long as there is no full concept of handling per-document UI settings I would vote against this request. Also I think users would be upset if the UI is changing when opening a new document.
Comment 11 Heiko Tietze 2017-11-15 20:22:02 UTC
We agreed in the design meeting that this issue is a WONTFIX.