GNOME Bugzilla – Bug 168896
Rotation PDF documents
Last modified: 2005-06-14 21:26:03 UTC
I'd like to request the ability to rotate the PDF, which is a critical feature. As of evince-0.1.5-1, part of Fedora Core Rawhide, evince is unable to rotate the PDF document.
Bryan do you have any suggestions on how to implement this ui wise? I need to look if xpdf backend support this.
So the backend allow this easily. We need to figure out the UI details... Can you elaborate a bit on the use case of this? Quoting irc: clarkbw so the fundamental problem is that some pdf's are created with the incorrect landscape/portrait layout embedded? * clarkbw is pretty sure that pdf's encode that info, yes? Is this correct?
And... this may be a totally crack idea but... if that's the use case would a way to override the pdf property make sense? File->Properties Landscape/Portrait that the user can change. View->Rotate is a lot more direct but it also clutter the UI with something that seem a workaround for broken PDFs. It would help to know how common is the case... I cant remember to have found pdfs like that, but I could very well be wrong.
IMHO they're pretty common - I run into them all the time, which is why I complained. My usage pattern is downloading PDFs for courses I take in my university. About a third of show up sideways.
Ivan, could you provide links to a couple of them please?
Hmm the only example I can find right now is some stuff on a secure site scanned out of a book. I know I've seen a lot more of those in the past, but they're all gone now. Maybe this isn't as frequent as I think, but if it's easy to implement, I feel like it should definitely be included. xpdf can do it, and so could ggv/gpdf/whatever was default on Fedora before. Anyway, I can't provide a link, since the site is protected.
Created attachment 38404 [details] Upside-down ps document Here's an example of a document that shows up upside down.
I have attached a PS document that shows up upside down. GGV does this as well, but has a menu item to change the orientation in the View menu. I dont think this can be done automatically for PS documents. Not sure about PDF.
I'm sure you've heard this before. ;-) Just because those other applications before had feature X doesn't mean we're going to implement it here. See rationale: http://ometer.com/features.html There isn't a feature that's easy to implement or free to just have, they all have costs. This is why we want to get the simplest and most correct feature implemented so we don't have to implement many rotation features to do the job of one. Marco, I wanted to leave File->Properties open for something like bug 169583 Is there a way you can think of where we can do both? Perhaps we can do File->Layout -> Landscape/Portrait/Flip? It seems excessive to have the Layout menu item just for this, I'd like to see it a part of the properties item somehow.
I talked with Martin about this... unfortunately the Layout state is per-page not per-document. I guess there is no other way than doing something in the view menu :(
Ok. I think I've come full circle now. :-) Here's what I think we should do. Place the Rotate items in the Edit menu. There's no standard HIG placement for this anyway, but that doesn't matter since I have good reasoning for doing this. In our blue sky future we'd like to remember the rotation of the document and redo that same rotation when you reopen the document by saving it as meta-data of some kind. Even if this is a per page thing we'd like to save it so the user doesn't have to do the same rotation everytime they open the document. Now since we're effectively editing the document (even if we're not actually modifying the file, since it doesn't really matter to the person) we can drop the rotation items in the Edit menu. This evens out our View and Edit menu sizes and give better relation to what you're actually doing. Plus EOG has been doing this for years so it's kind of a GNOME defacto standard anyway. So something like Edit -> Landscape/Portrait/Flip
>Just because those other applications >before had feature X doesn't mean we're going to implement it here. I wasnt saying you should implement all features of program X. i was only trying to say that rotating is basic functionality, so should be implemented someway. i really dont care how, its your design... >so we don't have to implement >many rotation features to do the job of one. by adding that line, you clearly state that you didnt get my point. i never said anything about adding loads of features to do one thing. i assume the error would be on my part, i probably didnt word it very well. oh btw, i dont know if you are aware yet, but Redhat removed GPDF and GGV from Fedora Core 4, to be replaced with Evince. Users dont want to lose functionality, so if the program lacks key features, that would make people view it as inferior. but oh well, some people rather flame than appreciate people that try to help.
Created attachment 39146 [details] rotated pdf Another example file if you need it. This one is rotated 90 degrees.
I'm going to implement this when I get a bit of time.
This is going to be a bit difficult to implement with current architecture :/
*** Bug 304077 has been marked as a duplicate of this bug. ***
*** Bug 305570 has been marked as a duplicate of this bug. ***
http://www.ida.liu.se/~TDDC18/handouts/ Here's a whole bunch of them. And for kicks you can select just about any other course there and you will find the same problem. Crappy handling from staroffice/openoffice/powerpoint but hey, too many other PDF viewers support rotation so the problem just cannot be ignored away.
I think we're all set on adding the menu items to the interface, however we're blocking on the coding right now. This is what I'm assuming for now so this is going off my radar.
Fixed in cvs
Maybe this is not perfect yet... I'm not 100% sure I'm correctly calculating the rotation... Please file separate bugs if you find issues.