Version: (using Devel) OS: Linux Installed from: Compiled sources When working with landscape pdf, chosing landscape when printing actually prints the document in portrait. Chosing portrait prints the document in landscape. I think that the portrait/landscape setting in the printing window actually is more like a rotate command: portrait leaves the document alone while landscape rotates it by 90 degrees. This is not always correct, obvioulsy in my case it's not. Okular I used is from the latest RC debian packages, running on Ubuntu Intrepid.
Couls you please provide a sample document showing the issue?
Created attachment 30416 [details] Example pdf file creating the problem As requested, this is the file I first encountered the problem with.
I observe the same bug, printing a landscape pdf, the content will not be rotated so that it fits the page but is rather cut of at the right side of the paper and at the bottom there is free white space System: OpenSuse 11.0 and 11.1 Source: OpenSuse BuildService KDE4:Factory Version: 0.8 (KDE 4.2.0) Architecture i586 and x86_64 Cups: cups-1.3.9-7.1 (on OpenSuse 11.1) When printing to pdf, the resulting pdf will be landscape as well, when printing to ps, the preview in dolphin shows it (correctly rotated) as portrait and when I then open it in okular again, it will be shown as landscape (correctly rotated again)
Okular Versione 0.8.80 Con KDE 4.2.71 (KDE 4.2.71 (KDE 4.3 >= 20090428)) Still happen, and the regression force my office to use kpdf and kde-3.5. A shot in the dark may be the fact the documents are in "A4" size?
1st how /me poor man fixed this: sed -e 's:landscape:portrait:g' -i okular/core/fileprinter.cpp || die "failed sed" In My Frustrated Opinion: this seem to be a recurring bug, there are possibly two ways to workaround it defintly: a) try to be the smart gui: rotate every page to portrait before sending it to the printer (hint the smart gui often is bashed by added complexity) b) give the user the freedom to chose the orientation he desire, _and_ make it a persistant default, it's already possible to set "portrait" as print mode and okular will obey it but it neeed to be set _every_ time the user open such a document. references: http://www.google.it/search?q=okular+kpdf+print+landscape ~/tmp/kdegraphics-4.2.71/okular/TODO: -> FIX: sheet rotation in landscape case -> rotate the whole document / individual pages (on screen/print?) (BR99352) kde bug #155696 using lp (cups 1.3.10) it print correctly with the command: lp -d"hp5" -o fitplot -o media=a4 file.pdf work fine _but_not_ when adding `-o landscape` filter used as seen in cups logs: "foomatic-gswrapper -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -sDEVICE =ijs -sIjsServer=hpijs -sDev..."
Same problem here. Maybe these reports are related as well: https://bugs.kde.org/show_bug.cgi?id=185296 https://bugs.kde.org/show_bug.cgi?id=186687 https://bugs.kde.org/show_bug.cgi?id=187722
*** Bug 186687 has been marked as a duplicate of this bug. ***
Can confirm this with 4.3RC1, you open a pdf which is landscape format, you print it and it prints portrait, you change the settings to portrait and it prints landscape.
No more mistake with 4.3 RC1.
Confirmed in 4.3 `sed -e 's:landscape:portrait:g' -i okular/core/fileprinter.cpp` fix the bug with our (laserjet networked) printers
Some further note/request: - can somebody tell if print landscape document is working for somebody? if yes, which distro? Do you know if they patched okular? If not, which printers are you using? Ghostscript version? - can Priority be raised? it's an annoying bug for people who print - may Status be changed to CONFIRMED?
I can also confirm this bug with Okular 0.9.1 on KDE 4.3.1 with KUbuntu. The landscape documents also don't scale to fit the paper size of the printer so, text can sometimes be missing etc. Regards,
With kdegraphics-4.3.0-1.fc10 I can still reproduce this. Steps to reproduce: 1. yum install pdfjam 2. wget http://www-i9.informatik.rwth-aachen.de/dateien/lehre/57/2-1%20dw.pdf 3. pdfnup --nup 2x2 "2-1 dw.pdf" 4. okular "2-1 dw-2x2.pdf" 5. Hit CTRL-P (printing from the file menu) 6. Hit ALT-r (Properties button) 7. Notice that Landscape is selected If "Landscape" is selected, the document won't be printed some printers, e.g. the both I tried so far. Since this option is well hidden, it is also a big source of frustration to always have to change this.
I can see this too on my fedora 11 : kdegraphics-4.3.0-1.fc11.i586
*** This bug has been confirmed by popular vote. ***
Created attachment 37367 [details] Sample document which is printed wrong with okular
I have the same issur I thing. I have also uploaded a sample document. Printing with "lpr <pdf-file>" gives me the expected result though.
I can confirm this bug on Arch Linux using: [astan@pyret ~]$ okular --version Qt: 4.5.3 KDE: 4.3.1 (KDE 4.3.1) Okular: 0.9.1
The bug is still present in the current KDE release. Using Kubuntu 9.4 HP LaserJet 1010 ~> okular --version Qt: 4.5.2 KDE: 4.3.2 (KDE 4.3.2) Okular: 0.9.2 Okular also dosn't remember this landscape/portrait option. So every time you want print a page you have to change this option. This gets realy annoying if you only need a few pages of a pdf dokument and every time you have to toggle this option. For me, this looks like as if the printig system and okular trying to detect the orientation of the pdf at the same time, which result in a 90° rotation.
Hej, I investigated the bug a bit, here are the results: The PDF we talk about here have '%%Orientation Landscape' or '%%PageOrientation Landscape' inside, that means CUPS knows that this file is landscape and therefor rotates it automatically when passing the plain file to lpr. In part.cpp:setupPrinter() however, the QPrinter orientation property is set to landscape, because the width of the page is larger than the height. When the PDF is printed then, the code in core/fileprinter.cpp:optionOrientation checks whether the QPrinter orientation property is set to 'landscape' and if so passes '-o landscape' as argument to lpr. So CUPS will find the %%Orientation tag inside the PDF and rotates the page correctly, however it will also see the '-o landscape' option on the command line and rotates the page again -> page is printed incorrectly. I'm a bit helpless here since I don't know how to fix it in the right way. Omitting the code in setupPrinter() for the poppler backend and trust that the orientation is always given inside the PDF?
I think it would be nice to have an opportunity to print pdf as it is - just to disable all Okular's manipulation. By the bug: Is there a way to delete orientation tag from pdf on printing it? Or just make it portrait? As I understand, Adobe Reader do such job on printing when 'auto rotate and fit to page' checkbox is activated. So, there would be (as in Adobe Reader) combobox to choose whether we want to: - auto-rotate and fit to page, - print as it is, - fit to page without rotation, - force print in user-chosen oritntation. P.S. I am not some a specialist in PDF format. So... this is just my suggestion.
@tokoe I know since some time that is part of the problem, the thing is that i also know each printer intreprets cups commands and PS commands as they want so well, it sucks In my opinion we should not add the cups command and let PS be the one at command, but i don't have time, printer nor A4 pages to spare trying to fix the printing mess
I think this is a very annoying bug or even a blocker one.
*** Bug 216944 has been marked as a duplicate of this bug. ***
Me too I would like to see this bug fixed. Having this issue on Fedora 12: $ okular --version Qt: 4.5.3 KDE: 4.3.3 (KDE 4.3.3) Okular: 0.9.3 As to comment 4 and comment 22: I doubt this is a problem specific to A4. Especially comment 20 gives good indication that the page size is not the cause.
I wonder, that kpdf printed automatically alright (like openoffice does too and like acroread with the default „Auto Rotate and Center“- Option). Now with okular (which shall replace kpdf) such problems...
(In reply to comment #26) > I wonder, that kpdf printed automatically alright (like openoffice does too and > like acroread with the default „Auto Rotate and Center“- Option). Now with > okular (which shall replace kpdf) such problems... KDE 3 has a printing system, KDE 4 doesn't. Spot the difference.
(Sorry for my bad english) I have similar problem on mandriva Linux 2010.0 with: Qt: 4.5.3 KDE: 4.3.2 (KDE 4.3.2) Okular: 0.9.2 Source pdf file is a set of slides => each page has landscape sizes. Printer has portrait setting. I tried to print 6 slides per page. Good. But I could not print 8 slides per page. There is no such option. There is no option to rotate slides (to fit them better on page). Then I set printer setting to landscape => I saw on page 6 cut slides.
Bug is still present in KDE 4.4.0 This is so incredibly painful ! Could the severity of this be raised ? KDE 4.4.0, 6 months in the making, is not able to print correctly due to a bug reported one year ago. What a shame.
"KDE 3 has a printing system, KDE 4 doesn't. Spot the difference." That's the key. KDE4 doesn't have a kdeprint like subsytem. What a functional regression from KDE3! I really don't get the whole development practice of KDE in some fields. system-config-printer-kde is another headache about printing. From: http://techbase.kde.org/Schedules/KDE4/4.5_Feature_Plan "TODO - system-config-printer-kde - Restore feature parity with KDEPrint3 where possible." Oh my god. That should already be in a working and "identical-to-kdeprint3-functionality" state in KDE 4.0 which is released in January 2008. 2 whole years, and nothing. Amarok got the same critics too. They totally broke all the stuff and started whole from the ground but at least they care and they are active. And then, what are they doing? plasma desktop, widgets, social networking stuff. Tons of stuff about nepomuk, akonadi, semantik search, etc. Okay, all of those are very promising and exciting innovations but at least start to focus them after completing the essentials of a desktop environment. KDE3 had a kio-bluetooth, KDE4 doesn't still have it. There a tons of things like that. Pff.
#29 and #30, if you are not going to give coding time nor money to fix the issue you should nor really comment because your comments add exactly *zero* value to the issue, we all know printing is broken.
Albert, I'm not trying to start a flame or to demotivate people involved with this. There's a difference between a functionality which was never implemented and one which has been working quite long time in KDE3 and then lost its way to KDE4. Anyway, I posted my #30 comment to kde-core-devel. Continuing through this bug is quiet off-topic. Regards,
(In reply to comment #31) > #29 and #30, if you are not going to give coding time nor money to fix the > issue you should nor really comment because your comments add exactly *zero* > value to the issue, we all know printing is broken. So, Albert, are you saying that KDE developers just don't care about the opinion of their users? The users should not be entitled to their own opinion on KDE because they don't give money or coding time? What is the goal of bug reports? Is this a private club for KDE developers and financial supporters? You know, it is weird, i have always thought that contributing with a bug report is a CONTRIBUTE to the project exactly as it could be with money or coding time because they say not only what is wrong, but also what the users think is IMPORTANT. But of course this supposes that on the other side there is someone that reads them and tries to learn something from them, if nothing else at least what is valuable to their users and what is not, instead than telling to their users that with their comments they add "exactly zero value to the issue". Not only this, but here we have users that are using their time to read this bug report and comment. Is their time less valuable than developer's time? Should they pay someone to have the privilege to tell you what's important? You say "we all know printing is broken". Really? But maybe what you miss to know is that printing is IMPORTANT to a desktop user. And this is what these comments try to point out. After years from the initial release of KDE4 _still_ printing is not working as it should and it did (in KDE3). Is it such a shame if some users try to underline this important aspect trying to get the attention of who CAN and KNOWS how to fix this problem? What is the point of wasting coding time adding useless graphical effects when an important subsystem of KDE still is missing to work properly (when it used to work in KDE3)? Maybe coding special effects is more fun than getting a printer to work out of the box? Do you think KDE users need more special effects or print without having to turn the world upside-down? Do you see the point of these comments now? Do you see WHY they are important just like the coding time of a developer?
(In reply to comment #30) > "KDE 3 has a printing system, KDE 4 doesn't. Spot the difference." > > That's the key. KDE4 doesn't have a kdeprint like subsytem. What a functional > regression from KDE3! I really don't get the whole development practice of KDE > in some fields. Yes, there are some things you don't get. The first and most important is that we (Okular developers, or what's left nowadays) tried *hard* to not be in this situation. We weren't able, kdeprint had no development for more than 6 years and nobody took the effort to make it work as it should have with the kde4/qt4 porting. I personally had fights with other developers especially because of this, and my mailbox can count *hate* emails coming periodially from KDE users because of printing, just like I would have been the one deciding to make printing less a priority (rather the opposite, unsuccessful). Do you think I love the current situation? (In reply to comment #33) > (In reply to comment #31) > > #29 and #30, if you are not going to give coding time nor money to fix the > > issue you should nor really comment because your comments add exactly *zero* > > value to the issue, we all know printing is broken. > > So, Albert, are you saying that KDE developers just don't care about the > opinion of their users? The users should not be entitled to their own opinion > on KDE because they don't give money or coding time? There's a huge difference between "be entitled to their opinion" and "repeating the same concept over and over". As said above, broken or less-than-optimally-working printing is overly known by us. Repeating in each bug report "printing is bad, please fix it!" will not magically fix problems over night. We don't need people to repeat that over and over, we need people to help. > You know, it is weird, i have always thought that contributing with a bug > report is a CONTRIBUTE to the project exactly as it could be with money or > coding time because they say not only what is wrong, but also what the users > think is IMPORTANT. > [...] As I said, we know printing is an important task, yes. If you don't believe so, please read my first paragraph above and tell me for whatever else reason I would had to fight against kdeprint removal, if I would not think that printing is important. But, at the same time, you should try to understand a bit that printing is a rather complex system, which needs a lot more than one day of hacking. And this bug report proves this once more. Okular team is very small (barely to the existance), and kind of "recreating" a "mini" printing system mapping from the few functionalities of the Qt system to our needs is not an easy task. > What is the point of > wasting coding time adding useless graphical effects when an important > subsystem of KDE still is missing to work properly (when it used to work in > KDE3)? Maybe coding special effects is more fun than getting a printer to work > out of the box? Do you think KDE users need more special effects or print > without having to turn the world upside-down? This is an huge false misconception: if a guy is interested in coding desktop effects, most probably he won't do printing stuff. Just like I chose Okular, I would not develop an email client nor a window manager. So, don't think that more people working on some aspects of the desktop environment means less people for other areas; they are unrelated.
(In reply to comment #34) > There's a huge difference between "be entitled to their opinion" and "repeating > the same concept over and over". As said above, broken or > less-than-optimally-working printing is overly known by us. Repeating in each > bug report "printing is bad, please fix it!" will not magically fix problems > over night. > We don't need people to repeat that over and over, we need people to help. Albert said: "if you are not going to give coding time nor money to fix the issue you should nor really comment because your comments add exactly *zero* value to the issue". I answered to this. > As I said, we know printing is an important task, yes. If you don't believe so, > please read my first paragraph above and tell me for whatever else reason I > would had to fight against kdeprint removal, if I would not think that printing > is important. > But, at the same time, you should try to understand a bit that printing is a > rather complex system, which needs a lot more than one day of hacking. And this > bug report proves this once more. > Okular team is very small (barely to the existance), and kind of "recreating" a > "mini" printing system mapping from the few functionalities of the Qt system to > our needs is not an easy task. Okular should not implement its own printing system. It should rely on KDE's printing system. If this bug is not related to Okular but is a general KDE issue then i don't see why this bug is assigned to Okular developers. What will happen? Every program will have to develop it's own printing system? Who took this decision and why? Why should every KDE program have a different printing interface or whole printing subsystem? > This is an huge false misconception: if a guy is interested in coding desktop > effects, most probably he won't do printing stuff. > Just like I chose Okular, I would not develop an email client nor a window > manager. > So, don't think that more people working on some aspects of the desktop > environment means less people for other areas; they are unrelated. What i see, as a KDE user from a long time now, is that for some unknown reason all of a sudden KDE developers have abandoned a desktop environment that _did_ work and replaced it with a different desktop enviromnent that is missing important features and gives priority to absolutely useless aspects (such as graphical effects). I perfectly understand that Okular is not the problem here and i perfectly understand that it is a pain to have users blame you for a problem that is a general KDE problem, but it is not acceptable to say to the users "if you don't pay or don't give code-time then your contribute is zero and so you should not comment". This kind of behaviour is what i criticized. Besides, if this is not an Okular problem but is a general KDE problem (the missing printing subsystem) then, IMO, this bug should be reassigned to KDE-CORE or the like.
(In reply to comment #34) > There's a huge difference between "be entitled to their opinion" and "repeating > the same concept over and over". As said above, broken or > less-than-optimally-working printing is overly known by us. Well, maybe you knew that it was broken, but I didn't, and I was not sure you did know it was, hence the message. Many people installing kde are not aware that printing will be problematic. If you don't want bug reports telling you over and over that printing is over, maybe the best thing to do would be to write it in the announcement; something like KDE 4.4.0 has plenty of nice features, but be aware that printing will be problematic (we know about it, work about it, contributions are welcome) (I am serious: a good announcements should present positive and negative points) It would certainly be the honest hing to do, and people would stop "repeating the same concept over and over". Now, I am interested (and I am sure many other users are interested too): what are the other fundamental things that are known to be broken in KDE 4.4.0 ? Please tell us so that we don't fill in annoying bug reports anymore !
(In reply to comment #35) > (In reply to comment #34) > > There's a huge difference between "be entitled to their opinion" and "repeating > > the same concept over and over". As said above, broken or > > less-than-optimally-working printing is overly known by us. Repeating in each > > bug report "printing is bad, please fix it!" will not magically fix problems > > over night. > > We don't need people to repeat that over and over, we need people to help. > > Albert said: "if you are not going to give coding time nor money to fix the > issue you should nor really comment because your comments add exactly *zero* > value to the issue". > > I answered to this. ... which is exactly what I was talking about: the problem is there, and that comment did not add anything useful to this bug report. > > As I said, we know printing is an important task, yes. If you don't believe so, > > please read my first paragraph above and tell me for whatever else reason I > > would had to fight against kdeprint removal, if I would not think that printing > > is important. > > But, at the same time, you should try to understand a bit that printing is a > > rather complex system, which needs a lot more than one day of hacking. And this > > bug report proves this once more. > > Okular team is very small (barely to the existance), and kind of "recreating" a > > "mini" printing system mapping from the few functionalities of the Qt system to > > our needs is not an easy task. > > Okular should not implement its own printing system. It should rely on KDE's printing system. Why don't you read what I said above, like comment #27? There is *no* KDE printing system in KDE 4. Now, either we want or not, we rely on Qt printing system, which is limited and needs to be worked around. > Every program will have to develop it's own printing system? No, this is mostly an Okular specific issue, due to the way Okular handles document of different types (PDF, DjVu, etc). > What i see, as a KDE user from a long time now, is that for some unknown reason > all of a sudden KDE developers have abandoned a desktop environment that _did_ > work and replaced it with a different desktop enviromnent that is missing > important features and gives priority to absolutely useless aspects (such as > graphical effects). Like people worked on what they preferred before, they do now as well. Didn't you read above that I said nobody was working on KDE3's kdeprint for years and years? The fact that kdeprint "worked" does not imply (sadly) that it was bug free, nor it was able to handle features in more recent CUPS versions. Just think kdeprint was up to the features of CUPS 1.0, which is was released more than 6 years ago! > but it is not acceptable to say to the > users "if you don't pay or don't give code-time then your contribute is zero > and so you should not comment". This kind of behaviour is what i criticized. Now try to be in our shoes just for a short moment: what you would think if people would phone you every hour just saying "it does not work!" and then hanging up? This is getting annoying. Just before I get misunderstood: I have nothing against constructive comments (eg "I tried this and that and got slightly different results"), but I do find unuseful opening a bug report, skip all the comments in it and just write "you bad poeple, this is a huge bug and please fix it!". (In reply to comment #36) > Please tell us so that we don't fill in annoying bug reports anymore ! The problem is not "annoying bug reports", see above.
(In reply to comment #37) > Why don't you read what I said above, like comment #27? There is *no* KDE > printing system in KDE 4. > Now, either we want or not, we rely on Qt printing system, which is limited and > needs to be worked around. Can't you just allow to print to a command and allow to have a list of commandlines to select from and maybe a history? Then the pdf can be just send to lpr and one can add the most often used options, e.g. duplex or not and still print from the viewer instead.
> So, Albert, are you saying that KDE developers just don't care about the > opinion of their users? No, I don't know what other KDE developers think, but i do care about the opinion of users > The users should not be entitled to their own opinion > on KDE because they don't give money or coding time? No, everyone is entitled to have an opinion > What is the goal of bug reports? Reporting non known bugs or giving extra information on existing ones > Is this a private club for KDE developers and financial supporters? No > You know, it is weird, i have always thought that contributing with a bug > report is a CONTRIBUTE to the project exactly as it could be with money or > coding time because they say not only what is wrong, but also what the users > think is IMPORTANT. This is comment #36 of a lot of printing related bugs, you are not CONTRIBUTING anything by adding yet another "you suck because printing is not fixed" comment. On the other hand we appreciate a lot the contribution of unknown bugs or addition of extra information to existing ones. > But of course this supposes that on the other side there is > someone that reads them and tries to learn something from them, > if nothing else at least what is valuable to their users and what is not, > instead than telling to their users that with their comments they add > "exactly zero value to the issue". Should i lie? Those comment added exactly zero value to the issue, in fact they possibily added negative value > Not only this, but here we have users that are using their time to read > this bug report and comment. > Is their time less valuable than developer's time? I don't care how others spend their time > Should they pay someone to have the privilege to tell you what's important? If you want a privilege, yes you have to pay or reward me in some other way. > You say "we all know printing is broken". Really? With "we" meaning the Okular developers, at which this bug is addressed, yes, really. > But maybe what you miss to know is that printing is IMPORTANT to a desktop > user. No, i do not miss that. > And this is what these comments try to point out. No, a comment saying "printing is still not fixed, you suck" does not try to point that out, it's a personal attack against the developers, and with a very weird rationale, some people think personal attacks is going to give them a positive answer from a developer > After years from the initial release of KDE4 _still_ > printing is not working as it should and it did (in KDE3). Again, we know > Is it such a shame if some users try to underline this important aspect > trying to get the attention of who CAN and KNOWS how to fix this problem? We know it's important. > What is the point of wasting coding time adding useless graphical effects > when an important subsystem of KDE still is missing to work properly > (when it used to work in KDE3)? This is mostly a volunteer run project, people waste their time in what they like. There are some ways to change what a developer wants to code, one of them is money, there are others, but they not involve the words "suck", "waste", etc. > Maybe coding special effects is more fun than getting a printer to work > out of the box? For some developers, for sure. > Do you think KDE users need more special effects or print > without having to turn the world upside-down? What i think it's non interesting here since in your words "i'm not wasting my time in coding graphical effects" > Do you see the point of these comments now? No > Do you see WHY they are important just like the coding time of a developer? No, hate comments or comments that add no information to a known bug just "remove" time from developers that can fix the issue, because we have to find a polite-ish way to answer your mail.
> > No, a comment saying "printing is still not fixed, you suck" does not try to > point that out, it's a personal attack against the developers, and with a very > weird rationale, some people think personal attacks is going to give them a > positive answer from a developer > Albert, nobody in this report -including me- talked in that tone (actually the only 'sucks' occurence belongs to you #28 :) (just kidding to calm down the thread)) And be sure that every user which had commented on this issue did that because they care about the developers, their efforts and the final product which they're using passionately as their desktop environment. And eventhough you think that the recent comments added negative value to the issue, I clearly got the points and the facts about the problem. Regards,
> Well, maybe you knew that it was broken, but I didn't, and I was not sure you > did know it was, hence the message. So you read the description and 28 comments of this bug and still did not know it was broken? Really? Also please read your comment #29 and say me what information you added to this bug?
I'm using the following workaround from 2009-05-05 #c5, it work for me, could some developer spread the light and write here _where_ it is un-appropriate? > # we have problem with landscape pdf and hp printers > sed -e 's:landscape:portrait:g' -i okular/core/fileprinter.cpp \ > || die "failed sed 1 " Hopefully having it explained and documented may put more eyes on this and possibly more brains ;) Are we waiting for a "proper" solution? What does it need to achieve, which are te possible regression, please told we, so at least we can flame with some clue. cheers
I think the option for choosing the portrait or landscape mode should be accessible in Options tab just below the page number selection, not in printer properties. Such a placement is illogical for me. All the important parameters of printing should be grouped on one scree or tab.
#43 The printing dialog is part of Qt, bug them at http://bugreports.qt.nokia.com/ if you think there is a better sensible placing for the options.
interesting discussion. I didnt know that the developpers know that printing is broken. Concerning the bug, i had the same problem today. If you need some further information, i am happy to provide you some. Thanks for the work on the print system, if you need money, maybe you could start some fundraising stuff like the people from the diaspora project did (compeletely off topic). I am sure that a lot of useres would donate some money. I usually donated to the KDE project itself, but if there is a lack of manpower and money for this crucial part of the KDE desktop, i am willing to donate directly.
Hi, KDE 4.5 RC1 - still not fixed :-( I'll try a workaround from #c5 but it is only a workaround.
Hi KDE Friends Me too has problem ;-). I tried to print a A4 PDF document which was autogenerated by a server from my University. In the print dialog of Okular I set the Landscape Option but it didn't work. Then I tried to set the default option to Landscape in the HP Driver (HPLIP 3.10.5 with Device Manager 15.0 (Qt4)) related GUI. But this also didn't help to solve the problem. Version 0.10.2 KDE 4.4.2 (KDE 4.4.2) I try to attach the document having the problem. Regards, Sebastian Morkisch
Created attachment 51773 [details] The document which will not be printed in Landscape
Still present in KDE 4.5.1.
I had filed the same bug as #243953 therefore I report here what I have reported in #243953. As the same "problem" is in the latest Kubuntu Maevrick distribution I decided to investigate a little bit further the probem : - I built a landscape sheet with Kword and saved it in pdf file. - I opened it with okular and print it : if you want to get the sheet correctly you need to check "portrait". - I opened the same sheet with acroread to check how this application was handling the printing action : it is exactly the same : the sheet being built as landscape is correctly printed if you leave portrait checked. So portrait and landscape in printer settings have different meanings than in the page setting of applications creating the page : - in printer setting portrait leaves the page as is (ldanscape correctly printed), whereas landscape forces printer to print the page in a 90° direction compared to what you expect to get. At the end of the day all this is very confusing and I simply suggest the following : - like in acroread show the page as is (landfscape or portait as built by the creating application), - but to improve user comprehension add another icon for the page as printed depending of which radio button checked. Like this everybody will be happy. Thanks.
*** Bug 243953 has been marked as a duplicate of this bug. ***
To #50 and others, I also looked at the KDE settings-manager hardware->printer->your printer options while investigating. Have a look there at the 'print task options' tab of your the printer settings and check what 'orientation' setting you have. To #50 what if you have both landscape and portrait pages in the same pdf ?
(In reply to comment #52) > To #50 and others, I also looked at the KDE settings-manager > hardware->printer->your printer options while investigating. > > Have a look there at the 'print task options' tab of your the printer settings > and check what 'orientation' setting you have. > > To #50 what if you have both landscape and portrait pages in the same pdf ? My Print Task Setting --> Orientation --> Automatic Regards, Semo
I can confirm this in KDE 4.6 for at least two different printers. So I guess it's hardly a printer driver problem. To get a right printing I have to activate portrait instead of the automatically chosen landscape.
Funny thing, I had the same issue with an old version of Adobe Reader on Windows (with a file exhibiting the same problem in Okular). Do not know if it is the same underlying problem.
Hi, this bug is more than 2 years old now, and still up to date. Just like Bug 198609. For me it's annyoing, I always need to install acrobat reader on every computer to be able to print landscape documents. Which makes okular.... "useless". I'ld like to use it, but if I can't print... Just out of curiosity: Why is this problem not solved? To difficult to be solved? Nobody feels responsible? Thanks Karl
similar to how it's done in comment #5 you can _try_ to modify the binary file: mkdir ~/my_bacakup_dir cp /usr/lib*/libokularcore.so* ~/my_bacakup_dir sudo sed -e 's:landscape:portrait :g' -i /usr/lib*/libokularcore.so notes: - it's untested, I do patch the sources from year 2009 - notice the "space" after portrait, it's needed, you're patching a binary file - this operation may (or may not) interfere with your package manager good luck a side note: what make me fuck**g nervous about this bug is the fact NOBODY CARED TO EXPLAIN what refrain to fix a so trivial bug which is so annoying. The thing which go nearer to an answer has been "we don't have a print manager anymore in kde 4 we had it in kde 3"
I understand that your proposition is a workaround. I will not use it because I would have to do it after every update.. to your notes: does it mean that from now on this bug will be fixed in all coming versions of okular? to your side note: why is there no print manager in KDE4 any more?
(In reply to comment #58) > I understand that your proposition is a workaround. it is, and an ugly one > I will not use it because I would have to do it after every update.. w/o the patch okular is useless so I do it after every update. Using gentoo so it's easier but not an assle anyway. > to your notes: > does it mean that from now on this bug will be fixed in all coming versions of > okular? not at all, I'm not a kde developer with access to okular sources > > to your side note: > why is there no print manager in KDE4 any more? better ask to developers, or in the forums, or in irc, please keep us informed if you find it out.
my english suck, but that's a different bug
:D any KDE-Developper around who could solve this bug? I'll try to set the priority to high. It seems to be an easy to resolve problem with very "bad" consequences
hmm, I can't change the priority.... so: KDE-Developpers: please do so thanks
There's an easy workaround: reset the orientation to portrait and it will print the landscape document as landscape. There's some confusion in the code between "portrait == long side is vertical, landscape == long side is horizontal" and "portrait == print in the original orientation, landscape == print rotated" semantics.
it's not working if you print two pages per page... and I have a better workaround ;): acrobat reader... Please somebody feel responsiblöe for solving this bug
And does the sed -e 's:landscape:portrait :g' -i /usr/lib*/libokularcore.so hack work in that situation?
@Francesco: can you answer this question?
(In reply to comment #64) > it's not working if you print two pages per page... > and I have a better workaround ;): acrobat reader... > > Please somebody feel responsiblöe for solving this bug mkdir ~/my_backup_dir cp /usr/lib*/libokularcore.so* ~/my_backup_dir sudo sed -i -e 's:landscape:portrait :g' -i /usr/lib*/libokularcore.so.1.6.0 I've now tested this on suse kde 4.6.0, if you have different versions you may need to change libokularcore.so.1.6.0 to libokularcore.so.1.?.0 Also noticed the added option to sed "-i" (in-place), w/o it will print on terminal the file (not very useful) It work as is, both printing w/o changing _any_setting, and also changing _only_ multiple pages per page setting. have fun!
i think bug #235438 is a duplicate of this.
bug #222258 seems to be a duplicate too.
*** Bug 235438 has been marked as a duplicate of this bug. ***
*** Bug 222258 has been marked as a duplicate of this bug. ***
I can confirm this bug with a networked Brother printer. I set the printer's settings to automatically rotate documents (System Settings -> Printer Configuration -> [My Printer] -> Job Options -> Orientation -> Automatic Rotation). I can print portrait PDFs just fine. Landscape documents automatically set themselves as landscape in the print dialog (which is correct) but they print as portrait. It is only until I set the orientation to portrait in the print dialog that the page prints correctly (as landscape). I am using Kubuntu (if it matters). Qt: 4.7.0 KDE Development Platform: 4.6.1 (4.6.1) Okular: 0.12.1 OpEd: I think this bug is annoying and needs to be fixed but I think it is unfortunate the way some have reacted to this bug. I recently installed a new USB printer (not the one listed in this comment) and all I did was turn the printer on, plug it in, and it just worked with KDE. The time and effort that has been put into the printing system of KDE is amazing and I am truly appreciative for that. The fact that I could plug in my USB printer and have it just work without any configuration is amazing and shows how much time the developers of KDE have put into the various subsystems.
(In reply to comment #53) > (In reply to comment #52) > > To #50 and others, I also looked at the KDE settings-manager > > hardware->printer->your printer options while investigating. > > > > Have a look there at the 'print task options' tab of your the printer settings > > and check what 'orientation' setting you have. > > > > To #50 what if you have both landscape and portrait pages in the same pdf ? > My Print Task Setting --> Orientation --> Automatic For full usability of the print dialog, I suggest these options: - match page's short edge to paper's short edge - match page's short edge to paper's long edge (i.e. rotate 90') - force all pages to have bottom parallel to paper's short edge - force all pages to have bottom parallel to paper's long edge IMO, "portrait" and "landscape" in the print dialog causes only confusion. Those names are good when creating the document, but after it gets prepared for printing (like in PDF) the orientation is already defined by page's content.
I am using KDE 4.6.2, Fedora 15 beta. I noticed that okular is unable to detect the orientation of some (landscape) pdf properly, then i found about this bugreport... ---- PTST_Landscape01.pdf --> single-page landscape document PTST_Portrait01.pdf ---> single-page portrait document ---- Okular: * Print PTST_Landscape01.pdf (default - LANDSCAPE) -> BAD ( !! a landscape doc in portrait !!) * Print PTST_Landscape01.pdf (orientation to PORTRAIT) -> GOOD (! Incorrect behaviour !) * Print PTST_Portrait01.pdf (default - PORTRAIT) -> GOOD * Print PTST_Portrait01.pdf (orientation to LANDSCAPE) -> BAD (Correct behaviour) LibreOffice * Print PTST_Landscape01.pdf (default - LANDSCAPE) -> GOOD * Print PTST_Landscape01.pdf (orientation to PORTRAIT) -> BAD (Correct behaviour) * Print PTST_Portrait01.pdf (default - PORTRAIT) -> GOOD * Print PTST_Portrait01.pdf (orientation to LANDSCAPE) -> BAD (Correct behaviour) I just configured LibreOffice-Writer as the default pdf application as a workaround. >> My Print Task Setting --> Orientation --> Automatic I tried with it, but when i changed the default 'auto', the option 'auto' just "disappeared" and cannot be re-selected, so i left it in 'portrait'.
Does this bug is in plans to fix for KDE 4.7? How can we force developers to solve it?
(In reply to comment #75) > Does this bug is in plans to fix for KDE 4.7? How can we force developers to > solve it? I gave up on this one. Nobody will ever fix it. btw I don't use okular any more... This bug just makes it useless for me. I don't think that any devellopper is still reading here...
#76: We developers got fed up of the abuse happened in this and other various bugs and moved to greener pastures By the way if you don't use Okular anymore personally I would be grateful if you stop doing worthless comments on our bugs, you might even want to unsubscribe yourself from this bug.
Thank you for your feedback. Given the history of comments on this bug I can really understand the developer's attitude here, but at the same time I would find it unfortunate if this bug is really being ignored for that reason. In my (humble) opinion this bug does represent a fairly important user experience flaw. All the comments that are in this report so far can't be undone unfortunately. But is there something us users can do to rebalance this situation in a way the developers are willing to take on this issue ?
No, please... It's bug 157284 all over again. Out of curiosity, is there any other reason not to fix this bug apart from "punishing bad users" (and thus all KDE users indirectly)?
@Geert: Yes, leave it lay low, don't give us anymore bad comments and we might come back in the future, or you might be lucky and get some new developer to fix it. @Alvaro: Yes it is, get over it, we are humans and don't like to work on things that don't give us pleasure. We had this discussion there already so please don't repeat it again.
Fair enough. However, I stand by what I said then: I think this does harm KDE's reputation. Anyway, I understand you so I'll leave it here. I hope working on Okular gets fun again in the future. Good luck!
Hi, Please don't misunderstand I'm not trying to "attack" anybody body here or to "destroy" the benefit of anybody's work here. I'm simply frustrated of having great software here which I can't use. I just did the effort and started to read the whole thread through... I wanted... I gave up at post number #45 (something like that). You're right, there are a lot of useless long comments that don't advance the situation, blaming QT, blaming the missing print-system in KDE... Trying to get forward: If I understand it right, like posted for example in #67, the solution of this bug is known already, you simply have to search/replace through the code of this library. If it is so "easy", then please do so. If it's not that easy, and the problem is located in any other place of KDE4, please let us know, so we can put our votes to this "bugs". Thanks Karl
Created attachment 59734 [details] Patch for the PDF orientation problem First of all I am not a Okular/KDE developer ... just a normal user that lost lots of paper in this bug. The patch I would like to propose, fixes the Bug for PDF documents. But the Bug may be present also for other documents. The patch itself was created against SVN Revision 1230782. The Problem was, that okular detected a landscape document and passed the landscape option to cups. Cups itself took the page and rotated it and that results in the Bug we see. So the main point of this is: If you have a Landscape document and wanted it printed as is than you have to pass "portrait" as option to cups. If you want to print a landscape document in portrait you have to pass portrait as option to cups. Thats why the mentioned workaround works, I haven't tested it but i bet that the workaround fails for portrait documents. Because for portrait documents the options work as one would expect. So hopefully the patch finds it way into the trunk. Falk
That's certainly an improvement over the status quo and I think it should be applied. However, I suspect there might still be issues with mixed portrait/landscape documents.
I just checked it. With the patch also mixed documents now print as one would expect. Falk
@Kevin: If you think the patch is correct and are prepared to take the blame i don't see why you should not commit it @Falk: And you have checked all the other formats we support? Also files whose width is bigger than his height but are not marked as rotated in the pdf properties? And files that are marked as rotated at 270º?
As I am just user, I try to contribute as I can. I googled and found, that a few years ago Evince, Acrobat reader, kpdf had similar problem. And the solution was the same, as said in comment #21 by Pavel: we need implement "auto-rotate and center" and "scale" options. Auto-rotate option should be used by default. Evince introduced these options with these commits: http://gitorious.org/evince/evince-document-centric/commit/207192392258ab19ba71dbcfcc613912a5fc4c2c http://gitorious.org/evince/evince-document-centric/commit/7a84044cdf9470e21fd8c2d65b253a4eeed203fc I think, A skilled programer should found ideas about fixing Okular in these commits.
@Albert As I already stated, the patch fixes *only* PDFs all other formats maybe still encounter the problem. But they should be easily patchable too because we now know whats wrong. If you can point me to a test set of documents (I expect that something like this exists). I'm willing to print them and see if it works and update the patch if something goes wrong. I know that there is still a long way to go, but some one had to do the first step. @Mindaugas I think auto-center/rotate/scale would be a nice feature to have, but I think that it would be overkill for this bug. Just my two cent. Falk
@Falk: Sorry, as I already stated I don't feel like working on this bug, i was just giving some quick advice
So for starters, I think it's a bad idea to boycott this bug. Many users are being annoyed by it and only a small vocal bunch of them complained on this bug. That said, I understand your feeling, rude users don't make me want to work on something either. About 270° vs. 90° rotations, the UI only knows Portrait and Landscape, so I think this cannot be implemented completely without a UI change. I do suspect you may end up with upside-down documents if you print landscape documents in portrait (i.e. rotated mode). Actually, I'd expect the 90°-rotated documents to show up upside down and the 270°-rotated documents to show up correctly when printed in portrait mode. (Of course, this depends on what your definition of 90° vs. 270° is: Do you use the positive angle orientation generally used in mathematics (counterclockwise) or clockwise angle orientation? Do the PDF spec and CUPS agree on the angle orientation?) But the common case is to print the documents in their original orientation, where this problem does not occur. What this patch solves is the problem that "Portrait" actually meant "Don't rotate" and "Landscape" actually meant "Rotate 90°". One thing that irritates me about the patch is that it adds some additional code to detect the orientation of the document. That detection must be already made somewhere, or we wouldn't get "Landscape" preselected for landscape documents. I'd like the detection code to be reused, because 1. that'd allow fixing the other format backends more easily and 2. it'd make sure that the detection mechanisms match, so "Landscape" really only gets preselected if and only if it will be interpreted as "Don't rotate". Next, unfortunately, the Evince code cannot be reused at all. The UI part is in GTK+ and the printing is done using Cairo, which is very different from Okular's Qt UI and printing code based on sending entire files to CUPS. Now about other formats, the bug is almost certainly still present for those because they don't pass any orientation. (The default is portrait, which behaves as before the patch.) Falk, there are plenty of ps.gz and dvi files around the net, search e.g. Google Scholar for some papers and you'll find plenty of them. OpenDocument odt files can easily be made with OpenOffice.org Writer / LibreOffice Writer or KWord / Calligra Words. Other formats, e.g. ePub or DjVu, may be harder to find, but there should be example files for those formats somewhere, too. That said, the patch is also a prerequisite for making the other formats work, as it adds the required API.
@Kevin It was my first Idea was to reuse the ocular orientation detection code. But I didn't found a way to pass the information from there to the actual printer code without breaking the complete APIs in between. As you may have noticed only a QPrinter Object is passed around and that is unable to handle the additional piece information we need. Thats why I added the additional code block.
Falk, to clarify: do you mean that the orientation detection code works differently than what is already in Okular? You didn't just cut-and-paste, because the types that they work on are different earlier on vs down in the printer code?
The orientation detection code isn't copy paste, because it works over a different data structure. But the idea behind it is the same. It uses the page height and width to decide if a the page is landscape or portrait. If the majority of the pages are in landscape the document orientation is set to landscape. But as Kevin already pointed out, it is not very clever to have the detection code at two places. Because as soon as one is changed and the other one isn't the printing will break again. The okular printer page orientation detection is in a file called 'part.cpp' in a function called 'setupPrinter'. But from there I see no way of passing the information detected there to the printer code without breaking the API for the so called document generators. So for now it looks like we have to live with the fact that the document orientation is detected twice by different code.
I'm sure there must be some way to get this right, I'm going to have a look at the code.
*** Bug 274147 has been marked as a duplicate of this bug. ***
This is what I came up with: https://git.reviewboard.kde.org/r/101513/ I fixed the duplicate code, moving the orientation detection to the Okular::Document class in core/document.cpp. I also adapted the other 3 generators using FilePrinter::printFile (in addition to the Poppler/PDF one). The FilePrinter::printFiles function (which takes multiple files at once) still doesn't do orientation properly, but I don't see this being used anywhere in Okular. I haven't done any testing yet though. Falk, can you please test this patch? (On my side, I'm going to build it in Fedora's Koji build system shortly to verify that it is compilable and hopefully get more people to test it.)
I updated the review request with a fixed patch which actually compiles. :-) A rediffed version of the above patch which applies against the kdegraphics-4.6.3 release tarball can be found in Fedora's distribution git repository: http://pkgs.fedoraproject.org/gitweb/?p=kdegraphics.git;a=blob;f=kdegraphics-4.6.3-okular-landscape.patch;h=a434c146375f463df8ae3670d2286f1f0cc3abb5;hb=HEAD I have verified that this patch builds successfully for Fedora 15: http://koji.fedoraproject.org/koji/buildinfo?buildID=246374
I made some builds for Fedora users, which I want to push as updates soon. A build for Fedora 15 (4.6.3) is now available for testing: http://koji.fedoraproject.org/koji/buildinfo?buildID=246374 A build for Fedora 14 (4.6.3) is now available for testing: http://koji.fedoraproject.org/koji/buildinfo?buildID=246376 A build for Fedora 13 (4.5.5) is now running: http://koji.fedoraproject.org/koji/buildinfo?buildID=246378 I would like some confirmation that the patch works before pushing updates. The feedback is also needed for getting the patch applied in upstream Okular.
Hi Kevin, I reviewed the code changes and tested your patch with my test documents. PDF is ok. PS prints ok but the landscape document is not detected as landscape. So the Bug won't be visible. This have to be checked if it is caused by the changes in the document orientation code. DVI fails to print and to render in okular, but I think this is another bug. I'll attach the test files.
Created attachment 60703 [details] Landscape DVI that fails to render and print Taken from http://amath.colorado.edu/documentation/LaTeX/reference/landscape/
Created attachment 60704 [details] Landscape ps that is detected as portrait Taken from: http://amath.colorado.edu/documentation/LaTeX/reference/landscape/
Hi ! Sorry for adding some more noise : I read 90% of this thread, and it seems that the amount of comments and the disagreeable tone used by some people disgusted some developers to try to fix it. This is 100% understandable (KDE devs work for pleasure and not to be harassed) and unfortunate at the same time (as it affects almost everyone printing stuff). Suggestion : could there be a way (for triagers/developers) to highlight the most enlightening comments / hide by default the most useless ones ? (as on osnews for instance) As a bugreport gets popular, it will always drain some annoying people, which may just represent 0.05% of the user but get all the attention.
Can we commit my patch? It has been in stable Fedora 15 updates since Monday, and Fedora updates-testing for a few weeks before that, with no complaints whatsoever, and it definitely does fix this frequently reported bug.
As i said already in this bug "If you think the patch is correct and are prepared to take the blame i don't see why you should not commit it", but at least you should fix the FIXMEs in your code. You are also breaking BC of the okular core library which is something we do not like. Also did you try as I asked PDF files where different pages have different orientations?
(In reply to comment #103) > Can we commit my patch? It has been in stable Fedora 15 updates since Monday, > and Fedora updates-testing for a few weeks before that, with no complaints > whatsoever, and it definitely does fix this frequently reported bug. The patch work here on a gentoo system with kde 4.6.3, would be nice if you commit it (provided you have a kde git account), as suggested by Albert Astals Cid in c#104 and take the applauses. I've also printed succesfully pdf with mixed page orientations.
> but at least you should fix the FIXMEs in your code. As far as I can tell, the one function with a FIXME in it (FilePrinter::printFiles, as opposed to FilePrinter::printFile which is what is actually being used) is used nowhere in all of Okular. (I searched the entire code for uses of them and didn't find any.) I have no idea why it's there in the first place. If you think I should just remove that unused function, I can do it. But I didn't want to do that without knowing why it's there… > You are also breaking BC of the okular core library which is something we do > not like. It is necessary to make those API changes to fix this problem cleanly. It could probably be hacked around without adding those extra function arguments, but that doesn't strike me as a good long-term solution. > Also did you try as I asked PDF files where different pages have different > orientations? That case can't really be handled any worse than the status quo, but comment #105 now confirms that my patch also works in that case.
(In reply to comment #106) > > but at least you should fix the FIXMEs in your code. > > As far as I can tell, the one function with a FIXME in it > (FilePrinter::printFiles, as opposed to FilePrinter::printFile which is what is > actually being used) is used nowhere in all of Okular. (I searched the entire > code for uses of them and didn't find any.) I have no idea why it's there in > the first place. > > If you think I should just remove that unused function, I can do it. See below. > > You are also breaking BC of the okular core library which is something we do > > not like. > > It is necessary to make those API changes to fix this problem cleanly. It could > probably be hacked around without adding those extra function arguments, but > that doesn't strike me as a good long-term solution. In the long term: when the BC of okular core will be broken, the deprecate functions will be removed. So yes, you will add new functions without breaking okular core's ABI, if you want your patch in.
This is just ridiculous. What's the point of keeping binary compatibility in a library Okular is the only user of? What other excuses are you going to come up with not to fix this bug?
(In reply to comment #108) > This is just ridiculous. Just for you, really. > What's the point of keeping binary compatibility in a > library Okular is the only user of? We try to have also backends written by 3rd parties. > What other excuses are you going to come up with not to fix this bug? Oh come on, I didn't say that won't be accepted at all, just that it will accepted once it is fixed to not break the okular core BC. Reading that as "excuse" is just wrong on your side.
Does the patch not break djvu, dvi and ps that use the same method you modified but you are not passing/calculating the correct value? If you do not need to pass/calculate the value, doesn't that mean that is a bug just in the pdf backend and you could just fix it there without modifying so much stuff?
My patch fixes all the backends to pass the correct value. As for binary compatibility, do we need binary compatibility also for the protected functions in FilePrinter or only for the public ones?
(Falk's original patch was incomplete and only touched the PDF backend. My version which fixes all backends is at https://git.reviewboard.kde.org/r/101513/ . I'm currently adding all the deprecated overloads to keep BC.)
Protected methods are part of the API, so yes.
(In reply to comment #111) > As for binary compatibility, do we need binary compatibility also for the > protected functions in FilePrinter or only for the public ones? For the public ones for sure. About the protected methods: they should have not added that way at all, originally, this is something that slipped in. Most probably you can just add the new functions as static inside the .cpp (inside an anonymous namespace to be safe, even).
I updated my review request to keep binary compatibility: https://git.reviewboard.kde.org/r/101513/
Git commit e001fbab55aceef62ad9ca2bb87a170dacfe3fdd by Kevin Kofler. Committed on 06/06/2011 at 00:40. Pushed by kkofler into branch 'master'. Fix landscape documents getting printed in portrait format if "Landscape" is selected in the print dialog (the default). Partly based on a patch by Falk from KDE bug #181290. BUG: 181290 REVIEW: 101513 M +10 -1 core/document.h M +1 -1 generators/djvu/generator_djvu.cpp M +57 -7 core/fileprinter.h M +22 -0 core/document.cpp M +5 -2 generators/dvi/dviexport.h M +2 -2 generators/dvi/dviRenderer.h M +1 -0 generators/poppler/generator_pdf.cpp M +5 -3 generators/dvi/dviexport.cpp M +60 -11 core/fileprinter.cpp M +2 -2 generators/dvi/dviRenderer.cpp M +1 -1 generators/spectre/generator_ghostview.cpp M +1 -1 generators/dvi/generator_dvi.cpp M +1 -18 part.cpp http://commits.kde.org/okular/e001fbab55aceef62ad9ca2bb87a170dacfe3fdd
Thanks!
I forgot to put in a FIXED-IN tag, so let's make it clear: This fix will be in 4.8.0. 4.7.0 has already been released, and the fix requires new APIs in the Okular core, so I'm probably not supposed to backport it for 4.7.x.
APPLAUSES !1!
I looked forward to see this solution, I appricate it dearly and I can hardly wait to see kde4.8. But does anybody see a possibilty to port this solution in some way to kde 4.4.5. Since we use a debian distribution in our office, we really could make use of it. Since I'm no developer I don't now where to look.
I'd like to see a backport to this - the problem is very annoying and it will take some of us years to get to 4.8...
For 4.7 there might be chances to backport (if Kevin wants to do it), for 4.4.x, I doubt anyone will do from KDE. Ask the Debian packagers to include the patch in their releases (if it applies cleanly at all).
I'd like this backported also, but I don't want to do this if the Okular maintainers don't want it done, it's not my program.
With suse 11.4 kde and suse 12.1 I have the same problem with okular If I try to printa pdf document with landscape configuration I get a vertical printing oth left part of the document , in the same time if I do the same with acroread I have no problem for your information same problem with libreoffice , but good behaviour with openoffice or firefox or thunderbird
the problem I describe in comment 24 is for okular version 0.12 kde version 4.6 and also for version kde 4.7
It will be fixed in 4.8.0. The problem with backporting it is that it has to add functions to the okularcore API, and AIUI the Okular maintainers don't want API additions there in a release branch. In any case, I don't want to make them without their OK and they haven't replied one way or the other. Thus, I ask again: Okular developers, are you OK with me backporting this to 4.7.x or do you want me NOT to backport it? (I'd at least like an answer, even if it is a "no".)
I answered already ages ago. No new API in stable releases.
And meanwhile we will leave this BUG unfixed in our stable releases. :-/ (IMHO the KDE policy really needs to be changed so that bug fixes MUST be backported rather than that they can be backported as now.) So send all complaints about this bug not being fixed in 4.7.x directly to the Okular developers, I cannot do anything about it.
That, or nag your distro to backport the fix, or switch to Fedora, which has been shipping the fix for months.
openSUSE has already backported patch. More details from https://bugzilla.novell.com/show_bug.cgi?id=625122 in https://build.opensuse.org/request/show/91021 If you have openSUSE 11.4 you can install okular-4.7.3-21.1.i586.rpm or okular-4.7.3-21.1.x86_64.rpm RPM package from https://build.opensuse.org/package/binaries?package=okular&project=KDE%3ADistro%3AFactory&repository=openSUSE_11.4 (in http://download.opensuse.org/repositories/KDE:/Distro:/Factory/openSUSE_11.4/ repository at the moment is still not-pached okular-4.7.3-20)
Thanks in opensuse 11.4 kde I have tried to instal okular 4.7.3.21 with one click instal , But there is a problem : one depenciy is not deliver ( libqt4-x11...) I have accepted to break the dependency but of course Okular is not launched when I try to do it And for kde 4.7 deliver with 4.72.31 ??? Thanks
Pierre, Maybe you want to add additional repository, like http://download.opensuse.org/repositories/KDE:/Release:/47/openSUSE_11.4/ to solve dependencies.
I have installed the repository for kde 4.7 as you wrote , but it seems that the dependebcy which is necessary is not delivered . So I prefer to stay in my situation and wait when Okular will bee usable in better conditions.. or use Evinc instead of okular the bug is not young and it is shade not to have it coorected in the normal situation And Is not normal that the new version of suse 12.1 use not the las good version of okular for exemple Thanks for the informations
*** Bug 178956 has been marked as a duplicate of this bug. ***
Short question, in which version of Okular will this bug be fixed? Only have 4.7.4 in the debian repositories and just ran across this bug again (like every second time I try to print something :P), so I'm really looking forward to it.
As already written several times in the previous comments and indicated in the "fixed by" field, this was fixed in 4.8.0. The 4.7 branch is no longer maintained, and back when it was, the Okular maintainers refused to backport the fix because it makes additions to the API of an Okular library only used by Okular itself and by Okular backends. They wanted Okular backends compiled against 4.7.4 to also work with 4.7.0 (forward compatibility) and found that more important than fixing this bug.
Yes, we the Okular maintainer eat babies for breakfast. Kevin, get over it, you always can't win and complaining forever won't help you.
I didn't complain, I just explained to the user WHY his Okular is still broken.
Thanks – I read most previous posts, and I also saw that it was fixed in 4.8; At this place, thanks for the fix. What I wondered, maybe not expressed that well, I've now upgraded to KDE 4.8 and my Okular shows as version 0.13.3 and in apt as 4.7.4 still, but in the About dialog of Okular it also says «Using KDE Development Platform 4.8.3 (4.8.3)»; Is the fix already included in this version or only in 0.14?
If it shows as 4.7.4 in apt it's because it's version 4.7.4, otherwise the packagers have done a huge mistake.
You appear to have version 4.7.4 of Okular, but version 4.8.3 of kdelibs. (That is possible, because kdelibs is backwards-compatible, so an older Okular on a newer kdelibs should always work.) The bug and its fix are in Okular, not in kdelibs, so the Okular version is the one that matters.
Okay, thanks for the information! Will try to keep that in mind for the next print :) Or not – saw that 4.8.4 just arrived! Cool.
i am running opensuse 13.1 and i can not print in landscape mode with okular # rpm -qf /usr/bin/okular okular-4.11.5-150.1.x86_64 # rpm -qf /usr/bin/kde4 kdebase4-runtime-4.11.5-482.6.x86_64
*** Removed by KDE Sysadmin due to violation of abuse policies ***
I was just hit by this bug, so it's not fixed. I'm using 4:15.08.3 (Debian testing).
Don't expect a "me too" in a bug with 147 comments to cause the developers to do something. If you're convinced you have this bug, open a new bug with clear instructions of what you do and how to reproduce it.