Support page extension (negative crop)

[jeromerobert]

When pdfarranger do a crop operation it changes the MediaBox of the page. Yet, there are many other boxes in a PDF, particularly the CropBox which is what PDF viewers actually for display. CropBox is always smaller or same size as MediaBox. See https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf page 77.

Currently pdfarranger cannot extends pages. Negative values are not supported in the crop dialog, but this is something easy to fix. This is not enough because to extend a page we would need to change both MediaBox and CropBox. I think we can't find a good logic which hide that complicity to the user and work with all kind of PDF.

I think it would be nice that pdfarranger support edition of all boxes (MediaBox, CropBox, BleedBox, ...) as they are in the PDF file. We would just provide unit conversion to millimeter or percentage.

I had in mind to remove percentage and keep only millimeters, but percentage is the only one which makes sens when editing multiple pages (thank you to #256). Here we talk about a positive or negative percent of a dimension of a PDF rectangle.

All this would give more flexibility, like for example allow to extend pages or increase/decrease margin.

So the new dialog would contains:

• A combobox to select the kind of box we want to edit
• 4 fields to edit a PDF rectangle (see PDF spec page 9)
• A widget to switch from percentage to millimeters (disabled in multi-page mode)

Difficulties:

• Require changes in the model
• Require changes in the way iconview work
• We would probably need to create temporary files as implementing this logic with Poppler will be a nightmare

This is related to #199 (model change, temporary files, ...). Maybe this dialog box should also handle scaling.

[jeromerobert]

Well I'm not that sure we need to keep all boxes. May be we could just remove all of them and keep only the MediaBox (which is equivalent to have all box equals to MediaBox). This should cover 99.9% of PDF arranger usages. This would avoid to modify the model.

[mara004]

This is not enough because to extend a page we would need to change both MediaBox and CropBox. I think we can't find a good logic which hide that complicity to the user and work with all kind of PDF.

I think from the PDF side that should actually be doable:

• store positive values as crop, negative values as margins (two separate lists)
• if crop was requested, apply it to the page (edit CropBox)
• if margins were requested, convert the page to an XObject and place it on a new page with resized MediaBox

Well I'm not that sure we need to keep all boxes. May be we could just remove all of them and keep only the MediaBox (which is equivalent to have all box equals to MediaBox).

Nooo, that would be an unclean solution. Ignoring an existing CropBox may lead to unexpected results. I believe that maintaining the existing boxes should not really increase complexity, though I have to admit I don't know about your model requirements.

[angsch]

store positive values as crop, negative values as margins (two separate lists)

Since page splitting is realised with (positive) crops, the user interface for crops and margins must be separated. Example:

1. Split a page into [A | B]. Crop of A: left 0%, right 50%.
2. Extend A to the right. We overwrite the right crop with a negative value. The full page [A| B] would become visible, extended with the added margin.

[mara004]

Oh yes, right. There's no reason for limiting to either crop or margins.
It's the more obvious way to separate crop/margins in the interface anyway. I only thought in the direction of negative crop values because of the above decription.