I did not see this feature, though it is documented at home page of this GitHub pdfslicer that this application able to extract pages ! This functionality is already well supported by QPDF backend.

Can you clarify what you mean by this? Do you want to select some pages and then save each page individually to a different file?

@junrrein Yes ! Yes, this is exactly what I want: I want to select some pages and then save each page individually to a different file.

Keeping with the philosophy of "everything you see on the screen is what's going to get saved", I have an idea for the UI of this feature:

The user removes all of the pages they don't want to save.
The user hits a Save each page to a separate file... button.

This new button would be located next to the normal Save button.

@junrrein Hi. I have better, more powerful & still easy: I suggest to use same design that already you used for "delete" & put it beside "delete" options (at their right side) at lower border of program.

In delete option you set icon that when user click on it it will remove selected pages. Beside it "more page removing operations" which including "remove unselected", "remove previous pages", "remove next pages" & [you added "select all evens pages" , "select all odds pages" that I do not where their positions exactly"] ..... So, I suggest that extract option will be similar: 1st icon will extract selected pages into individual pages while 2nd icon will be for "more pages extract operations" that will include "extract unselected", "extract previous pages", "extract next pages", .......

I wish that I was clear in my description .......

May I suggest an idea for the UI?

open a pdf in pdfslicer and select at least one page
a "extract"-label-button in the bottom-bar gets activated
if the user click on that button, a copy of all the selected pages are loaded in a new pdfslicer session
the user now have the original session in which the pages are still selected AND a new pdfslicer session with those extracted pages. The title for the latter might be "*unsaved document" and there the user can do exactly what he can do in any other pdfslicer session, even extracting other pages.

@Nokia808

I don't like that proposal because it changes the meaning of the bottom bar. Right now the bottom bar includes all of the actions that modify the current document in some way. Having a "Save" action here doesn't make sense from my viewpoint.

Having "Extract unselected", "Extract previous" and "Extract next" actions is stuff that could be accomplished by just using the approach I delineated earlier: first removing from view any pages you don't want from the result, and then using an "Extract" action.

I'm sorry, but I don't think I'll be convinced otherwise.

@amivaleo

Before I comment further on this, are you aware this issue is about saving different pages to different files? Is this idea of yours something unrelated?

Before I comment further on this, are you aware this issue is about saving different pages to different files? Is this idea of yours something unrelated?

😂😂😂

I completely misunderstood this! 😂

Apologies... 😅

@amivaleo

No problem! It seemed like you were confused but I wanted to be sure lol.

@junrrein Hi. Sorry for delay in response since I was in travel ..... Dear @junrrein as long as you already added options to select odds / select evens pages, & taking both of your philosophy to keep all thing simple + usual approach by most PDF editor, I would like to suggest on you something unified for both:

1) user 1st selected which page she/he need to extract, 2) click on "extract" button to extract - in block - all those selected by 1st step into individual pdf files for each.

Removing all pages that not liked to extracted from view 1st (as you suggested) is unusual (one working in inverse way) ! The usual is select what user need to extract 1st then extract them. This keep every thing simple as you like & keep usual way as well ....

I've coded this feature, and it's ready for a design review. @amivaleo and @Vanadiae, I would welcome any and all comments. Sorry for the wall of text/screenshots!

Here is an installable Flatpak bundle (English only) you can use to test this feature. You need to decompress the file, and then use the command flatpak install pdfslicer-savesplit.flatpak to install it. I recommend to uninstall any existing Slicer version before installing this one. Remember to also uninstall this test version when you no longer need it, since it may interfere with Slicer being upgraded later.

I've added a new action, "Save each page to a different file", that can be found under a menu in a button next to the "Save As" button. It pops up the following dialog:

Captura de pantalla de 2020-04-28 23-24-11

As you can see, you can select the destination folder for the created files, and the base name that's going to be used as the beginning of the file names. The list shows how the file names will look when saving. Files get numbered from 1 upwards, with no option for custom numbering schemes.

