Apache OpenOffice (AOO) Bugzilla – Issue 127269
Print preview and incorrect margins
Last modified: 2022-07-13 06:09:30 UTC
Printer is an HP Officejet 4630. AOO Write informs me that my margins, set at .20", are outside of printable area under Linux Mint 17 and it truly can't print less than .7", but .20" margins were fine under Winduhs XP with the same printer and I printed 50 or 60 pages just fine from there. Not only will AOO Linux not print the extra .5" on the page, but PRINT PREVIEW shows the page fine and it STILL cuts off the other half inch on the actual printed page. I wasted 4 pages of paper, color ink, and a long stream of expletives to figure out just how far these settings are wrong. I expect this kind of BS under Winduhs, but not Linux, and surprisingly, Winduhs is better. Please do not insult my intelligence by passing it off as a bug in the printer driver. If it was the printer driver, the preview would have whacked off the other half inch, too, and I would not have wasted my paper, my ink, nor especially my time. I think you owe me some paper, some ink, an apology, and to compensate my time and frustration.
I am also just a user - not a developer. I appreciate your bug report and I hope that the developers will find the problem so the chop off will be fixed. I use my printer to print pretty close to the border, too. But I don't use Linux too often but Windows and as you said, Windows is not affected. Your "waste" of paper and ink helped in the bug tracking process. But as you probably know, the project has no income so costs by software malfunction can not be refunded. If you like to save costs on ink in the future, then you might want to look into refilling technics. There are also videos available showing you how to refill your HP OfficeJet 4630 on video platforms. This way you can save costs compared to buying original ink cartridges from HP. But this is a tip where you are on your own risk.
(In reply to karko from comment #1) > I am also just a user - not a developer. I appreciate your bug report and I > hope that the developers will find the problem so the chop off will be > fixed. I use my printer to print pretty close to the border, too. But I > don't use Linux too often but Windows and as you said, Windows is not > affected. I had this same kind of problems with Winduhs 3.0. > Your "waste" of paper and ink helped in the bug tracking process. But as you > probably know, the project has no income so costs by software malfunction > can not be refunded. I expect this kind of response from the jerkoffs at Microshaft! > If you like to save costs on ink in the future, then you might want to look > into refilling technics. There are also videos available showing you how to > refill your HP OfficeJet 4630 on video platforms. This way you can save > costs compared to buying original ink cartridges from HP. But this is a tip > where you are on your own risk. *techniques* I have refilled printer cartridges before and I found it a very unrewarding and extremely messy process fraught with pitfalls.
To be honest, I think Open Office works as designed here. I suspect this is more a Problem within CUPS, the default printing system of Linux. Have you, Lee, contacted some user help source? If not please try these first. I suspect the chances are higher that you get a quicker solution there. If you went through without luck you can reopen this Issue and we will try to sort this out together, if you still want to. Please link the unseccsfull discussions so no activity gets repeated. What you can find out would be (you'll need the info anyhow): CUPS Version Driver Version, and Driver used (could be only a generic Open source CUPS definition, which might be not as good as special HP drivers i.e. on Windows.) I recomment on Mint Help channels. If those are not helpfull you can try HP channels or our user Forum (https://forum.openoffice.org/en/forum/), or our user Mailing list. I also would watch your tongue. Karko, wnated to help you. Appreciate this a little at least. This moves makes community strong and will eventually help to solve your Issues faster or better. Show him and his efferts some respect, please. I would like to close this Bug with your concense. We have a little unlucky nameing that will say, "not an Issue" which is of course not true. But for I see our help not very promising. And I do not want to waste your money.
If this were a CUPS driver issue, then why does OOo not properly show the print preview? Or would you have me believe that OOo reads the paper dimensions from two different places and that's what makes Preview look fine? Furthermore, the CUPS driver is specifically for the HP printer in question. I am not using a generic driver. What part of my OP did you miss? Do not treat me as though you think me a noob. I've been writing software since 1982. Not only does OO NOT 'work fine' here, it is really crap! BTW, Libre works fine as well for this particular function. I just don't like the way it imports web pages.
I guess this is just a waste of my time. You people refuse to listen to very detailed information and reporting from another software writer. If you can't tell me you've FIXED the issue, then don't respond to my post.
(In reply to LeeWilkerson777 from comment #4) > I've been writing software since 1982. If you are a developer – how about some concrete informations? E. g. sample documents and screenshots to show the differences? Or at least the version of HPlip? I'm using OOo/AOO since years under Ubuntu with a HP printer without problems. But there are differences between different HPlip versions (e. g. between the definitions of margins for the same paper size!).
I never said I was a developer; I said I write software. BIG, HUGE difference. Furthermore, I have grown both tired and very annoyed at your misdirection. I am not taking the time nor do I have the inclination to assist you any further. Had the first respondee asked me to send screenshots or whatever, I might have been more inclined. I don't even remember what document I was working on and I'm certainly not inclined to waste more paper and ink to reproduce it just so you will eventually say I was right when I already know I'm right. I'll just use a Winduhs computer. BTW, if this were an actual driver issue, none of my other word/text editors would work properly either. Unfortunately for you, they do work properly including the proper display of html documents! GEDIT, for example. Simple is sometimes better. Back to the drawing board! I was trying to help you by pointing out that your software shows/prints formatted pages incorrectly. You aren't listening! Now fuck off!
Well, I did not see any reason to rate you anything else then noob. Speaking style and professionalism is totaly lacking. So what boon should I give you? I can not read your mind, and I am not the NSA that wants to know your thoughts. A lot of people showing here and they know nothing. And they do not do their job to analyse their Problem correctly. This is after all not a user help desk. And we lack coders. You did not write that you have tested your Problem with another Application. So I did not have the same faith in your report that you have. PLUS I am really pissed from your tone. This is off the scale. However I have looked at the Code, and searched through bug Reports. It seems the Preview does not consider printer specifications. So it can be that Print layout gives you a wrong suggestion. I link in other reports where people report cutoffs on printing boarder. However they do not complain about the Printlayout. However they are hardening your case. Issues: 126698 93723 Imho it should be required that the Printborders can not set beyont what the printer can print. Especially because today it seems techspecs do not contain this info.could not find thesame. I will try and see if I can provoke my printer in doing the same. BTW. A workaround could be to print to PDF, check the document, then Print the Document. (However I have seen some issues with the PDF Exports and boarders too. So not sure if this is not triggering other bugs.
*** Issue 127807 has been marked as a duplicate of this issue. ***
we have multiple reports and this is already on my interest list. However I am not sure what the finbal solution is on this.
Well this has been going on for years and I find that this is a basic functionality of the software. If a program cannot print out what is on the screen, then the is a serious problem indeed. When a word processor does not know what the printer can do based upon the printer driver it has to work with in the OS environment, then it is not a word processor with any reasonable output abilities. Is it even considered a word processor? It is high time that this issue becomes a major focus of the development team. I, for one, am tired of people trying to say that this is normal. That is total BS. One of the very first things done in writing code for a word processor is to make sure it has print functionality. Part-way functionality means that the software is part-way coded. Why even bother releasing it? If Apache wants users to support their product, they'd better make it work in basic functions.
Kitchm, Apache is not a software producer like Google or Microsoft. The Organization does not hire or have developers directly. Apache does only provide Infrastructure and supports cooperation between participants (who can be anyone). To support OpenOffice currently means that you start Programming or writing specs for Programmers, or organize Programmers. Only supporting us after the issue has been fixed, is quite wired. after the issue is fixed, we do not need your support anymore. The work is done. We need your support now, in order that you use your skills to get closer to a fix of this issue. It is your free will not to support us, then we will fix this issue when we get to it. There are lot of other issues. And this one is not even clear what to do exactly. currently you as a user have to apply the specs. It would be nice if the software can be more supportive, but I am not sure how. One discussed approach is to have multiple margins shown, to provide an Idea if the current layout is help full or not. Your report plays into it, because your Issue shows that OpenOffice applies assumed margins. So I collect these requirements all here, and then maybe we can solve them all at once, or we split them up in singular programmer tasks.
You assume a lot. http://apache.org/foundation/contributing.html It is obvious that there is a basic flaw in the programming when there can be no proper communication with a printer and/or its driver. Seems pretty darn fundamental to me.