Created attachment 44091 [details]
05 Orfanosentel bug.doc
Downstream bug may be found at:
1) lsb_release -rd
Description: Ubuntu 10.10
2) apt-cache policy libreoffice-writer
*** 1:3.3.1-1ubuntu3~maverick1 0
500 http://ppa.launchpad.net/libreoffice/ppa/ubuntu/ maverick/main i386 Packages
3) What is expected is when one performs at the Terminal:
cd ~/Desktop && wget https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/626827/+attachment/1871555/+files/05%20Orfanosentel%20bug.doc && lowriter -nologo 05\ Orfanosentel\ bug.doc
Click File -> Save As -> File name: 05 Orfanosentel bug.doc -> File type: Microsoft Word 97/2000/XO (.doc) -> Save button -> Yes button -> Keep Current Format button -> close the document -> reopen the document the headers remain as they were when first downloaded.
4) What happened instead is that the header from the first page is inserted in the header of all subsequent pages.
Yes, can reproduce. After saving, the page style "First Page" seems to be renamed to "Default" and used for all pages, and the original "Default" page style forgotten. For Cedric?
In Writer 3.4.4 Win 7 (64-bit) the first page is set as first page the rest as default. The problem is that the following pages uses different odd/even page setups and on export to doc I'm left with no header at all on these pages.
Should I create a new bug since the bug discription isn't quite correct anymore?
Similar problem or duplicate:
Bug 34147 - Writer FILESAVE: "First page" style created by Writer lose the page style
Still reproducible on Version 220.127.116.11 (Build ID: 932b512).
Steps to reproduce:
1. Open new writer file, make sure it has more than one page.
2. Add header/footer with a page number (just as an indicator).
3. Change first page style
4. save as doc file and reopen the file.
All pages style is as the first page.
An important issue, of course. But why is this a “3.6 most annoying bug”, if it is reproducible since 3.3.1?
Quoting from #44446
"This is the Meta issue to track most annoying bugs for the release of
LibreOffice 3.6.x releases. It helps developers to concentrate on bugs that are important for users."
So this is quite impotant for users, and I got several complaints from people for whom this issues prevents them from using LibO, as they can't edit doc files. Most of them were lawyers who tried to prepare a contact, which got "ruined" each time they saved to send the comment to the other side.
@ Lior Kaplan:
Sorry, my question was ambiguous ;-) I did not want to deny that this is a most annoying bug; you are completely right that this issue is very important.
I just wanted to suggest that it belongs to the “3.5 most annoying bugs” list, not to the “3.6 most annoying bugs” list, because we have the convention to add a bug only to one MAB list, i.e., to the oldest applicable one (cf. http://wiki.documentfoundation.org/Most_Annoying_Bugs). That’s all, sorry for the confusion.
I have to admit that this question will be obsolete soon, because the 3.5 MAB list will be probably closed in the near future, and all remaining bugs will be moved to the 3.6 MAB list. So we can leave this bug on the 3.6 list, OK.
From where I sit this is a 'Most Annoying LibreOffice Bug' (MALOB?).
Our UK Charity has run 100% open source from day one. Since docx import / export is not yet functional, the only way we have of interfacing with the outside world in terms of group development of documents is doc files. This is sufficiently common a requirement in our world that all our admin machines (except for mine) are set to save writer files to doc format by default.
I am keen to upgrade to LibreOffice for features like the improved print dialogue and eventually to get a workable level of docx support. (Obviously the moment you get good support for docx Microsoft will move the goalposts yet again with a 'new' docx format the same way they do whenever they need another injection of cash. However, the docx issue is only really coming to the fore over the last year or so - despite the existence of the first version for many years now, most of the documents we get in the charity sector are still doc format.)
Our current best handling for docx is to get it coverted to doc online by the likes of zamzar.com, or to request a copy in doc format from the sender. We then use doc format or pdf for any documents we return. The doc handling in OpenOffice 3.3 is a bit squiffy - you end up with all sorts of 'Convert 1' page styles and so on, but the end results are usable. Thus, I am still deploying new installations of OpenOffice 3.3 for use by our staff and volunteers (two new ones just yesterday)
The typical business report has a cover page, overview, table of contents and a dozen or so pages of stuff. The cover usually has a different page style than the rest - often no header or footer - then the rest often has a common style with say a descriptive header and a page-numbery, doc-referency sort of footer running throughout. The support for this within LibreOffice is nothing short of excellent, with the 'First Page' style being inherently followed by the 'Default' style. The new direct access to headers and footers right there on the page saves a lot of dialogue box interaction. - I've just made an empty report as I've been typing this and LO 3.6.3 really is superb for this sort of task. I can import graphics and pictures, size 'em and stick 'em just where and how I want on the page, wrap the text around and when I'm done I can even spit out a pdf with just a couple of mouse clicks. Better yet, I can paste tables of live data straight out of our MySQL database, and even edit any data errors I spot right there through the query in the data sources window on the fly (bet you didn't know that). 'Selling' LO to our staff and volunteers will be easy. All I need right now is a way of sending a readable, editable version to someone out in the real world...
It seems to me that the most important applications under any OS are web browser, email client and office suite. Firefox and Thunderbird are both really impressive, well supported and stable. Without a functioning office suite any OS is nowhere in the global scheme of things. LibreOffice is very nearly there now. Obviously there will always be bugs of some sort or another, but right now support for doc is the Achilles' Heel.
@ Writer Experts:
Hi Cédric, Michael (Stahl), and Miklós,
I know you have much important work to do, and do not need additional work, but Ian~G has given a brilliant explanation here
why this bug is especially important not only for interoperability with MS Office, but even for the distribution and success of LibreOffice. This is one of these bugs which make it really hard to convert people to LibreOffice, as Ian~G has explained convincingly.
So please have a look at this issue. Thank you very much!
@ Michael Meeks:
I CC you because of the importance of this bug for the migration of users
[I ping our Writer developers about this bug again, in spite of it is already “assigned” to Cédric, because (a) this assignment was not done by Cédric himself, and he did not set the status to ASSIGNED, i.e. has never “accepted” the bug,
and because (b) there are far too much old bugs “assigned” to Cédric, including many minor ones -- it is impossible that he could handle them all ;-).]
Created attachment 68836 [details]
simple two page document
Created attachment 68837 [details]
simple two page 'doc' ument
attached two files
test header footer.fodt
test header footer doc.fodt
create a simple document two pages, no header/footer on first page and a simple header and footer on default style for page two.
save it as a .fodt
then save it as a .doc
reopen the .doc and save it as a .fodt
open both in a text editor and scroll way down:
<style:master-page style:name="Standard" style:page-layout-name="pm1">
<style:master-page style:name="First_20_Page" style:display-name="First Page" style:page-layout-name="pm2" style:next-style-name="Standard"/>
<style:master-page style:name="Standard" style:page-layout-name="pm1"/>
<style:master-page style:name="First_20_Page" style:display-name="First Page" style:page-layout-name="pm1" style:next-style-name="Standard"/>
I can't tell if the problem occurs on the initial export to .doc or on the import as I don't have any M$ software, but setting the First Page style to pm1 obviously breaks the document.
May also have something to do with bug 47838
Do you know if this is a regression, I mean if in older LO/OOo versions this ever worked properly?
If you look at an OOo 3.3 doc file exported from an odt it changes the styles to:
'default' for the first page (was OO first page)
'convert 1' for what was OO default (viz the rest of the document)
this as I said before 'kind of works' in that we don't get wtf? kind of responses back from people we send the files to. If you export them to doc and re-open them they look the same. Again as I said before our admin machines are all set to .doc format by default. They all run either openoffice 3.2.1 or 3.3
My first experience of libreoffice was with ubuntu 11.04. It was sufficiently broken - especially in combination with the natty interface that I ran a mile...
the whole page styles thing has 'always' (to my perception) been very messy. problem is the most real nuts and bolts experience I have is in base (cos that was the messiest element of OOo, and the bit I most needed to work at the time). I can tell you for sure that the report wizard templates are completely screwed with regard to page one / default- and this is staying within OO file formats. I mean for example they give you an A4 page for page one and then the rest is all US letter - that kind of thing. It is easy to 'fix' as a user by editing the template files. If you know where to find them!
best answer I can give you is yes it worked up to OOo 3.3, but 'properly' would be a bit of a stretch.
and, again, thanks to you guys for sorting this.
What is interesting: I can reproduce this bug (using second attachment) only beginning from 3.5.0 version. Versions LO 3.4.2, 3.3.2, OO 3.2.1 export to doc correctly.
So, according to my measurments, it is regression beginning from 3.5.0
And this is fileexport bug. msWord2003 opens produced doc exactly as Writer
This is no longer reproducible via steps in Description https://bugs.freedesktop.org/show_bug.cgi?id=34984#c0 . RESOLVED WORKSFORME.
Description: Ubuntu 12.10
apt-cache policy libreoffice-writer
*** 1:3.6.2~rc2-0ubuntu3 0
500 http://archive.ubuntu.com/ubuntu/ quantal/main i386 Packages
Still borked here LO 18.104.22.168 on ubuntu 12.04 LTS 64 bit
Also borked on (older) LO 3.6.2~rc2 latest release on ubuntu 12.10 64 bit
- incidentally, during the course of testing I had to disable the global menu which was acting up big time; items like 'save as' not working by mouse, and whole menu glitching in and out. I tested both with and without the global menu though and got the same results both times. Global menu no issue for me since I disable it completely as a matter of course. I find unity is quite nice to use without this irritating feature...
From memory, I don't think this is a 64 bit issue. Only thing I can think is I put page number of count in the default footer - maybe this makes a difference.
Hope I'm not overstepping the mark by marking this reopened.
do you have lo-menubar package installed? If yes, could you uninstall it and try again?
Could you also test after having renamed your LO profile?(see http://wiki.documentfoundation.org/UserProfile)
Ian~G, regarding your comments https://bugs.freedesktop.org/show_bug.cgi?id=34984#c17 :
>"Still borked here LO 22.214.171.124 on ubuntu 12.04 LTS 64 bit Also borked on (older) LO 3.6.2~rc2 latest release on ubuntu 12.10 64 bit"
With what document is this reproducible in specifically?
>"- incidentally, during the course of testing I had to disable the global menu which was acting up big time; items like 'save as' not working by mouse, and whole menu glitching in and out. I tested both with and without the global menu though and got the same results both times. Global menu no issue for me since I disable it completely as a matter of course. I find unity is quite nice to use without this irritating feature..."
Please do not amalgamate multiple issues into a report. This report only focusing on the problem originally reported in the Description:
Thank you for your understanding.
"do you have lo-menubar package installed? If yes, could you uninstall it and try again?"
I was surprised to see LO menubar was not installed. This was a default 12.10 install. I just let it all install and ran it raw. Thought I'd give the global menus one last shot. You know how it is when you develop a dislike of something, you can get a sort of preconception that you don't like it for what turns out to be no real reason in the end?
So, 12.10 default install. Global menus definitely very squiffy, even after logout / reboot / full update the whole nine yards. Some items (sorry only one specific from memory - the save as - there were several more) simply no function from the mouse. The menu 'accepted' the item - ie disappeared - but no function occurred.
Thing is you're asking me to reinstall the only bit of unity that is actually duff... Still I'm an even handed sort of geezer, so I'll give it a go, but I'm going flying tomorrow, so short delay.
more important though is the .doc bug in LO... - regardless of OS
I must recognize I didn't understand your last comment. Certainly because I don't use Ubuntu, global menu, lo-menubar... I'm just on Debian testing with Gnome.
So let it drop.
What about the profile part of my previous comment, did you test?
"I must recognize I didn't understand your last comment. Certainly because I don't use Ubuntu, global menu, lo-menubar... I'm just on Debian testing with Gnome.
So let it drop.
What about the profile part of my previous comment, did you test?"
No worries Julian - and nicely phrased - lets get this fixed.
I always scrub the old profile before the new install. I am installing generally from the LO download, except for the 12.10 install we just discussed which was from the ubuntu repos and on a brand new 12.10 install.
I have been dropping some of the files from the install. Like KDE stuff, Report Builder (ugh!), french dic and espanish dic.
ok, thank you for your feedback so put it back to "REOPENED". I'm a bit stuck here :-(
Julien Nabet, please stop toggling this report. As I am the original reporter, and my original problem noted in the Description is no longer reproducible, this is RESOLVED WORKSFORME as per https://bugs.freedesktop.org/show_bug.cgi?id=34984#c16 , and lack of response from https://bugs.freedesktop.org/show_bug.cgi?id=34984#c19 . If you have a bug in LibreOffice, please file a new report.
Thank you for your understanding.
"With what document is this reproducible in specifically?"
Apologies for not responding to your question
Any document. All documents. I have provided example files earlier at #10 and #11.
Basically, open LibreOffice
change page style to First Page (with no header or footer)
add some text like 'this is the first page'
ctrl enter for a hard page break
add a header to page two like 'Default Header'
add some text like 'this is page two' to the page body
add a footer to page two like 'Default Footer page <insert> <fields> <page number>'
<file><save> name it 'testfile.odt'
then <file><save as> and save it as a MS word 97/2000/xp/2003 doc file 'testfile.doc'
reopen the new doc file by double-clicking it and
presto! no headers or footers anywhere to be seen
Again apologies for not responding to your question earlier and for any incorrect usage of this bug reporting system. Also my intention was not to amalgamate any multiple issues, but to provide additional info on my particular installations in case there was some significant difference which could be identified between our systems / installs which might establish how it could be working for you and broken for the rest of us.
It would really help if you could run through the procedure above to establish for sure that you get headers on page two and none on page one in the resultant .doc file. It only takes a few minutes - much less time than it took me to type this lot. If it works your end I will do a full reinstall of 12.10 ubuntu i386 on my spare 64bit machine (currently running 12.10 64bit) and see if it works ok here.
Does this being marked resolved mean the issue is closed and we must now start a new bug report in order to get it fixed?
It is such an important issue. Why is it a problem to leave it open?
OK I've got a workaround.
Create a document that consists of just the body of your report all in default style with header and footer, page numbers etc throughout. Save it as a .doc file NOT .odt say 'reportbody.doc' Close LO.
Now create a new document in First Page style with no header or footer. Type 'report name no header or footer' then ctrl enter to hard page break into page two. Now <insert> <file> and put your report body file in here. Save the whole lot now with a name like finishedreport.doc and close LO.
Open the finished report and bingo! it works. The pages from an inserted doc file get imported into Convert 0 style on import, then changed to Convert 1 style on file save but continue to retain the header and footer thereafter.
Better yet you can edit it and even add more pages to the body without losing any formatting.
Hope this helps.
Ian~G, this bug report is only about the originl attachment I posted as noted in the Description.
At this point, this report is _not_ about the other two, nor how to create a document that produces a problem indepedently.
If you can reproduce the same problem with the original attachment, please specifically mention this, the testing environment, and the version of LO.
Otherwise, RESOLVED WORKSFORME.
Created attachment 68962 [details]
resaved version of original in .doc format
Interesting. The file save blanks the header on the second page and moves all but a couple of lines of text to the following page.
linux ubuntu 12.04 64 bit LO version 126.96.36.199
There is still a bug here. Though I'm not sure if it's 'your' bug or not. I notice you have changed the title of the bug report to more clearly reflect your original content.
Personally, I think it's the same bug, but a different result because of the left and right page layout.
(In reply to comment #28)
> Created attachment 68962 [details]
> resaved version of original in .doc format
> Interesting. The file save blanks the header on the second page and moves
> all but a couple of lines of text to the following page.
> linux ubuntu 12.04 64 bit LO version 188.8.131.52
> There is still a bug here. Though I'm not sure if it's 'your' bug or not. I
> notice you have changed the title of the bug report to more clearly reflect
> your original content.
> Personally, I think it's the same bug, but a different result because of the
> left and right page layout.
Ian~G, the original problem of "Saving .doc as .doc format copies first page header onto all others" does not happen in either the testing environment you noted, nor in mine.
However, it's clear more work needs to be done on the .doc export code in both of our testing environments to get it working as one may expect, but a different bug for a different report.
If you have a bug in LibreOffice, you are welcome to file a new report about this following http://wiki.documentfoundation.org/BugReport .
Thank you for your understanding.
"the original problem of "Saving .doc as .doc format copies first page
header onto all others" does not happen"
Yes it *does*. That has been and still is the whole point. I have provided better examples and descriptions than your original file with a view to finding a solution.
Your original file looks like a particular subset of the same problem due to the left and right page layout.
I don't understand the motivation here. I just want to get LO fixed so that it can be used as an office suite.
If I have to file another bug report for the same bug to achieve this then OK but it sure seems like a lot of wasted time to me.
thank you for your understanding...
Rainer: we need a Q/A expert here, any idea?
Eureka! It's not a bug, it's a feature!
(Yes, I do know this bug report is closed, but just for the sake of completeness I thought it might be helpful to give it a decent burial)
'Hidden' in the LO main menu is a new item >Format >Title Page
Using this secret weapon you can produce report type documents with a different formatting on the front page to the remainder of the contents. These reports will save as .odt .doc AND .docx and retain the formatting when you reload them. (Yes, even if you include a table of contents with merged cells in the first row...)
Unfortunately there is a minor caveat; there is a bug built-in to the feature:
If you choose the option 'Reset Page Numbering after title pages' and set it to 2, it all works like a swiss sewing machine. If however you choose to 'Set Page Number for first title page' and set it to 1, the formatting is lost on file save to *all three formats*. The .odt file looks fine on re-loading and is still perfectly usable - until you save it as a .doc or a .docx when the formatting is lost together with all the headers and footers throughout the document.
The reason the OP's file sort of works is that the title page setting has been retained in the original Word file - though if you re-save it and have a look, you'll see that the second page has lost its header. However, if you fix the overspill of the first page onto the duff page two by, say, deleting one blank line above the title on page one, then the document works.