(*** This bug was imported into bugs.kde.org ***) Package: kghostview Version: 0.12-beta1 (using KDE 2.2.0 beta1) Severity: wishlist Installed from: compiled sources Compiler: gcc version 2.95.2 19991024 (release) OS: Linux (i686) release 2.2.19 OS/Compiler notes: Hi! this is a real missing function cu ferdinand (Submitted via bugs.kde.org) (Called from KBugReport dialog)
*** Bug 64045 has been marked as a duplicate of this bug. ***
Bug #72347 is related.
This bug should be solveable now that the xpdf backend is used. no?
More than 1700 votes? Why don't use kpdf > 0.4 for viewing PDF-documents? It support searching in PDFs among other features.
Good point and I've to add it works just fantastic. Damn good work done on kpdf! So, is there any reason this wish is still marked open?
the question here is comment #4 might be right. this bugs subject could be a little bit missleading. subject line talkes about pdf, wheras product is kghostview (mostly for ps files). my kghostview (0.20) can open some pdf files, but not all. where as kdpf (0.32) can open all pdf files but no ps files. if the reporter really wants khostview to support searches in pdf files then i think this bug should be open. but if he can live with one application for ps files and one for pdf, then i also vote for closing. by the way, is it at all possible to add a search function in kghostview to search in ps files?
well I am fine with kpdf for pdf and kghostview for ps files. IMHO only a very limited number of users will search in ps files. so I vote for closing this one
This might be off topic, but on my System (SuSE 9.1 using the supplementary KDE 3.3 update), kpdf isn't installed as default. When I click on pdf files, they are automatically opened with kghostview. I had to install the package "kdegraphics3-pdf" manually, but still kghostview was the default application for pdf files. So I had to change the file associations of Konqueror manually to chose kpdf as default application and kpdfpart as default kpart for viewing pdf files. If I wasn't notified of the previous four comments to this bug, I wouldn't even know that there is an application called Kpdf. So, in my opinion, if Kpdf is regarded as the default application for pdf-files, it should be distributed with the default KDE packages and it should be associated with pdf-files. Perhaps this should be discussed in a new bug report. Or is this only a problem with SuSE?
> ------- Additional Comments From gassauer kde org 2005-01-22 09:59 ------- > well I am fine with kpdf for pdf and kghostview for ps files. > IMHO only a very limited number of users will search in ps files. > > so I vote for closing this one IMHO kghostview and kdvi should be merged into kpdf (only the good, usable code) and go out KDE: * less duplicate code * one application that can open all these files
By saying that "kghostview and kdvi should be merged into kpdf" you somehow seem to imply that "kghostview and kdvi" are less important. I hope the developers of these components don't see it like this and feel pissed off because of that ;-) I would have said "let's merge kghostview, kdvi and kpdf" into one application. Basically it's the same idea and I think this would really be much more transparent for the end user.
Comment 7 says "only a very limited number of users will search in ps files." This does not match my experience. PostScript is the most common format for distribution of TeX-generated scientific content, and a search function is very valuable. Is there any reasonw why PostScript should be less searchable than PDF?
> ------- Additional Comments From SPW vo lu 2005-01-24 16:23 ------- > By saying that "kghostview and kdvi should be merged into kpdf" you somehow > seem to imply that "kghostview and kdvi" are less important. I hope the > developers of these components don't see it like this and feel pissed off > because of that ;-) I would have said "let's merge kghostview, kdvi and > kpdf" into one application. Basically it's the same idea and I think this > would really be much more transparent for the end user. Yes, that's exactly what I mean: take the best things from all these three applications and scramble them into an open source prize winner application :-)
Considering all three apps (KGhostView, KPDF and KDVI) provide KParts, the work is done already. The app you're looking for is Konqueror. Click one such file (.ps, .pdf, .dvi) and it'll be shown inside Konqueror. What should be done, IMO, is harmonise the UIs wherever possible.
I'm for merging, lets call it KReader. IMHO is the next logical step. This way pdf, ps, dvi and other documents (insert your favorite ebook format) could be added as backends, while kreader would implement the logic abnd presentation. This way, if a backend supports it we get searching highlighting copying etc, together with readahed and thumbnails and... go for it!
I second #14!
Well, how about we start a revolution right here. Let's call it something without a K, for a change. Or is that a little too revolutionary?
To http://bugs.kde.org/show_bug.cgi?id=28898#c11 Just want to mention, that on (my) windows XP professional there is no ps-reader installed. Need to install either gsview for windows or others... that's why I still think only a very specialized group (of windows users) will ever encounter ps files. but I agreee with http://bugs.kde.org/show_bug.cgi?id=28898#c13
No, let's stay with the "K", call it "Akrobat Reader" and get sued by Adobe! ;-)
Karobat Reader lol
> Just want to mention, that on (my) windows XP professional there is no ps-reader installed. There isn't even a PDF-Reader included in a default Windows installation. But I think we don't have to talk about this... ;-) PS and DVI are important for everyone who deals with LaTex. What could be done is make the viewer extensible: In a default KDE environment, it can only display PDF and perhaps PS. But when you install some LaTex related KDE-software (eg. kile), they bring dependencies for a package that extends the viewer so that it can also display DVI. I think this would really be a killer application.
even though the subject of the bug suggests something else then the discussion. i think it's a great idea to have something like "Kreader" that can support all the filetypes named above. (adding more votes). but don't forget the search functionality.
Why God? Why? Why the K? Allah, whoever? Kod? Kallah?
Perhaps we should open a new wishlist item "Merge KGhostView, Kpdf and KViewShell to one extensible reader".
>Perhaps we should open a new wishlist item "Merge KGhostView, Kpdf and KViewShell to one extensible reader". Sounds sensible. Someone do it, and post a link when done over here *hey, I can be lazy too, :-)*
I did so: http://bugs.kde.org/show_bug.cgi?id=97949
I use ps files offen too. Granted almost always for school papers. Another cool feature would be overlays for pdfs, (pdf-forms) something like flpsed http://www.ecademix.com/JohannesHofmann.
Hey folks! You really want to go to Bug 91481 and vote for it. It's similar to this bug, but has more "ideas" ;-)
stefan, i like your idea resp. the idea of bug 91481
Is strongly needed SEARCH, and better with ctrl+F. regards
Kpdf already do it, why have you to use kghostview for opening pdf files? (or with okular in the upcoming KDE4) ? This bug should be closed. Hi! :-)
works in 3.5.7
No, the problem isn't pdf but ps files. kpdf can't open postscript files and kghostview can't search in them.
function missing for ps files so I reopen the bug
My Kpdf version (0.5.10) is capable of searching in ps files. I just tested it. IMO this bug should be closed.
Regarding the new Okular which replaced KPDF in KDE4: It seems as if Okular is able to search in PDF files, but NOT in PS files :( On another computer, PS files open up with gv, but this software feels like the early nineties, and seems to have no search command at all. So I think this bug is still valid/relevant until Okular learns to search in PS files, just like in PDF files. And KPDF seems to be unavailable for KDE4, so you basically have to use Okular or kghostview. P.S.: The version that I currently use: user@user-desktop:~$ okular --version Qt: 4.4.3 KDE: 4.1.4 (KDE 4.1.4) Okular: 0.7.4 P.S.: Okular seems to use libspectre as the PS backend, and as far as I understand it, this library is not yet able to extract any text or search the text of PS files. Source: http://okular.kde.org/formats.php
Moved to Okular.
Don't hold your breath in this one, the postscript format wasn't though for search and is basically "not searchable"
As said, can't be done. I'll be happy if someone proves me wrong. Please if you have information on how to search text inside a postscript document reopen this bug. Thanks for caring about KDE :-)
(In reply to comment #39) > As said, can't be done. I'll be happy if someone proves me wrong. > > Please if you have information on how to search text inside a postscript > document reopen this bug. > > Thanks for caring about KDE :-) GSView (available as a source code, Aladdin Free Public License) http://pages.cs.wisc.edu/~ghost/gsview/get49.htm can search text in DSC PS files well enough (even for non-Latin1 TeX locales, tested).
well, DSC comments are just random stuff and not part of the standard as far as i can tell, this smellls to me like "i own both the creator and the reader of the ps so i'll add my non standard stuff to it for text". No?
(In reply to comment #41) > well, DSC comments are just random stuff and not part of the standard as far > as i can tell, this smellls to me like "i own both the creator and the > reader of the ps so i'll add my non standard stuff to it for text". > > No? Ok. I cannot say in general. All 15 PS papers in my archive (from 1995 to 2007) are DSC documents (and I do not have the TeX source for them). All tested PS documents from arxiv.org are DSC documents (although PDF and TeX source are available). PRN files for PostScript (e.g. HP LaserJet 4550 PS) printers are not DSC compatible.
Created attachment 81175 [details] Example of TeX-created DSC PS file Just try to find the word "nonsense".
Reopening, more appropriate title.
Any news since more than one year?
There's noone working on this to my knowledge.