Bug 67870 - Writer doesn't remember non numeric zoom factors in .doc files
Summary: Writer doesn't remember non numeric zoom factors in .doc files
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: Other All
: medium normal
Assignee: Justin L
URL:
Whiteboard: target:4.5.0 target:4.4.0.2
Keywords: bibisected, bisected
Depends on:
Blocks:
 
Reported: 2013-08-07 13:59 UTC by moray33
Modified: 2015-12-17 07:22 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Example .doc file (9.00 KB, application/msword)
2013-09-20 18:07 UTC, moray33
Details
screenshot of the "View/Zoom" menu (24.87 KB, image/png)
2014-10-07 05:43 UTC, tommy27
Details
zip of many doc files with various zoom levels. (8.12 KB, application/x-7z-compressed)
2015-01-01 19:35 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description moray33 2013-08-07 13:59:48 UTC
In the office, I have 3 Windows PC with LibreOffice. One of them has one directory shared and we work there from all the PCs. In that directory, from a client PC LibreOffice doesn't remember the scale of .DOC files. With .ODT and .DOCX works 'well' (I have to save it to remember a new scale as I said in the bug https://bugs.freedesktop.org/show_bug.cgi?id=67466), but it always open .DOC with 100% scale.

It worked well in 4.0
Comment 1 Jean-Baptiste Faure 2013-09-19 05:10:30 UTC
Is the zoom factor saved in the document file or in the LibreOffice config?
I looked in registrymodifications.xcu in the user profile and found only the last used zoom, not related to a particular document.

Hi Miklos, do you have an idea?

Best regards. JBF
Comment 2 Miklos Vajna 2013-09-19 08:24:26 UTC
The zoom setting is stored in the files. There are various zoom modes; in case it's explicitly set to a given percent value, then it's saved/loaded from/to doc/docx/rtf as well, see sw/qa/extras/ww8export/data/zoom.doc in core.git for an example that's working.

I would need a sample that contains the zoom value, but not loaded/saved back, then I can have a look.
Comment 3 moray33 2013-09-20 09:19:09 UTC
I've been doing some research and I've found the actual cause of the bug (it isn't what I though).

It's simply that Writer doesn't remember page width scale in .doc files (works fine in .odt and .docx). It doesn't matter if it's a local file or from a shared folder or another computer.
Comment 4 moray33 2013-09-20 09:19:42 UTC
It happens with all .doc documents, so I think I don't need to send an example.
Comment 5 Miklos Vajna 2013-09-20 15:38:12 UTC
Please do attach an example, as mentioned in comment 2, I already have an example where it works, so your input is needed.
Comment 6 moray33 2013-09-20 18:07:30 UTC
Created attachment 86217 [details]
Example .doc file
Comment 7 moray33 2013-09-20 18:08:27 UTC
I've tested it in three computers and it happens in all of them. I just created a new .doc document as example (attached).
Comment 8 Jean-Baptiste Faure 2013-11-10 15:51:42 UTC
Set back as UNCONFIRMED because requested document has been provided.

Best regards. JBF
Comment 9 retired 2013-11-23 19:38:40 UTC
Moray, a step-by-step description of how to reproduce the issue is most helpful and will help to speed up the processing of this problem a lot.

Setting to NEEDINFO until more detail is provided.

After providing the requested info, please reset this bug to UNCONFIRMED. Thanks :)

I tried reproducing the problem:

1) open test file
2) zoom to 120%
3) cmd + s to save
4) close LO
5) reopen the file

Voila: 120%. So not reproducible on OS X 10.9 with LO 4.1.3.2.
Comment 10 moray33 2013-11-24 00:00:06 UTC
Ok, I think I got it. Try to set the scale to page width and save it. I just tried with 150% and 200% and it works, but it doesn't with page width, which it's what I always tried.
Comment 11 moray33 2013-11-24 00:03:02 UTC
Reading the title of the bug it seems that I specified from the beginning that the problem was with page width scale in particular.
Comment 12 Jean-Baptiste Faure 2013-11-24 09:13:31 UTC
Ah, I understand, you mean the zoom setting "page width" (second choice in the zoom options) is not saved or honored by LibreOffice. Indeed when opening your attachment, it opens with zoom at 100% while "page width" gives 111% on my screen. This value depends on the configuration of the LibreOffice window (maximized or not, sidebar or not, etc.).

Only Miklos can say if that is a bug or not. :-)

Best regards. JBF
Comment 13 moray33 2013-11-24 12:53:36 UTC
LibreOffice saves the page width scale in .odt and .docx, and used to do it with .doc in 4.0.x and previous versions, so I'd say it's a bug.
Comment 14 Jean-Baptiste Faure 2013-12-13 17:59:36 UTC
According to comment#2 if zoom setting is not defined as a given percent value, it is not saved/loaded from/to doc. If I understand well, non numeric values like "page width" are not allowed in doc format. So it is not a bug and I will close this bug as NotABug.