By default, the destination folder is set to the folder of the last opened file (the same case as the "Save As" feature), and the basename is set to the file name of the first opened file in the document (using "Open").

The "Preserve metadata, annotations and form fields" needs to be an option because, when active, saving can range from being slow to being really slow, depending on the size and complexity of the source files.

When any of the target files already exist, a warning pops out, and the offending file(s) get highlighted in the list:

Captura de pantalla de 2020-04-28 23-31-19

Some characters are forbidden in the base name, since they can cause problems if used. Notably on Windows, where they are really not allowed at all. While we don't currently support Windows, I don't want to make that harder to do in the future.
When one of them is present, a warning also pops out:

Captura de pantalla de 2020-04-28 23-34-11

I have noticed the mistake in the label ("caracters"), and that's already fixed in a new commit.

While saving, the same notification is shown as when using "Save As".

Notes:

The main inspiration for my design was Nautilus' batch rename tool, but I deviated on one key point. In Nautilus, when invalid file names would be the result of the rename action (because of an invalid character, currently only "/", or because any of the target files already exist) a panel gets revealed from the bottom of the window to indicate the problem(s):

Captura de pantalla de 2020-04-29 01-28-09

I did not like that approach because I don't think that panel gives a clear visual signal that something isn't right. I think a colored hint is essential in this case. They do color the file names in the list that are causing problems, and that I did copy for Slicer.

All of the "yellowed" elements are colored using custom CSS. I know this should be avoided when possible, but I did it for the following reasons:

Gtk doesn't offer any class that can be used to apply a "warning" state to a widget. At least I didn't find one (and I looked for it).
For the file name list, that's the same thing Nautilus is already doing. If it's good enough for Nautilus, then it's good enough for me (sorry if this sounds like a sub-par attitude :sweat_smile:).
For the "warning" labels, I did it because I really think these items need to be colored in order to grab attention. The only colored UI items that Gtk provides and that the Gnome HIG recommends are Info bars, and I don't think they fit this use case well.

These custom items are still legible in a dark theme, but they look exactly the same.

I tested using colors defined globally by themes (the ones listed here), with the following results:

Using @warning_color and @theme_text_color:

This looks like ass. After reading some docs about the Gtk CSS properties, it seems the intended usage of @warning_color is pretty narrow, and not for our usecase:

-gtk-icon-palette defines a color palette for recoloring symbolic icons. The recognized names for colors in symbolic icons are error, warning and success. The default palette maps these three names to symbolic colors with the names @error_color, @warning_color and @success_color respectively.
Using @theme_selected_bg_color and @theme_selected_fg_color:

This looks ok, but I'm not sure about repurposing those colors for this usecase.

I'm also looking feedback on the labels used.

Are "Save each page to a different file", "Base name" and "Target name" ok terms? For example, I'm not sure "Target name" is easy to translate (at least not to Spanish, the translation I'm maintaining).
Are the colons after each label necessary? Like in "Destination folder:".

And of course, please leave feedback on anything else that comes to mind.

Oh gosh... I really have so many bad things to say about this... 😅

So:

1 The color of the yellow box that tells the user not to use some characters is hardcoded. That's bad. Really really nasty. 😄

Do you know OMGubuntu? I happened to read about the fact that devs complain that user themes make their apps look bad. My answer is: if your application do not use hard-coded pieces of GUI, any bad look that arises with a custom theme is automatically an issue of that theme. That means, that you could close EVERY single issue about user themes even without reading it, because you know you did things correctly. But if you hard-code a yellow box and then I'm visually impaired and need to use a high-contrast theme, that very piece of gui could be a pain to me.

Do not hard-code anything, please. If you deeply believe that some feature is missing in gnome GUI library, tell me and we complain together in some IRC chat. I'm VEEEERY good at complaining, I swear! 😄

2 That very same box could be removed, and the same info could be given IF the user type a forbidden character in the file name field. For example: the font color might turn to red and, the blue save button on the headerbar might become insensitive and a warning sign (⚠) might appear at the end of the file name field. If the user click on that ⚠, a message could be shown in which you tell the user about the forbidden character.

