Created attachment 65731 [details] Label template for Avery 8162 The result of a mail merge breaks labels position. The files attached will explain the issue. The file "Avery-j8162-template.odt" was generated by the 8162 label from Avery. You will see is correctly in the page. It is as expected. However, the file "Avery-j8162-MMerge-result.odt" is the result of the mail merge and shows labels competely misplaced. You will notice that the rightmost label has slipped below the leftmost label. This makes the mail merge ramdomly unusable. Notes: 1) Filling the template with text does not misplace the labels 2) I have not tested exhaustively with other types of labels 3) it looks like the mail merge is mishandling labels positions. 4) I am also attaching the data source. 5) I was able to recover the 2 column layout by changing slightly the labels dimensions, but it should not be this way.
Created attachment 65732 [details] Results after mail merge
Created attachment 65733 [details] Data for mail merge
Hi Olivier, I looked at your pimaco.xcu and at one label in particular (the first one I found with two columns): 6081/6181/6281/62581 The given dimensions result in a paper width of 212.4mm, which is more than A4. The result is that the second label will not fit on the same line as the first label. With the numbers: definition of label states: HDist = 10680, Width = 10160, Left = 400 and Columns = 2. calculated paper width is Left + Width + (Columns - 1) * HDist = 21240 Either your paper is not A4 (210,0mm) or Letter size (215,9mm) or the label dimensions are not entirely correct (in this case). I then saw your bug and checked for label 6182, which has the same horizontal dimensions as 6182, so the same problem occurs. I then reread your bug and saw that you mention Avery A4 (J)8162. That label is not in your pimaco.xcu. The document created by the label wizard no longer shows the label dimensions, but your attachment (description 'Label template for Avery 8162', but file name 'Avery-j8162-template.odt'). The label Avery A4 J8162 does fit on A4. The label Avery Letter Size 8162 will not fit on letter width (label definition gives a width of 221,92mm but paper width is only 215,9mm). This is a bug indeed; the dimensions of this labels are not correct. To avoid confusion, which label are you referring at?
(In reply to comment #3) Hi Olivier, I miscalculated: Avery letter size 8162 does fit on Letter size paper, so not a bug there. But the label definition you used for your attachments still needs attention, so please telle me which label you used.
Hi Winfried I originally was handling Pimaco labels, but I decided to see if Avery had the same issue (since I know from good source that Pimaco borrowed Avery numbering). So, as you will see, Letter-sized xx82 class labels have this issue with both brands. Just for the records, in your calculations Left + Width + (Columns - 1) * HDist we should add the right margin (which is not given, but most often equal to the left margin). 2*Left + Width + (Columns - 1) * HDist So I attached a spreadsheet from Pimaco, with the dimensions, as they gave me circa 2009. I hope it can me read without translation. Ideed there are many labels with wrong page dimensions. Not sure with respect to Avery.
Created attachment 65823 [details] Pimaco data in spreadsheet format
(In reply to comment #5) Hi Olivier, The right margin is not always the same as the left margin. That is the major reason why I had to introduce the paper/page dimensions to the label definitions. What is important is that the mentioned calculation (left + width + hdist * (columns - 1)) results in a size <= the paper size. The right margin is not used by LibreOffice. What intrigues me is which label did you use in your attached odt-files? The dimensions/positions are not those of Avery A4 J8162 or Avery letter size 8162. If you used Pimaco definitions, then these need to be corrected and there is not a bug in LibreOffice. I am willing to help you with Pimaco definitions and adding them to the LibreOffice Labels.xcu.
Winfried The test case documents attached above were generated with Avery data, as supplied in LibreOffice 3.6.0.
I am able to reproduce the problem, but with Avery A4 J8162 and with Avery LS 8162: -create new label document, no problem -save document -close document -open document: the labels no longer fit on the paper. I will test with version 3.5 and see if this is a regression problem.
It looks like regression as version 3.5.6 does have this problem. The label-wizard code has not been changed since february 2012. The newly created label-document looks good (in 3.5 and 3.6), but once saved and reopened, the label layout is broken. I suspect some change in document-save code causes this, as a document saved by version 3.6 opens with broken layout in 3.5. Unfortunately, that code is totally unfamiliar to me and I change the status back from assigned (to me) to new. I am willing to help in any way to solve this problem.
Adding some more pieces to the recipe: Taking Avery Letter J8162 Ink Jet as sample (2 columns, 7 lines), generate a new label document with dummy data 1) saving the generated document as ott, fodt or odt breaks the layout upon reading the document back or running the mail merge (one colum disapear and the rightmost label slip under the leftmost label). 2) saving as .DOC breaks the layout in another way: The 2 columns are there but the inner gap between the 2 columns is gone. This error is exactly the same I see in Version 3.5.4 of the label generator for any kind of document format.
Also, a PDF generated by the label document displays correctly.
OK, reviewing the math and the labels dimensions, I have a potential overflow: Taking Avery J6182 (2 col, 7 rows), measurement in centimeters Left margin: 0,4 1st label width: 10,16 right spacing: 0,48 (obtained in the frame-wrap, spacings properties) 2nd label width: 10,16 right spacing = 0,48 (same frame dimension as 1st label) total : 0,4 + 10,16 + 0,48 + 10,16 + 0,48 = 21,68 But 21,68 is larger than 21,59, the width of a letter-size paper. This will force to break the line. That explains why the second label slips under the first since frames are character-anchored. Apparently that behaviour happens when the frame positions needs refreshing/recalculation, such as loading the file. So by using custom pages for labels, the pages sizes are relaxed to hold this overflow. I noticed that all labels frames are styled, with auto-update, so if I change one label property, all labels change as well. Some questions I have: 1) why not use Word approach and build a table with the labels dimensions and spacings as cells? 2) why use character anchored frames, instead of page-anchored?
(In reply to comment #13) The code uses different frame definitions for the rightmost column, bottom row and bottom right frame to avoid this problem, so this should not happen. I have been away for a week, but I will try and look at it again asap. But as the label wizard code has not changed between 3.5.3(?) and 3.6, I suspect another change causes the problem. Unfortunately, no one with knowledge of the odt-document save/write code has presented him/herself yet. With regard to your questions: I have changed the original label wizard code as little as possible when I worked on it; I did not see a reason for a complete rewrite.
Created attachment 67022 [details] label document with Avery letter J8162 made with version 3.5.6
Created attachment 67023 [details] label document with Avery letter J8162 made with version 3.6.1
Created attachment 67024 [details] label document with Avery letter J8162 made with version 3.5.6 and 'saved as' with version 3.6.1
I made two documents with Avery letter J8162 labels (see attachments), one with LibreOffice version 3.5.6 and one with version 3.6.1. The document made with version 3.5.6 opens well in both 3.5.6 and 3.6.1. The document made with version 3.6.1 opens with distorted layout in both 3.5.6 and 3.6.1. This seems to mean that saving/writing the document with version 3.6.1 introduces the problem. However, opening the document made with 3.5.6 in 3.6.1 and saving under a different name does not give a problem. I compared the contents.xml of the 3 documents and could not find a difference that might be the cause of of the distorted layout. As I am not familiar with the other files in the odt-document, I have not done other comparisons. I'll go on searching..
Version 3.7.0 (git update of 2012-09-12) has the same problem as version 3.6. Another thing I noticed: the newly created label document shows the labels with a gap between the left and right label, as it should be. When opening an existing label document (one of the attached documents), the gap often (not always) is no longer there. This applies both to version 3.5 and version 3.6. This supports my thought that the problem lies in the Writer's write or read functions (where the cause may still be in the label wizard code).
I unassigned myself from this bug. Since the newly created document is ok and only gets broken when saved/reopened, someone who knows about read/write of writer documents needs to look at it. I have not been able to find such a person to assist me in finding the cause of the problem. I am willing to improve the code of the label wizard should that be necessary or desirable. I am sorry that I cannot fix this bug myself as it is a very annoying bug indeed.
Sad. More tests with LibreOffice 3.3 shows the following: 1) saving and loading the labels document works. At this release, the page size is set to custom. Custom width: 21.71 cm custom height: 25,86 cm 2) setting the page size to Letter breaks the labels layout, and displays the same problem of this bug. The width of the letter size is smaller than the custom page size. My conclusion is that the present labels position calculation requires custom pages.
(In reply to comment #21) > Sad. > I don't feel happy about it, but I lack the expertise in the write/read area. > My conclusion is that the present labels position calculation requires custom > pages. The present label wizard uses 'custom pages', i.e. the page size (width and heigth) is saved with the label definition. This is the case for version 3.5.3 (or 3.5.4) and later. Your conclusion is correct and the requirement is met.
I have been thinking about the suggestion in comment #13 (why use character anchored frames, instead of page-anchored?). When I I changed the original code as little as possible and kept the character-anchored frames, even though I thought it unlogical. Now I changed the code to page-anchored frames, which simplifies the code (I like that). The bug does not occur now, as the frames are fixed at there location on the page. It is a sort of workaround, as the original cause of the bug is not known. I will have to do a lot of testing now, to see if the code handles othter sorts of labels and business cards well. Once satisfied with my testing, I will submit the modified code as a patch. I reassigned the bug to myself and hope to be in time for version 3.6.3. @Olivier Do you want the modified code so that you can build and test yourself too? It is one file only, with -so far- only a few (unpolished) changes.
Yes please, send the modified file to me (or attach here). Thanks you. I will test it with my latest builds..
Created attachment 67330 [details] preliminary patch/workaround With the attached diff file the patch/workaround can be tested. So far all looks good, but I want to test some more before I submit.
Hi Winfried I applied your patch (patch <53(..).diff) and it compiled ok. Reloading the file seems to recover the right label layout, at least with J8162. 1) You may want to investigate the appearance of 6 paragraphs marks, just on the right of the top left label, as indicated in the 1st image attached. 2) Running the mailing list with data has a bug: A extra frame shows up in the second row (2nd image)
Created attachment 67356 [details] Mailing list result My guess is that the previous logic of frames insertion (charater-anchored based) required the creation of a paragraph. One paragraphh per line. Here, there are 7 rows and 6 marks (N-1?). No idea on why another frame shows up.
(In reply to comment #26) Hi Olivier, Being a workaround, it may introduce more problems than it solves ;) > 1) You may want to investigate the appearance of 6 paragraphs marks, just on > the right of the top left label, as indicated in the 1st image attached. I see that too, the number of paragraph marks is the number of rows on the page. I don't know (yet) why and where this paragraph mark is set. It doesn't seem to do any harm, though. > 2) Running the mailing list with data has a bug: A extra frame shows up in the > second row (2nd image) I will make a mailing list myself and see if I can reproduce this (followed by trying to find the cause).
(In reply to comment #26) Hi Olivier > 1) You may want to investigate the appearance of 6 paragraphs marks, just on > the right of the top left label, as indicated in the 1st image attached. removing lines 362/363 from applab.cxx if ( i + 1 != rItem.nRows ) pSh->SplitNode(); // Small optimisation removes the extra paragraph marks. I don't see a problem in removing these lines. > 2) Running the mailing list with data has a bug: A extra frame shows up in the > second row (2nd image) I haven't been able to reproduce this yet. Could you use the buit-in bibliography as database and create a maling list with the extra frame, so that I could have a look at the file? Or, alternatively, can you provide me a step by step process to create such a document (with a databse that I have/can use, of course)?
Hi Winfried 1) I removed the paragraph counter as indicated in comment #29. OK 2) Compilation OK, but complains now of unused parameters (minor issue) [build CXX] sw/source/ui/app/applab.cxx /home/tdf/git/core/sw/source/ui/app/applab.cxx:92:17: aviso: unused parameter ‘bPage’ [-Wunused-parameter] /home/tdf/git/core/sw/source/ui/app/applab.cxx:129:17: aviso: unused parameter ‘bPage’ [-Wunused-parameter] 3) Saving and opening the label page works OK in the example: same layout as generated (file teste-etiq-pag3.odt) 4) The zip file attached contains the data I used to test: datasource: address.odb spreadheet data: address.ods file generated by labels: teste-etiq-pag3.odt Resulting mail merge: result3.odt file generated by MM after MM: teste-etiq-pag3-after-mail-merge.odt As you will see, the result file (result3.odt) is buggy. What puzzles me is that the MM destroys the generated label file (teste-etiq-pag3.odt) and produces teste-etiq-pag3-after-mail-merge.odt
Created attachment 67419 [details] set of 5 files with examples and results
(In reply to comment #30) Hi Olivier > 2) Compilation OK, but complains now of unused parameters (minor issue) I had corrected that, but as it didn't matter for the testing I omitted to mention it. > 4) The zip file attached contains the data I used to test: > datasource: address.odb > spreadheet data: address.ods > file generated by labels: teste-etiq-pag3.odt > Resulting mail merge: result3.odt > file generated by MM after MM: teste-etiq-pag3-after-mail-merge.odt > > As you will see, the result file (result3.odt) is buggy. What puzzles me is > that the MM destroys the generated label file (teste-etiq-pag3.odt) and > produces teste-etiq-pag3-after-mail-merge.odt I am going to look into this.
Created attachment 67424 [details] mailmerge results Hi Olivier, I cannot reproduce your problem with mail merge. I used your file to produce a mail merge document, both with version 3.6.1(Windows) and with 3.7.0(openSUSE), see attachment. They look OK to me. I also made a label document myself and connected it to the bibliography database present in LibreOffice. The mail merge result looked good too. I : -open the document (say teste-etiq-pag3.odt) -select File-Print... -say yes to produce a form document -check the connection and make a new connection to address.odb (my path differs from that in teste-etiq-pag3.odt) and set the fields -select File-Print... again as the reconnecting breaks the print command (bug, as designed?) -select range of addresses and select output to single file (see attachments) -open output file What could be the difference between your and my results?
(In reply to comment #33) > I : > -open the document (say teste-etiq-pag3.odt) > -select File-Print... > -say yes to produce a form document > -check the connection and make a new connection to address.odb (my path differs > from that in teste-etiq-pag3.odt) and set the fields > -select File-Print... again as the reconnecting breaks the print command (bug, > as designed?) > -select range of addresses and select output to single file (see attachments) > -open output file > > What could be the difference between your and my results? Aha! There we are: I think it was the way we do the mail merge. I used the "Tools - Mail Merge" wizzard. So at this point we must be sure that the problem is isolated. The page-anchored frames seems to fix the save-close-open label template file, and we must then test for as much labels as we can to really be comfortable. My conclusion is that the previous approach was producing rows longer than page width, and forced a line feed on the second (last) label of the row. This is fixed now, as frames are page-anchored with protected frame positions. The donwside is that (please confirm) we broke the mail merge wizzard found in Tools - Mail Merge. To circumvent this limitation until it get fixed, we must use the File - Print procedure to generate the mail merge. I think we should bring that to the attention of other developers (dev list) to get one that is knowledgeable with the mail merge wizzard.
(In reply to comment #34) Hi Olivier, > Aha! There we are: I think it was the way we do the mail merge. I used the > "Tools - Mail Merge" wizzard. So I tested with your files and used the mail merge wizard: the merged document looks fine, no inserted frames, just as when I merge via print... > So at this point we must be sure that the problem is isolated. The > page-anchored frames seems to fix the save-close-open label template file, and > we must then test for as much labels as we can to really be comfortable. My > conclusion is that the previous approach was producing rows longer than page > width, and forced a line feed on the second (last) label of the row. This is > fixed now, as frames are page-anchored with protected frame positions. IMHO the problem is not in the label document creation code, as the newly created document is OK. Only when it is saved and reopened, th eproblem starts. The frames on the rightmost column are created with a smaller width (label width only) and fit (until saving/reopening). It works well with version 3.5, but doesn't since 3.6; no label document creation code has been changed. By changing the label creation code, we can 'bypass' the cause of the problem, but it could reappear any moment. The changes to the label document creation code are improvements since they are simpler and the frames look like the actual label (more logical for the user). > The donwside is that (please confirm) we broke the mail merge wizzard found in > Tools - Mail Merge. To circumvent this limitation until it get fixed, we must > use the File - Print procedure to generate the mail merge. As said before, I cannot confirm your mail merge problem. > I think we should bring that to the attention of other developers (dev list) to > get one that is knowledgeable with the mail merge wizzard. I suggest that I submit a partial patch (the changed made to applab.cxx) with an explanation to the dev list. We could continue to try to reproduce the mail merge problem in order to make it possible for a developer with knowledge of the mail merge code to fix the bug. Also, I still hope that a developer with knowledge of the write/read functions will get interested so that the actual cause of the problem can be fixed. I will not submit the partial patch without your consent. Although the speed ay not be gigh because of the time difference, together we have made quite some progess!
Created attachment 67705 [details] updated patch/workaround Attached diff file gives the current changes of applab.cxx. IMHO it could be submitted separate from this bug, as the changes are an improvement of the code in itself. It (partially) 'fixes' this bug, but also seems to introduce unwanted behaviour with mail merging (see comment 30).
Hi Winfried, sorry for the loong delay - working back through my mail: > Since the newly created document is ok and only gets broken when > saved/reopened, someone who knows about read/write of writer > documents needs to look at it. Interesting ! It would be great to know what in the saved file is broken; Could we do the same steps in two -very- simply document, save as flat-odt (.fodt) and compare the output to see where they differ ? Anyhow - I'll ask a writer guy to look at this :-)
Hi here is the console output of a recent master (no patch applied) build with the issue and saving with format FODT and ODT. Upon reload of the file I get an exception olivier@SCIEDXPC:/mnt/data1/git/libo/install/program$ ./soffice create vcl plugin instance with gtk version 2 24 10 warn:legacy.osl:29554:1:/mnt/data1/git/libo/tools/inc/tools/resid.hxx:56: ResId without ResMgr created warn:legacy.osl:29554:1:/mnt/data1/git/libo/sw/source/core/attr/format.cxx:225: SwFmt::~SwFmt: Def dependents! warn:legacy.osl:29554:1:/mnt/data1/git/libo/sw/source/core/attr/format.cxx:234: ~SwFmt: parent format missing from: Frameformat warn:legacy.osl:29554:1:/mnt/data1/git/libo/xmloff/source/style/xmlimppr.cxx:689: Exception caught; style may not be imported correctly.
Created attachment 67814 [details] flat odt of Avery letter size 8162 label document
Created attachment 67815 [details] flat odt of Avery letter size 8162 label document (made with version 3.6.1.2)
Comment on attachment 67814 [details] flat odt of Avery letter size 8162 label document produced with version 3.5.5
(In reply to comment #37) > Interesting ! It would be great to know what in the saved file is broken; > Could we do the same steps in two -very- simply document, save as flat-odt > (.fodt) and compare the output to see where they differ ? I just attached two flat odf documents, one made with version 3.5.5 and one made with version 3.6.1.2. I note that some where the right margin of an item (frame?) has a value in one version and is 0 in the other version. That is just the difference that makes a frame fit/not fit on the page. I will submit my patch so far.
Winfried Donkers committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4bbcf581ad7a478387491058b38e6dd8a344af44&g=libreoffice-3-6 fdo#53673 fix for layout problems with version 3.6 and up It will be available in LibreOffice 3.6.3. 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.
Soo ... I see Winfried's nice patch got into master and libreoffice-3-6. I'm hoping that we can mark this fixed; and/or split out a different bug with any remaining issues (?). But of course, perhaps I missed something ? :-) Thanks so much Winfried.
I apologise if you don't want to know about this. I'm also informing Canonical on Launchpad about this bug. I'm having this bug on version 3.5.4.2 on Ubuntu 12.04. I'm using Avery A4 labels (4 rows, 2 columns). I think that LO is taking the height as the vertical pitch and the width as the horizontal pitch. Specifically, my dimensions are: TopMargin=2.3,VerticalPitch=6.8,Height=5.0,LeftMargin=1.45,HorizontalPitch=10.1,Width=8.0. Thus, it prints the second label down as 5.0 below the first label and the second label across as 8.0 to the right of the first label. Only workaround that I can think of is to make the Height=6.8 & the Width=8.0. However, this may cause the page height & width to be greater than the actual A4 page dimensions.
John is that a separate bug ? can you reproduce it with a recent build of LibreOffice preferably 4.0 ? if so we're interested of course.
Michael, BTW I've reported this on Launchpad (for Ubuntu) as Bug 1090745. I don't know how to move to LO 4.0, nor do I want to as I like stable builds. The reason that I reported this on Bugzilla is that I found it difficult to understand what this bug is & also that it exists on Ubuntu 12.04 (this being only released in 2012 & having 5 years of support.
(In reply to comment #45) > I apologise if you don't want to know about this. I'm also informing > Canonical on Launchpad about this bug. I'm having this bug on version > 3.5.4.2 on Ubuntu 12.04. I'm using Avery A4 labels (4 rows, 2 columns). I > think that LO is taking the height as the vertical pitch and the width as > the horizontal pitch. Specifically, my dimensions are: > TopMargin=2.3,VerticalPitch=6.8,Height=5.0,LeftMargin=1.45, > HorizontalPitch=10.1,Width=8.0. > Thus, it prints the second label down as 5.0 below the first label and the > second label across as 8.0 to the right of the first label. > Only workaround that I can think of is to make the Height=6.8 & the > Width=8.0. However, this may cause the page height & width to be greater > than the actual A4 page dimensions. John, Can you tell which Avery A4 label you are using?
Avery A4 (not Asian)
Bjoern - an Ubuntu user wanting free support from you ;-)
(In reply to comment #49) > Avery A4 > (not Asian) Sorry for not making myself clear: which type of the Avery A4 labels are you using (e.g. C2160)? It's the input field below the field saying 'Avery A4' on the tab 'Labels' of the label wizard.
I left it at the default i.e. [User].
(In reply to comment #52) > I left it at the default i.e. [User]. Ok, I checked with your settings and dimensions: master (4.1) & openSUSE 12.2: 8 nicely placed frames/labels on the A4 sheet 3.5.4.7-1.1.1 & openSUSE 12.2: wrongly located frames, the horizontal and vertical gap between labels are gone, but no exchanging of height and width occurs. Label height is 5 and width is 8 cm. 3.6.4.3 & Windows XP: 8 nicely placed frames/labels on the A4 sheet AFAIR somewhere in the 3.5.3/3.5.4 period I submitted a couple of patches, because of incorrect aligment when the horizontal pitch was greater than (Width + right margin), as is the case here. It is possible that the LO 3.5.4 from Ubuntu 12.04 and openSUSE 12.2 is from before the last patch in the 3.5 series, I don't know. LO 3.6 and 4.0 have a different way of placing the frames/labels on the page than the versions before that. That's what this bug is about.
Winfried, Thanks for your helpful explanation about tests you ran. Perhaps you missed my previous reply to Michael Meeks: BTW I've reported this on Launchpad (for Ubuntu) as Bug 1090745. I don't know how to move to LO 4.0, nor do I want to as I like stable builds. The reason that I reported this on Bugzilla is that I found it difficult to understand what this bug is & also that it exists on Ubuntu 12.04 (this being only released in 2012 & having 5 years of support). Still no reply on Launchpad (for Ubuntu).
(In reply to comment #54) John, No problem, it's just that as I changed the label wizard code, I'm keen to check if there are still issues to be fixed.