@Miklos : do you agree?

Best regards. JBF
Comment 15 moray33 2013-12-13 19:37:52 UTC
As I said several times it worked in previous versions of LibreOffice, so I have to assume it saved the page width zoom setting in .doc files miraculously?
Comment 16 tommy27 2014-10-06 14:41:56 UTC
retested with LibO 4.3.2.2 under Win7x64

test .doc file zoom settings are remembered by LibO when closing and reloading the file.

you have to save the file in order to see the zoom setting level remembered at reload.

if you just open, don't edit it and close it without saving, no zoom level is remembered

@moray 
can you retest? can we label this RESOLVED WORKSFORME or do you still see an issue here?
Comment 17 moray33 2014-10-06 22:50:33 UTC
@tommy27

Have you tried zoom setting "page width" (second choice in the zoom options) specifically?
I just tried with LO 4.3.2.2 under Win7x64 and it still doesn't work.
Comment 18 tommy27 2014-10-07 05:43:35 UTC
Created attachment 107454 [details]
screenshot of the "View/Zoom" menu

@moray33
sorry I tested numeric zoom factors (i.e. 50%) which do work.

now I confirm that non numeric zoom factor like "Entire Page", "Page Width" and "Optimal View" from the "View/Zoom" menu (see attached screenshot) do not work in LibO 4.1.0, 4.3.2 and last night 4.4 master.

it worked in 4.0.6 hence is a regression of the 4.1.x branch.

non numeric zoom factors are remembered in .odt, .docx and .rtf so the bug is limited to .doc format.
Comment 19 tommy27 2014-10-07 05:47:09 UTC
actually reproducibility has been confirmed on Windows.
please Linux and Mac user retest to see if it affects all platforms.

@Joel
this one should be easy to bibisect.
Comment 20 moray33 2014-10-07 15:53:45 UTC
I can confirm this bug affects to Linux.(In reply to tommy27 from comment #19)
Comment 21 Justin L 2014-12-23 13:01:22 UTC
Bibisecting.  unconfirmed, but likely point of regression is:

author	Miklos Vajna <vmiklos@suse.cz>	2013-01-07 08:13:02 (GMT)
committer	Miklos Vajna <vmiklos@suse.cz>	2013-01-07 08:14:49 (GMT)
commit	6e9ab7e0ca443cca46cd39a313583f4b90549e1c (patch)
tree	545b9c44da8f1a24f66bf1e8eb938449f34a3915
parent	504b6f0cec5cad01a64e723434d636bfb867ecfa (diff)
WW8 filter: import zoom factor
Change-Id: I557cf89642ff618aaddb2f036652d126b25555c9 


bc5972c728e8a576b0a6e2f620f73514d32d42b6 is the first bad commit
commit bc5972c728e8a576b0a6e2f620f73514d32d42b6
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Wed Oct 16 01:49:56 2013 +0000

    source-hash-475469626b3a92528a9584d6c34f2b44b7eb8d1c
    
    commit 475469626b3a92528a9584d6c34f2b44b7eb8d1c
    Author:     Werner Koerner <wk661lo@gmail.com>
    AuthorDate: Sat Dec 29 13:53:01 2012 +0100
    Commit:     Michael Stahl <mstahl@redhat.com>
    CommitDate: Mon Jan 7 13:20:42 2013 +0000
    
        Fix calls to SfxPoolItem* Put with a Which-ID of sal_false
    
        Change-Id: I39914909fd394532e7a32c791d4480530393c1c0
        Reviewed-on: https://gerrit.libreoffice.org/1499
        Reviewed-by: Michael Stahl <mstahl@redhat.com>
        Tested-by: Michael Stahl <mstahl@redhat.com>

git bisect log
# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574
# good: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15
git bisect good 8f4aeaad2f65d656328a451154142bb82efa4327
# bad: [9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02] source-hash-8600bc24bbc9029e92bea6102bff2921bc10b33e
git bisect bad 9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02
# good: [51b63dca7427db64929ae1885d7cf1cc7eb0ba28] source-hash-806d18ae7b8c241fe90e49d3d370306769c50a10
git bisect good 51b63dca7427db64929ae1885d7cf1cc7eb0ba28
# good: [d65a58c31c8da044ef66ae4517fa2fe74cec0019] source-hash-2e053cf5ea4d93a2e1845e795a9c7fe1e08c84af
git bisect good d65a58c31c8da044ef66ae4517fa2fe74cec0019
# good: [00f5ea8ff23485332a8009f8017ae95cd5f83fa4] source-hash-4ef5ed9d21de767ce1b4c70d73cf15994b38dcdb
git bisect good 00f5ea8ff23485332a8009f8017ae95cd5f83fa4
# bad: [b9da5d7ef8baf81aa867fc44cb6d8ebb6036201b] source-hash-ec376c2934e77fd1b56da892cfe2c1393f4c8156
git bisect bad b9da5d7ef8baf81aa867fc44cb6d8ebb6036201b
# good: [a6c846ef193b8c57600975a405db417d0563d04c] source-hash-f6b4d0313dbaf1089254a1bfae9ccfbc3f413eb3
git bisect good a6c846ef193b8c57600975a405db417d0563d04c
# bad: [bc5972c728e8a576b0a6e2f620f73514d32d42b6] source-hash-475469626b3a92528a9584d6c34f2b44b7eb8d1c
git bisect bad bc5972c728e8a576b0a6e2f620f73514d32d42b6
# good: [142a2a6ac236d6e9946bfbf51b6bfcc616958e98] source-hash-540f090a68ae4375a36d0ee6dfbb4a82f28ac704
git bisect good 142a2a6ac236d6e9946bfbf51b6bfcc616958e98
Comment 22 Justin L 2014-12-31 11:22:32 UTC
Comment 14 is correct.  It did NOT really work in earlier versions. What DOES happen is that your *user profile* remembers your last zoom type (comment 1).  

Steps to prove it did not work earlier
1.)  In LO = 4.0.x, open the document and verify that it is in fit width mode.
2.)  delete your profile.  On linux, this is ~/.config/libreoffice/4/user
3.)  Open the document again.  It will open in 100% mode.

Confirmed that this "bug" was introduced by "WW8 filter: import zoom factor"
Change-Id: I557cf89642ff618aaddb2f036652d126b25555c9

The key here is Miklos' statement in comment 2 - there are various zoom modes, but ONLY the percent zoom factor setting can be saved in .doc files - not the zoom type.   .ODT and .DOCX apparently have a variable to also save the zoom type.  So the deficiency is in the Word .doc format itself.

these two settings exist in .doc files (from sw/source/filter/ww8/ww8scan.hxx):
sal_uInt16  wvkSaved : 3;     //document view kind: 0 Normal view, 1 Outline view, 2 Page View
sal_uInt16  wScaleSaved : 9;  //< Specifies the zoom percentage that was in use when the document was saved.

However, the bug author is also correct - previously when you opened up a .doc file that DID NOT specify a zoom factor, it would use your last user profile setting.  Now it ALWAYS forces 100% zoom - even though that is not specified in the document.

Ultimately, the problem is that wScaleSaved is INITIALIZED to 100 for all .docs, so even though NO SCALE FACTOR is specified in the .doc file, the initialization will force it to 100% based on the new "import zoom factor" code.

This bug can be resolved by commenting out wScaleSaved=100 in ww8scan.cxx.
Comment 23 Justin L 2015-01-01 19:35:31 UTC
Created attachment 111623 [details]
zip of many doc files with various zoom levels.

Tested Word 2003 and 2013.  Both save zoom info when exporting to .doc files, using zoom percent calculated for all types (text width, page width, whole page, many pages.)  Default page size zoom of 100% is also saved.  So, initializing the zoom to 100 for all .docs is compatible with MS Office.

Word 2013 does NOT honor the zoom type OR zoom factor when opening .doc files.  It opens all .doc files in 100% zoom.

I was wrong when I said that .doc does not have a spot to save the zoom type.  Testing shows that word 2003 can properly restore text width and page width settings from documents authored on 2013.

sal_uInt16  zkSaved : 2;        //      document zoom type: 0 percent, 1 whole/entire page, 2 page width, 3 text width/optimal
Comment 24 Justin L 2015-01-02 05:13:09 UTC
Patches submitted:
https://gerrit.libreoffice.org/13717 - export zoom type
https://gerrit.libreoffice.org/13718 - import zoom type
Comment 25 Commit Notification 2015-01-05 15:51:11 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=615ba47c5937dd62573181a0404ae24968d7daec

fdo#67870 WW8 filter: import zoom type

It will be available in 4.5.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.
Comment 26 Commit Notification 2015-01-05 17:27:07 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=42f48db159980ad30588ed1d52867afbbe9648f5&h=libreoffice-4-4

fdo#67870 WW8 filter: import zoom type

It will be available in 4.4.0.2.

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.
Comment 28 Robinson Tryon (qubit) 2015-12-17 07:22:50 UTC Comment hidden (obsolete)