3 There's something that tells me that the file name field should go before the destination folder field. 🤔 It's like: first you want to know the most important think ("what") and there all the rest ("where").

4 I'm really not convinced about the bottom half of that very same window. I can't tell why, maybe I'd add a column for the page numbering. Or maybe it's the header: that bold "Target files (to be created)".

5 "I did not like that approach because I don't think that panel gives a clear visual signal that something isn't right. I think a colored hint is essential in this case."

I agree on this: some more highlight is needed. But... Not the way you did it (see 1 & 2). 😛

6 "If it's good enough for Nautilus, then it's good enough for me"

Not really. And I'm gonna tell you why, which is basically the very reason for which I consider this a bad UI (sorry):

In every software that I've used in my life, the Save action is like the last thing you (could) do to your file before quitting. When you save something, the application records what you've done till that very moment. While saving, you are not supposed to edit the file anymore, you only have to choose a file name and that's it.

What you did here is some sort of a mix between an action ("exploding" the file into several files) and saving. I do believe that, while it is clear that this "mix" can't be split into two separate actions (since I don't see how you can split the pdf into several files without saving them), the action that takes presidence is not "saving".

What I mean is that this action should not stay close to the save button on the headerbar. Because you're not really "saving" something, you're doing something to the file AND saving the result.

Also, I see this action more related to the pages than to the file as a whole. I mean: you have many sheets altogether and you put each of them into a separate place. I rememebr that you wanted to put in the headerbar the actions related to file as a whole, and the bottom bar as a container for actions that deals with the pages.

In my opinion, I'd suggest to reduce the code and the GUI for this action, by creating one single button on the bottom bar that deals with it.

I'm thinking about an "explode" button in the bottom panel, either text based (better I think) or icon-based (uhm...). Let's go deeper into this:

this button is inactive if no page is selected.
when some page is selected, it becomes active 1 - if clicked, the selected pages are extracted and saved in the very same folder path of the original pdf 2 - if the original pdf is called "ORIGINAL.pdf", the extracted pages will be saved as "ORIGINAL1.pdf", "ORIGINAL3.pdf", "ORIGINAL12.pdf", "ORIGINAL47.pdf", etc, where the number at the end is the original page number (it can also be "ORIGINAL_page_1.pdf" or "ORIGINAL_p1.pdf" or whatever, this is not relevant now) 3 - an in-app notification appears in slicer telling the user that "The selected pages have been extracted and saved in the folder path of the original file(s)".
if more pdf where loaded in slicer, the same rationale applies, with one clarification. Let's say that FIRST.pdf and SECOND.pdf were both loaded, then the user selects a few pages and click "explode" button -> those pages are saved as "FIRST3.pdf", "FIRST4.pdf", "SECOND3.pdf", "SECOND11.pdf", etc, where the number is the page numbering on the respective original files. -> the very same in-app notification appears, and this means that the single pages are saved in the very same folder of their respective original files. So if FIRST.pdf is saved in home folder and SECOND.pdf is saved in Music folder, FIRST3.pdf will be saved in home, while SECOND11.pdf will be saved in Music.

Other reasons for which I do believe that this is a better solution, apart than being easier to code (I guess, since no much GUI is needed):

you can bypass the need of checking forbidden characters since the original pdf file already has a valid file name, and you're only adding a number next to it
"Explode" is exactly the term which is used to refer to this very same feature (google it!) so you might exploit this kind of "expected behaviour"
the gui used in nautilus is actually a very small application on its own, while you would use it as an alternative save-dialog. Google for "easytag" in linux, you'll find a metadata editor for songs, which is basically like that nautilus-rename app brought to a much higher level. That is to say that the tiny nautilus-rename routine is actually an application that could be split from nautilus and live on its own
you would avoid the list of names which I... I don't know, there's something really wrong in it as I said in 4 😂. It's just an awkward way of telling the user the name of a bunch of files that he is going to create, which is something not really needed since it is no more that the file name chosen by the user + a progressive digit.
it would allow to let the user decide in a very simple way which page he is going to extract. He wants to extract all of them? Well "Select All" -> "Explode", without any additional window popping up.
I believe this button is easier to illustrate in a guided tour (or a system of "hints") if you're going to code that as discussed in https://github.com/junrrein/pdfslicer/issues/179 because it requires less GUI and less user interaction
less quotes that need localization
you would avoid to replicate what nautilus does: let nautilus deal with renaming files
no hard-coded GUI 😱

