Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to delete page(s) ? #130

Closed
Nokia808 opened this issue Aug 5, 2017 · 6 comments
Closed

How to delete page(s) ? #130

Nokia808 opened this issue Aug 5, 2017 · 6 comments

Comments

@Nokia808
Copy link

Nokia808 commented Aug 5, 2017

Hi. In manual there is a statement about "Delete pages" & referred to "examples directory", but I do not found how this ?

How can I delete a specific page or pages from a PDF ?

@jberkenbilt
Copy link
Contributor

The examples directory is in the qpdf source distribution. You look at the examples directory here in github, or you can download the source distribution from sourceforge. You can delete pages using qpdf's --pages option by just skipping the pages you want to delete. For example, to delete page 5, you could run qpdf infile.pdf outfile.pdf --pages infile.pdf 1-4,6-z --.

@Nokia808
Copy link
Author

Thank you very very much !!! You remove great suffer from me by this command !! It is not only allow me to delete single page ! It allow me to select what I wish !! Like this:

qpdf example-1.pdf new.pdf --pages example-1.pdf 2-5,11,89-111 --

I was, before this command, enforced to use Windows application for this option. Now you reduce my need for Windows significantly !

@jberkenbilt
Copy link
Contributor

That's great! Reducing need to use Windows is a worthwhile goal. :-)

@Nokia808
Copy link
Author

Dear developer. We need to KILL any need to use Windows OS at all ! To achieve this we need progression in certain directions (not many but in fact some). One of these direction is PDF edit.

Currently we have 2 great programs:

  1. your program (QPDF)

  2. jPDFTweak:
    https://sourceforge.net/projects/jpdftweak/

Regarding jPDFTweak it has big problem: has no preview (build in viewer). I asked it's developer & he refuse to add this feature because he has no time & it is very hard for him.
Also, it's approach to delete pages / add blank pages is unusual (user need to select file more than one time).

Your program is very strong application. It need to few steps to become a base for advanced PDF editor that will certainly stimulate many developer to create a GUI for it.

I respect your desire not to create GUI.

But to make your program a strong base for future PDF editor, you need to change aim of your program: currently you are not interested in change contents of PDF, but only structure. But we need few steps (most of them deal with contents).

Let we see what we need to form such advanced base for future PDF editor (please notice that I do not include by editor the annotation tools because we have already excellent PDF annotator called Okular):

  • we need option to edit "document info" (author, producer, creator, date of creation, date of last modification)

  • we need option to delete ALL "document info" listed above. I already asked for this feature but no comment from you on it.

  • we need option to add/delete/edit outlines for PDF. This will be vital when some one starting to develop a GUI for QPDF. You can delay adding this feature.

  • we need option to divide page(s) of PDF vertically from midpoint. I asked for this feature but you refused it. This feature important to deal with scanned PDF that prepared by scan every 2 faced pages together.

  • we need option to "Deskew", "Descreen", "Remove background", "enhance text sharpness". I asked for these but you disagree.

  • we need option to add new blank page(s)

Only the above 6 points, then your program will be a very strong base for future PDF editor that solve PDF problem on LInux

You are free to refuse these. But only these points (plus what you already accept to add: page rotation, split to individual pages) & you will shut PDF problem on Linux by a gun shot (the mercy gun shot).

Best.

@jberkenbilt
Copy link
Contributor

Well, basically, I'm an individual person with a full-time job, young children, and other responsibilities. I have very limited time to work on qpdf. I have to keep the scope narrow and commit to things I can realistically achieve. Even adding page rotation is a bit of a stretch because it is right on the border between content and structure, but rotating pages is literally just adding a /Rotate key to the page dictionary along with a little extra work to handle inherited page attributes. It's the kind of thing that the QPDF library is really good at, and rotating pages is so close to being structural that I'm willing to stretch into that a bit.

Options to deskew, descreen, etc., are definitely out of scope for qpdf. To do this well, you need a full renderer and lots of image manipulation logic. There is no way I will ever include that in qpdf itself. However, it would be possible for someone to write an image extractor using qpdf and to pass those images off to something else and then replace them with qpdf. Virtually all of the other things you suggest could be in another application, and if that application wanted to use qpdf to help it with the PDF parsing and updating part of its work, that would be a good use of the qpdf library.

qpdf was not intended to be a PDF editor. It could be used to help write a PDF editor, but the resulting editor would be a program that links with the qpdf library, not part of qpdf itself.

I think there are a number of programs in Linux that can work with PDFs. I'm not an expert on this topic, actually, but I think you can google it or ask on stackoverflow.

Remember that the qpdf command-line tool is just a fancy program that uses the qpdf library under the covers. It has a little bit of its own logic for stuff like page splitting and, to a lesser extent, rotation, but mostly it's just making calls to the library. Most of the hard work is in the C++ library. The examples directory has a bunch of small examples of how to do many different kinds of things that would be beyond stuff I would want in the library itself. There is stuff that manipulates metadata and outlines.

Sorry if there's an issue you created that I haven't responded to. I went through and did triage on issues that piled up over the last few years when I've been ignoring qpdf because of a family issue that required a lot of my attention. I marked some of the issues as things I thought I could do in the near term. There are others that I haven't addressed.

I do appreciate your enthusiasm, but my drawing boundaries around what functionality belongs in qpdf is as much for practical reasons as for philosophical ones. I'm putting a big push this summer to get caught up in fixing bugs and handling relatively simple feature requests, but qpdf is basically in maintenance mode at this point. I hope I can solve some weaknesses around outlines, threads, thumbnails, and other document-level structures in splitting and merging, and it would be nice to handle embedded attachments, signed documents, and a few other structural items that qpdf currently doesn't do. I also have a standing request to implement user-pluggable stream filters, implementing some existing stream filters more fully, adding more inspection options particularly around linearization data, and handling incremental updates. Many of these things are listed in the TODO file in the source tree. Even if I just do these things, I would stay busy for weeks. My plan is to keep chipping away at this a little a time.

There are two google summer of code projects this summer that are involved with qpdf. One will add PCLm support to qpdf to help it support driverless printing. The other is involved with form flattening. It is not yet clear whether that functionality will be added to qpdf or will be a separate program that uses qpdf. PCLm requires changes to qpdf, while form flattening can probably be done externally without any modifications to the core library. I'm excited to have a few other people have their hands in the code. While I am in good health and interested in continuing to enhance qpdf over time, any solid open source project has to have a life beyond its original author and maintainer. Maybe over time, other people will become committers. For now though, I remain the single arbiter of what goes into qpdf. This is more out of necessity than intent, though I do hold the code to a very high standard and would want to ensure any future maintainers could keep that standard high.

Hopefully this clarifies things.

@Nokia808
Copy link
Author

Please accept my apologization. I pressed on you too much ! You took from your time to dictate all this long replay !

Take your ease in development of QPDF.

One point: really your great program not so famous !! When I post notification about it in Fedora forum, many users were not know about it, in-spit of it's very strong powers !! They know about pdftik (which is not available on Fedora repositories or RPMFusion repositories). This may explain why no other developer(s) assist you in it's development.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants