Hi, Actually there are mulitple issues with the attached document. The file is Europass cv (served in odt format: original can be found here: https://europass.cedefop.europa.eu/en/documents/curriculum-vitae/templates-instructions) Steps: 1- Get the ODF file attached (CVTEmplate.odT) 2- Save as - docx and close the file 3- Reopen with LibreOffice 4- open it with MS Word I've spotted following issue on LibreOffice 4.3.2 (but it is better than LibreOffice 4.4.0 :( ) On LibreOffice 4.3.2 Problem 1) Header, footer and page number missing on second page while saved docx the attached ODT file. You may see the comparison Word 2013 vs Writer 4.3.2 on the screenshot (derivative of the document) The file is Europass cv (served in odt format: original can be found here: https://europass.cedefop.europa.eu/en/documents/curriculum-vitae/templates-instructions) On 4.4 things got worst. The following errors was not seen on 4.3.2. They are new to 4.4.0 Opening the file with LibreOffice a) The styles are not preserved. For example the red lines with style name _ECV_Comments are actually Arial 8, but when saved style name ok, but font is changed to Times New Roman 12. B) Europass logo dissorted Opening the file with Word 2013: Problem a and b does not exists, only Problem 1 is preserved. I see that LibreOffice 4.4.0 can export it like 4.4.o but cannot view as good as 4.4.0 Sorry for the mixed description. --- PS: Doc format was very good on 4.3.2 but it breaks some tables when exported on 4.5 and opened by Word 2013 Best regards, Zeki
Created attachment 113297 [details] CVTemplate - original ODT file
Created attachment 113298 [details] Difference between LibreOffice 4.3.2 and Word 2013
Hi Zeki, i can reproduce most of your bug. Unfortunately, you reported more than one bug. Can you create one report per bug? 1. Header/footer problem in 4.3.2 2. Style regression in 4.4.0 3. Logo regression in 4.4.0 (i was unable to reproduce that one in 4.2 and 4.5) 4. A bug for with attached document for your "PS" part Just send me the links to your need bugs or post them here. I will set 1 and 2 to verified and retest 3 and 4. Thanks!
(In reply to Jan from comment #3) > Hi Zeki, Hi Jan > i can reproduce most of your bug. Unfortunately, you reported more than one > bug. Can you create one report per bug? Yes sure > 1. Header/footer problem in 4.3.2 Changed this bugs title to header/footer data loss and lets concentrate this bug for this problem. > 2. Style regression in 4.4.0 https://bugs.documentfoundation.org/show_bug.cgi?id=89315 > 3. Logo regression in 4.4.0 (i was unable to reproduce that one in 4.2 and > 4.5) https://bugs.documentfoundation.org/show_bug.cgi?id=89316 > 4. A bug for with attached document for your "PS" part https://bugs.documentfoundation.org/show_bug.cgi?id=89317 > > Just send me the links to your need bugs or post them here. I will set 1 and > 2 to verified and retest 3 and 4. Thanks. Best regards, Zeki
Still reproducable on Version: 5.0.0.5 Build NO: 1b1a90865e348b492231e1c451437d7a15bb262b Regards, Zeki
verified the problems still exists in LO development 5.3 (ubuntu 12.04) In the ODT, the second page switches to follow page style "SmallerHeader". This appears not carried through to the .docx where all of the pages are using the "Standard" style. The ODT Default Style (first page) has "different header even/odd", while the SmallerHeader uses the same header for even/odd. In the .docx import into LO, only the first page-style is imported, and for some reason the footer has also taken on the "different even/odd" setting.
If I understand correctly, Word doesn't have the concept of named page styles. Docx page styles are "dynamically" created on import and given the name "ConvertedX" In CVTemplate.odt, the "Default" page style on page1 is next:linked to the smallerHeader page style, so Writer automatically switches from Default to smallerHeader on page2 without the use of a pagebreak (somewhat similar to how Word automatically switches between section style info). Since Word doesn't work this way, we would need to emulate it with a section break or a page break.(Probably a page break so that we round-trip better since sections are awkward, but a section break would probably be better for flexibility in Word, so let me first look into importing continuous breaks as next:links since that might fix some other problems...)
This problem with first and next pages is as 'old as Methusalem' as we say in Dutch ;) So there will be more issues to find for this for sure. But ;) Hi Justin! (In reply to Justin L from comment #7) > If I understand correctly, Word doesn't have the concept of named page > styles. Correct. > Docx page styles are "dynamically" created on import and given the > name "ConvertedX" More precise: that Page styles are created on import of a docx file. > In CVTemplate.odt, the "Default" page style on page1 is next:linked to the > smallerHeader page style, so Writer automatically switches from Default to > smallerHeader on page2 without the use of a pagebreak (somewhat similar to > how Word automatically switches between section style info). Word allows to set for a different header/footer on the first page of a section. So if you insert a section break in Word, and you use that for page settings, then you can define that. With LibreOffice 4.0 Miklos introduced an important improvement in Writer wrt compatibility: the possibility to do the same setting in Writer page styles. ("Same content on first page" on Header and Footer tab. That are linked by the way, which makes sense, since Word doesn't allow to differentiate between header/footer in this way either. > Since Word doesn't work this way, we would need to emulate it with a section > break or a page break. Until the new page style setting (see my previous paragraph) the user had to give a Insert > Manual Break with page style setting at the end of the first/top of the second page when saving in a Microsoft format. (I've once automated this with a macro to handle multiple docs ;) ) But with the new setting, at the creation of a document, one has the possibility to avoid that need. (However I find it not easy to work with the new option. In my experience it's impossible to reliably change header/footer hight and distance after it's once set and you've started working on the content. Should make an issue for that..) > (Probably a page break so that we round-trip better since > sections are awkward, but a section break would probably be better for > flexibility in Word, A hard page break is a ctrl+Enter. When you set properties in that paragraph (Format Page .. Text Flow > Page Break & Style) then it becomes a section break with the needed attributes in the doc(x) file. (Both a hard page and a section break give the result that the automatic text flow to the next page is interrupted.) So at the moment that you convert to a break with 'page attributes', it will become a section break in Word. Another approach might be to convert to different first and other page header and footer. But I can't make any sensible remark on the programmatic implications of that. (Will attach a screen shot of the break menu in Word 2010)
Created attachment 127243 [details] screen shot from Word 2010 with the menu Breaks
Created attachment 127301 [details] FollowStyle.odt: next style converts poorly to .doc and .docx (simple example) different first page: only the margins from the "follow" style are considered in writerfilter. Emulation is in wrtw8sty.cxx::SectionProperties, but doesn't apply for this example because the margins are different. Can force it with: if ( sw::util::IsPlausableSingleWordSection( *pPdFirstPgFormat, rFollowFormat ) || titlePage || true ) continuous break, new section: This is how MS would do it. However, that is VERY hard to handle for Writer since on import you don't know how many pages the section covers, so you can't do fancy emulation stuff (without causing other regressions and problems). page break, new section: This is how .doc export handles it, but .docx completely ignores that shared code path: docxexport.hxx:virtual void SectionBreaksAndFrames( const SwTextNode& /*rNode*/ ) override {}
(In reply to Justin L from comment #10) > different first page: only the margins from the "follow" style are > considered in writerfilter. Emulation is in > wrtw8sty.cxx::SectionProperties, but doesn't apply for this example because > the margins are different. Can force it with: > ... So ideal would be that this is extended? > continuous break, new section: This is how MS would do it. However, that is But not for the first page different from the others. People use a continuous section to set e.g. new page margins from (next page) at that point on. Or do I get this wrong? > VERY hard to handle for Writer since on import you don't know how many pages > the section covers, so you can't do fancy emulation stuff (without causing > other regressions and problems). But this issue is about export to docx, not about import? > page break, new section: This is how .doc export handles it, but .docx > completely ignores that shared code path: > ...
Created attachment 127332 [details] manyHeaderDefinitions.docx: complex situation that Writer can't fully handle ------------------------------- Yes, this is an export bug, but we need to be able to round-trip, so anything we use to emulate this must also be valid on it's own. Doing anything with continuous breaks would be very tricky. You can also use continuous breaks to define new headers and footers. These only take effect IF that section ever moves to the next page. VERY flexible design from MS point of view, and something LO can't do at all. So, instead of doing a "first header is different from the following pages" you can just create a continuous section break and define new headers which will take effect at the next page. This lets you redefine headers MANY times on a single page if you want.
*** Bug 112203 has been marked as a duplicate of this bug. ***
*** Bug 121888 has been marked as a duplicate of this bug. ***
*** Bug 117830 has been marked as a duplicate of this bug. ***
*** Bug 124682 has been marked as a duplicate of this bug. ***
Still reproducible in Version: 6.5.0.0.alpha0+ Build ID: 02b24d77476f93887691dde564351d6f8b770b8f CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Michael S, I thought you might be interested in this issue, after your recent improvements done to loss headers < https://cgit.freedesktop.org/libreoffice/core/commit/?id=08f13ab85b5c65b5dc8adfa15918fb3e426fcc3c >
*** Bug 116959 has been marked as a duplicate of this bug. ***
*** Bug 133470 has been marked as a duplicate of this bug. ***
*** Bug 105134 has been marked as a duplicate of this bug. ***
*** Bug 139266 has been marked as a duplicate of this bug. ***
*** Bug 137674 has been marked as a duplicate of this bug. ***
*** Bug 142756 has been marked as a duplicate of this bug. ***
*** Bug 152179 has been marked as a duplicate of this bug. ***