Hi there again @amivaleo. Thanks for your feedback! There's things that I agree with, and things that I don't, so let's get going with it.

1 The color of the yellow box that tells the user not to use some characters is hardcoded. That's bad. Really really nasty. :smile:

Do you know OMGubuntu? I happened to read about the fact that devs complain that user themes make their apps look bad. My answer is: if your application do not use hard-coded pieces of GUI, any bad look that arises with a custom theme is automatically an issue of that theme. That means, that you could close EVERY single issue about user themes even without reading it, because you know you did things correctly.

I know about that article, and the initiative behind it. I tend to agree with the points they make, however...

But if you hard-code a yellow box and then I'm visually impaired and need to use a high-contrast theme, that very piece of gui could be a pain to me.

This is IMO different issue, and a critical one. This alone convinces me not to hardcode a color, ever, unless I'm developing a painting program or something lol.

Do not hard-code anything, please. If you deeply believe that some feature is missing in gnome GUI library, tell me and we complain together in some IRC chat. I'm VEEEERY good at complaining, I swear! :smile:

I do believe you're very good at complaining :stuck_out_tongue:. But there are people already talking about a solution to the general problem of coloring in Gtk apps. Here's a blog post about it, and here are some comments about it (but take those as you will).

2 That very same box could be removed, and the same info could be given IF the user type a forbidden character in the file name field. For example: the font color might turn to red and, the blue save button on the headerbar might become insensitive and a warning sign (:warning:) might appear at the end of the file name field. If the user click on that :warning:, a message could be shown in which you tell the user about the forbidden character.

Did you just suggest to hard-code the font color to red on errors? :P The @error_color defined by themes isn't suitable for text (or really anything except symbolic icons).
I like the idea of the warning sign, but I don't like the idea of the info being hidden until the user clicks the sign.
I would modify the solution I offered by still showing the warning label (without color) plus the warning sign in the textbox.

3 There's something that tells me that the file name field should go before the destination folder field. :thinking: It's like: first you want to know the most important think ("what") and there all the rest ("where").

It's the same to me, so I wouldn't mind moving it up.

4 I'm really not convinced about the bottom half of that very same window. I can't tell why, maybe I'd add a column for the page numbering. Or maybe it's the header: that bold "Target files (to be created)".

I think you understand the purpose of that list, but I'll be explicit just in case: I want to tell the user that generated files will be numbered from 1 onwards, without a label saying "Generated files will be numbered from 1 onwards". Would using that label actually be a better solution? Edit: Or would you argue that this needs no explanation? About the implemented file list, I don't like the header either, but it's the best I could do without resorting to a custom gradient for the background, to make it look nicer (and not make the bold font necessary). But maybe I could build a background gradient using theme-declared colors.

6 "If it's good enough for Nautilus, then it's good enough for me"

Not really. And I'm gonna tell you why, which is basically the very reason for which I consider this a bad UI (sorry):

I'm going to nitpick a bit here. When I made that comment, I was talking exlusively about hard-coding the color of a highlighted list item, not about the general UI.

With that being said, I will talk about your alternative proposal in another comment. It will take me another while, since I want to research how other PDF editors implement this feature. You don't need to respond before that.

I've coded this feature, and it's ready for a design review. @amivaleo and @Vanadiae, I would welcome any and all comments. Sorry for the wall of text/screenshots!

Found some time to look on this :smiley_cat:

