Description: Using Avery type 6460, if I change the font in any label position other than row 1 column 1, it resets to printing row 1 column 1. Steps to Reproduce: 1. Open Writer -> New -> Labels 2. Set Brand & Type & enter a few lines of text to be printed 3. on the Options tab select any row/column other than 1 & select 'New Document' 4. in the new document, select the text & alter the font in any way & try to print from the toolbar Actual Results: On my system, the label goes to R1 C1 both in the print preview & on the actual paper. Expected Results: The label should stay put. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.3 (x64) / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 24; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
(In reply to Scott from comment #0) > Description: > Using Avery type 6460 I can't find that type in the list of types, so I couldn't test. Version: 7.1.1.2 (x64) / LibreOffice Community Build ID: fe0b08f4af1bacafe4c7ecc87ce55bb426164676 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL
Created attachment 170498 [details] Screenshot of label type
(In reply to Scott from comment #2) > Created attachment 170498 [details] > Screenshot of label type Please check attachment. It doesn't contain an image file.
There is a PNG image when I click the link. One of us is doing something wrong, but I can't understand how.
I just remembered that I have Avery Design & Print installed; could that be how LibreOffice has this label type?
Sorry, don't know, why I had problems earlier. Now I could open the image-file. I've tried to reproduce the bug (also in SafeMode) Steps: 1. Open Writer -> New -> Labels 2. Set Brand (Avery Letter Size) & Type (6460) & enter a few lines of text to be printed 3. on the Options tab select row 2 and column 2 & select 'New Document' Expected result: Four labels in two rows and two columns Actual result: Only one label On the other help says, that the option 'Single Label' "prints a single label or business card on a page [1]. So perhaps current result is correct, but option for setting numbers of rows and columns is wrong. In sum: There is definitely something wrong here, but first step is know, how it should work cc: Design-Team [1] https://help.libreoffice.org/7.2/en-GB/text/shared/01/01010203.html?System=WIN&DbPAR=WRITER&HID=modules/swriter/ui/labeloptionspage/LabelOptionsPage#bm_id3154894
Single Label: Prints a single label or business card on a page. So far the current implementation is correct. But with col/row it's not a _single_ label anymore and I would expect to print the given number of labels. Hard to say if the implementation was done intentionally (making this an enhancement) or not (thus it's a bug, plus the caption is wrong). Jmux, any stance here? Maybe it's easyhackable.
Well, the problem I'm experiencing is not printing a single label with the default font. The problem comes when I try to make that font easy to read; i.e. bold, larger pt, etc. When that is done, the label reverts to column 1 row 1 regardless of which row & column I have it set to. I feel like this is unintentional behavior.
In comment #6 step 4 in my OP was neglected. The current implementation is clearly broken, unless inability to change fonts is somehow 'correct behavior'.
(In reply to Heiko Tietze from comment #7) > Single Label: Prints a single label or business card on a page. > > So far the current implementation is correct. But with col/row it's not a > _single_ label anymore and I would expect to print the given number of > labels. Hard to say if the implementation was done intentionally (making > this an enhancement) or not (thus it's a bug, plus the caption is wrong). > > Jmux, any stance here? Maybe it's easyhackable. I have no idea about the correct behavior, like many other features in LO. But I see the actual result described in comment 6 as correct: > Actual result: > Only one label My interpretation of this feature / workflow: 1. Define your label format by 1.1 (Optional) Select the label type from the brand + type lists 1.2 (Optional) Set the "layout" in the Format tab 2. Select which single label you want to print (as in: which position AKA row + column) 3. Create the document via 'New Document' button Now you have a document with a single label / frame at the correct position on the page. I can modify anything in the text frame and then print / MM the document. IMHO the user shouldn't be able to select any row + column for the "single label", which is outside the range specified in the Format tab. At least I don't see any sense in it, if you select "Format: Sheet". I have no idea yet, how the "single label" option with "Format: Continuous" even makes sense. Coming back to the original report, I can't reproduce; > 4. in the new document, select the text & alter the font in any way & try to print from the toolbar Why should the label frame move? If it does, it's clearly a bug, but I can't reproduce with master. The generated / MM document is correct. So Scott, please describe exactly what you did in step four and attach the saved label document, before you print it (AKA the MM input document), based on the biblio default DB. And please update your LO to the current version. So I'll set this bug to NEEDINFO. And please reset the bug to UNCONFIRMED.
Created attachment 171386 [details] Label to be printed
Using 7.1.2.2 release: Follow steps 1 through 3 in mt OP. The text I am using in step 2 is: " PS 80 Norwegian Blend March 4, 2021 June 2, 2021 " In step 3 I'm setting row 1 and column 3. In step 4 the font is Liberation Serif. Default pt is 12. Change it to 14 pt and try to print. On my system the label frame moves to R1/C1.
FWIW: the version field is for the first affected version. So I reset that field to the original reported version. Thanks for the new info. I could reproduce this "bug" on master. And I did a bibisect, which pointed to commit: commit 87d5c863109f7991e3f2f3a1eb970c00d5a27bd5 Author: Daniel Silva <danielfaleirosilva@gmail.com> Date: Sat Dec 8 10:15:26 2018 -0200 tdf#54908 Make selection active if there's a selection (Writer) That commit is first included in 6.3.1. And at this point it's clear, that it's not a bug, but a feature, even fixing a regression. I also didn't notice, that in the print dialog in "Range and copies" the "Selection" range is active. So my STR are just 1. Open attachment 171386 [details] 2. Select some text in the frame 3. Print the document Result: just the selection is shown in the preview and if you select the full label / frame text, it looks like the label moved, but it's just the text. This became even more confusing, because the print preview is now different then the print. @scott: if you actually see something else, please reopen the bug and add more info. @heiko: any idea how to make this more obvious? I don't think we can change the behavior. At least people claim it's a regression in bug 54908. And I guess normally it's much more obvious, that just the selection is printed. It reminds me of the whole "print empty pages" problem ;-)
(In reply to Jan-Marek Glogowski from comment #13) > And at this point it's clear, that it's not a bug, but a feature, even > fixing a regression. I also didn't notice, that in the print dialog in > "Range and copies" the "Selection" range is active. Cannot follow this. Using 2x2 rows/cols in the wizard produces still 1 single label (arranged to have more items on the page). Printing is okay for me.
@Marek Glogowski: so, I have to make absolutely certain that nothing in the single label frame is selected or it will print in an unexpected location? I must admit, I don't understand what problem is being solved by having a selected label frame print in the wrong location; it still feels like a bug. At least I now know what I was doing "wrong." I appreciate the information, thank you.
(In reply to Scott from comment #15) > @Marek Glogowski: so, I have to make absolutely certain that nothing in the > single label frame is selected or it will print in an unexpected location? No. In the print dialog "General" tab select "All Pages" (or one of the others) instead of "Selection". This behavior fooled me too, but people in bug 54908 claim it was a regression.
*** This bug has been marked as a duplicate of bug 139164 ***