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
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
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.
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.
It happens with all .doc documents, so I think I don't need to send an example.
Please do attach an example, as mentioned in comment 2, I already have an example where it works, so your input is needed.
Created attachment 86217 [details] Example .doc file
I've tested it in three computers and it happens in all of them. I just created a new .doc document as example (attached).
Set back as UNCONFIRMED because requested document has been provided. Best regards. JBF
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.
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.
Reading the title of the bug it seems that I specified from the beginning that the problem was with page width scale in particular.
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
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.
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
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?
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?
@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.
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.
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.
I can confirm this bug affects to Linux.(In reply to tommy27 from comment #19)
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 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.
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
Patches submitted: https://gerrit.libreoffice.org/13717 - export zoom type https://gerrit.libreoffice.org/13718 - import zoom type
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.
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.
The export portion was also committed to the master branch: http://cgit.freedesktop.org/libreoffice/core/commit/?id=efa21d48a0dcb46e4728a19f89d0e26587a17327 and to 4.4.0.2: http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-4&id=955994ce0e039d40c48c420c887bf68c1d766615
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]