Nautilus does have a nice way of informing people on this. You can see it when right clicking on an item and "Rename" like this (note this is french, I didn't bother launching it with english) :

Capture d’écran de 2020-05-09 17-56-50

As you can see, I inserted a slash in the name and this is forbidden. So Nautilus don't let me click on the button and show a line of text just underneath to explain why you can't procede. I think this is a great approach.

Do you know OMGubuntu? I happened to read about the fact that devs complain that user themes make their apps look bad. My answer is: if your application do not use hard-coded pieces of GUI, any bad look that arises with a custom theme is automatically an issue of that theme. That means, that you could close EVERY single issue about user themes even without reading it, because you know you did things correctly. But if you hard-code a yellow box and then I'm visually impaired and need to use a high-contrast theme, that very piece of gui could be a pain to me. @amivaleo

Regarding this point especially. You are talking about themes but what you don't seems to realize is that there isn't any theming API, just CSS on GTK widgets. See this blog post for a in-depth explanation. As @junrrein pointed out, there is some ongoing discussion on a coloring API that could help with that point on emphasizing the culprit files.

Still, I agree with you that it isn't terrible to hard-code colors.

So this won't be it I should think :

I did not like that approach because I don't think that panel gives a clear visual signal that something isn't right.

Answered at the top of my message for reference (small line of text just underneath).

For the "warning" labels, I did it because I really think these items need to be colored in order to grab attention. The only colored UI items that Gtk provides and that the Gnome HIG recommends are Info bars, and I don't think they fit this use case well.

Nor do I find it a good idea.

I tested using colors defined globally by themes (the ones listed here), with the following results: [...]

Using @theme_selected_bg_color and @theme_selected_fg_color: This looks ok, but I'm not sure about repurposing those colors for this usecase.

I don't it's really repurposing, it's really to "select/emphasize" the items that are concerned by the small message line.

I'm also looking feedback on the labels used. "Save each page to a different file"

Not convinced. "Save pages separately" seems better and translates well to other langages in my opinion.

"Base name"

Seems a bit "technical". This is the kind of word that you would use when programming but sounds bad elsewhere and people might not understand the purpose of the field.

"Target name"

Same. Without your "what will be created", most people won't understand. I think it should just be a noun that means "what will be created" like... why even bother about this after all. I don't even think we should put this, it heavies the UI and isn't even needed because the use-case is quite clear : why would these names be there other than to indicate the files export name.

Are the colons after each label necessary? Like in "Destination folder:".

I don't think we need those. for example in the HIG

And of course, please leave feedback on anything else that comes to mind.

I'm not convinced of the naming of "Preserve metadata, annotations and fields" and if it's even appropriate to put it in this dialog.

If the export with the previous item ticked, and if it's reallyyyyy long, a progress bar could be placed in the UI or a progress spinner.

That's a fairly big piece of text :smiley_cat: .

You are talking about themes but what you don't seems to realize is that there isn't any theming API, just CSS on GTK widgets

I'm aware of that. It's just that I don't like the underlying idea that no one should be allowed to play with CSS on their machine. And if I get something broken because I did some bad thing in the stylesheet, that's my business. That's the direction I'd like to see. This, anyway, is another topic. I don't want to talk about it, at least not in this thread.

The need to hard-code colors or some custom widget proves that there's something broken somewhere, I believe. Either it's dev's fault or gtk's fault. If you want to make something completely different, which doesn't follow the HIGs, I'm fine. Otherwise, just stick to them.

As Julian requested: I'll wait for the second part of his reply before replying back.

You are talking about themes but what you don't seems to realize is that there isn't any theming API, just CSS on GTK widgets

I'm aware of that. It's just that I don't like the underlying idea that no one should be allowed to play with CSS on their machine. And if I get something broken because I did some bad thing in the stylesheet, that's my business. That's the direction I'd like to see.

If we are talking about the same website (https://stopthemingmy.app), then it's already covered :

This is aimed at distributions breaking apps by default, not tinkerers playing with their own setup.

Because thinkerers can thinker, that is not the point, but people with a distribution that breaks css will complain.

But I think as you said that it is an other topic so I'll stop talking about this here further on.

junrrein / pdfslicer

[Feature request] Extract selected page(s) to individual page(s) #81

Notes: