Project

General

Profile

Bug #10303

print module does not retain properly paper size in presets

Added by Bogdan Hlevca over 4 years ago. Updated over 4 years ago.

Status:
Fixed
Priority:
Low
Assignee:
Category:
Printing
Target version:
-
Start date:
01/30/2015
Due date:
% Done:

100%

Affected Version:
git development version
System:
openSUSE
bitness:
64-bit
hardware architecture:
amd64/x86

Description

This is related to presets.

1) Store the papers size in presets
2) play with presets and store another one, perhaps change paper size
3) go back to the firs preset the paper size shows negative value.

I used A3+borderless paper size

Print-ARW1.png (1000 KB) Bogdan Hlevca, 01/31/2015 07:21 PM

Print-bottom.png (1000 KB) Bogdan Hlevca, 01/31/2015 07:55 PM

Print-centre.png (1000 KB) Bogdan Hlevca, 01/31/2015 07:56 PM

Print-left.png (1000 KB) Bogdan Hlevca, 01/31/2015 07:56 PM

Print-right.png - Here is the problem (1000 KB) Bogdan Hlevca, 01/31/2015 07:56 PM

Print-top.png (1000 KB) Bogdan Hlevca, 01/31/2015 07:56 PM

History

#1 Updated by Bogdan Hlevca over 4 years ago

2) play with presets and store another one, perhaps change paper size

I meant play with various settings

#2 Updated by Pascal Obry over 4 years ago

  • Assignee set to Pascal Obry

I've just fixed an issue with the units and borderless printer. Not sure it is this issue which I cannot reproduce. Can describe more precisely the procedure to reproduce?

#3 Updated by Bogdan Hlevca over 4 years ago

1) select a RAW image
2) select print in the top menu
3) select printer (printer section)
4) select profile (printer section)
5) select paper A3+Borderless (page section)
(by the way in this case - Borderless -the margins should have been automatically set to 0)
6) set all the margins to 0
7) check imace width height = 19.02 x 12.64
(it is a bit off it should be 19.00 x 13.00 or 48 x 33 in cm
see here http://www.specialistinks.com/paper-sizes.php
)
8) save the preset
9) Close and restart darktable
10) select an image and select print again. (Note: previous settings were not preserved)
11) select the preset from the top left button of the modules
12) it shows now -87.40 x -57.87 (inch) but at times I got other values
(see attachment)

darktable version 1.7.0+819~ge06728b

#4 Updated by Bogdan Hlevca over 4 years ago

After updating to the last fixes

Updating e06728b..2fc4a20
Fast-forward
src/iop/temperature.c | 2
src/libs/print_settings.c | 22 +++++++++
+----------

the bug seems to be gone. I don't get the negative numbers anymore.

However, it still has the odd numbers 19.2 x 12.64
Also, the image and grey margins are not centered as it should although I have the alignment on the central +.
(I have a grey margin to the right of the image)

It is getting better, but it needs a little more work on the margins, sizes and alignment.
I believe that the extra grey margins are due to a faulty size calculation.

#5 Updated by Pascal Obry over 4 years ago

Ah! ok because I wasn't able to reproduce.

However, it still has the odd numbers 19.2 x 12.64

Depends on the size reported by CUPS. When you print can you:

$ darktable -d print

And then send the log displayed?

Also the size reported is the one of the image. If the image has not the same aspect ratio that the page it cannot fit and so the reported sizes is not the paper width and height. Maybe a screen shot of what you're seeing will help understanding the issue.

#6 Updated by Bogdan Hlevca over 4 years ago

Colour printing is expensive on A3+ and I cannot do it at this time, I don't have enough paper and ink. O will do the -d printer at a later time. Although I could try with a smaller format A4/Letter on a B&W printer. It should point to the same issue. What do you think?

However, the alignment bug is captured in the 5 images attached

Basically it does not align to the right if selected.

I assume that the gray rectangle represents the size of the paper and if selected borderless I would expect to fill it all. If the aspect ratio does not match you could offer a crop solution (where the image is exceeding the paper size and it is cropped to that size). This will offer the option of using the whole paper that is standard for my frames.

#7 Updated by Pascal Obry over 4 years ago

No the gray area is the printable area. That is the paper minus the margin. With 0 margin it is in fact here the size of the paper. And your image has not the same aspect. So the gray area on the top/bottom are OK. The right one should not be there, I have also a very small area but this is just a display issue. The computing for the print is different and more accurate when creating the final PDF layout. All in all, I'm not convinced there is anything to fix at this stage.

#8 Updated by Bogdan Hlevca over 4 years ago

This is strange. I don't think I understand you properly. I thought that the grey area is the NON printable area. See below 1).

1) I think that total area of the image + the gray stripes = the area of the paper.
Normally, the printable area is area covered by the image. When margins are zero there should be no grey stripes if the aspect ratio of the paper matches that of the image. When the aspect ratios do not match then they can be treated as in point 2) below:

2) If aspect ration is not the same I think that you should let the user choose if
2.1) he/she will cut form the paper (ie. keep the aspect ratio of the image and make it as big as the paper will let it on the longers side
2.2) Crop the image at the aspect ratio of the paper.

For now it appears that you support only 2.1

3) Yes you need to fix something as you mentioned in your post the grey area on the right should not be there. However, as I showed in the attachments there is still a problem with alignment to the right. It does not work. Look carefully at the Print-right.png and you will see that the grey stripe is on the right when it should be on the left in that case (align to the right of +). All the other cases of alignment are behaving properly. So even if the vertical grey stripe should not be there it exposes a problem with alignment to the right that you may want to look at.

I know that there are some tricky calculations for the alignment for so many possibilities and I really respect what you do. I am just trying to help you finding the problems .

To conclude I think that 2.2 is essential and if you want me to file for an enhancement please let me know. It is very important for photographers to be able to print/use the whole area of the paper. Of course we still have the option to trim/adjust the aspect the image before we enter the print module, but doing it in the print module would be so nice.

#9 Updated by Pascal Obry over 4 years ago

No the whole white page is the PAPER or page. The gray area is the printable area so the PAGE minus the MARGINS.

Indeed 2.1 is the only option. Cropping the image is not an option in this module nor I think it is desirable to support this. If you really want to crop your image just export as PDF and do whatever you need from any standard software supporting PDF.

For the little space on the right there is probably something to do but again this only affects the display and not the print.

#10 Updated by Pascal Obry over 4 years ago

Just to be clear, you said:

 However, as I showed in the attachments there is still a problem with alignment to the right. It does not work.

No that's wrong. It works as much as the other alignments. This is just a little offset on the right. Again this is due to a wrong calculation of the size of the image during display.

#11 Updated by Bogdan Hlevca over 4 years ago

It think we are on the same page. I did not make the difference between white and grey. I meant that whole thing that is not black is the page which you say it is white,

OK I understand that is a calculation error that affects display. You and I know that, but eventually it will have to be fixed as it will confuse other people thinking that the gray thing is what is excluded from print.

Do you want me to file an enhancement for 2.1? Or you are too busy at the moment to work on something like this?

#12 Updated by Pascal Obry over 4 years ago

  • Status changed from New to Closed: invalid

You can file an enhancement request. I'll close this PR.

#13 Updated by Tobias Ellinghaus over 4 years ago

If you want to get darktable's printer debug output without wasting paper or ink you could just remove all paper from the printer, start the print in darktable to get the debug output and then remove the print job in CUPS.

#14 Updated by Pascal Obry over 4 years ago

No need to open a new PR it should be fixed now.

#15 Updated by Bogdan Hlevca over 4 years ago

1)
Pascal Obry wrote:

No need to open a new PR it should be fixed now.

You mean the point 2.1. I know that for 2.1 no PR is needed as it is already implemented. My main concern is 2.2 where We need to have the entire paper covered by the image even if that means changing the image aspect ratio to the aspect ratio of the paper by cropping the image. Most photo applications allow that, for example Lightroom. It comes very handy what you want to print your image to a fixed size of paper you you dont want to cut the paper to the aspect ratio of the original image. I think that I am not the only one needing this. I assume that the code from the "crop and rotate" module could be used for that purpose.

So my question is if you would consider implementing my 2.2 point and if I should file an enhancement request for that?

2) The output from darktable -d shows the image size 19.02in x 13.02in
while in the UI is 19.02in x 12.64in . I assume the diffeence is given by the margins which are reported correctly but on the GUI side that slim band still appears.

[print] area for image 2992 : 19.02in x 13.02in
[print] max image size 5705 x 3906 (at resolution 300)
[print] margins top 54 ; bottom 54 ; left 0 ; right 0
[print] printer options (25)
[print] Borderless=true
[print] copies=1
[print] device-uri=tpu://Canon/Pro9000II_series/SN=308861
[print] finishings=3
[print] job-hold-until=no-hold
[print] job-priority=50
[print] job-sheets=none,none
[print] landscape=true
[print] marker-change-time=0
[print] media=A3+Borderless
[print] number-up=1
[print] printer-commands=AutoConfigure,Clean,PrintSelfTestPage
[print] printer-info=Canon_PIXMA_Pro9000II_(TurboPrint)
[print] printer-is-accepting-jobs=true
[print] printer-is-shared=true
[print] printer-location=
[print] printer-make-and-model=Canon_PIXMA_Pro9000II TurboPrint
[print] printer-state=3
[print] printer-state-change-time=1420477770
[print] printer-state-reasons=none
[print] printer-type=8531996
[print] printer-uri-supported=ipp://localhost:631/printers/Pro9000II-TurboPrint
[print] sides=one-sided
[print] STP_FullBleed=true
[print] StpFullBleed=true

3) You closed the bug as "Invalid" when in truth when it was open the bug existed and you fixed while we were exchanging information. A fair resolution would have been "Fixed".

This is awesome work, good to have this module in DT, but if you can implement that image to page aspect adjustment it would be brilliant. Cheers!

#16 Updated by Pascal Obry over 4 years ago

  • % Done changed from 0 to 100
  • Status changed from Closed: invalid to Fixed

Fair for the invalid. I expected to fix that later in another PR but finally it was easier than I though.

#17 Updated by Pascal Obry over 4 years ago

2) The output from darktable -d shows the image size 19.02in x 13.02in
while in the UI is 19.02in x 12.64in . I assume the diffeence is given by the margins which are reported correctly but on the GUI side that slim band still appears.

Right, but it is the area for the image (the gray area) that is the printable area. But again if the image does not have the same aspect it won't fill all this area which is the case here.

I'll rename:

[print] area for image 2992 : 19.02in x 13.02in

to:

[print] printable area for image 2992 : 19.02in x 13.02in

which should make things clearer.

#18 Updated by Pascal Obry over 4 years ago

No I won't consider implementing 2.2 for this reason. darktable is a photo editing software, so the proper process here to me is:

1. go to darkroom and edit the picture, including possible crop.

2. print this picture as developed.

I understand that in some image viewer it can be handy to crop the image while printing, but in darktable it does not fit the workflow. Again this is my point of view, if many people including the core developers disagree I'll implement this.

To me cropping at the time of printing is kind of molesting your picture, no? If you have cropped it in the darkroom why would you allow losing part of it while printing, frankly this is beyond me :)

#19 Updated by Tobias Ellinghaus over 4 years ago

I am not sure if I understand why someone would like to crop the image when printing, but from a technical side you can just have the bounding box of a dt_pdf_image_t have negative coordinates and the printer/CUPS should do the cropping for you.

#20 Updated by Bogdan Hlevca over 4 years ago

Tobias Ellinghaus wrote:

I am not sure if I understand why someone would like to crop the image when printing, but from a technical side you can just have the bounding box of a dt_pdf_image_t have negative coordinates and the printer/CUPS should do the cropping for you.

I'll give you an example. You have your pictures already developed and you have various paper formats and what to experiment on paper what looks better or simply you want to print for different purposes on different formats. Having this feature available at this stage will allow you to use the whole area of the paper without going back and redevelop/adjust aspect ratio. It is all about convenience. I agree that it is not critical, as there are ways to go around the limitation, but it can be handy for people who print a lot on different paper formats. You don't have to create several versions of your image for each of your targeted formats.

Negative coordinates are not allowed yet and Pascal would still have to do something to show visually when the negative margins will fit the paper, otherwise is just a trick/hack that does not guarantee the user the required precision. As Pascal and you mentioned you don't want to molest your picture but crop it properly to the essentials so that it looks nice on your paper.

Obviously this could be also done in the Darkroom mode if it was an option to show what paper size you are targeting. Otherwise is will be a little hassle to go back and forth between darkroom mode and print mode.

In my opinion is either done properly or leave it as is. The user has the option to go back to the darkroom mode, crop the image to the same aspect ratio of the paper he/she wants to use, and return to the print mode and print the whole page.

In any case this module is an essential and great addition to darktable.

#21 Updated by Tobias Ellinghaus over 4 years ago

Bogdan Hlevca wrote:

I'll give you an example. You have your pictures already developed and you have various paper formats and what to experiment on paper what looks better or simply you want to print for different purposes on different formats. Having this feature available at this stage will allow you to use the whole area of the paper without going back and redevelop/adjust aspect ratio. It is all about convenience. I agree that it is not critical, as there are ways to go around the limitation, but it can be handy for people who print a lot on different paper formats. You don't have to create several versions of your image for each of your targeted formats.

I still don't understand. So you would be able to get papers filled completely with ink, but the result would just be a random part of the image, so the result is useless and to be thrown away. Or is a crop of the image wit the same physical size is all you want to compare printers? I really don't understand.

Negative coordinates are not allowed yet and Pascal would still have to do something to show visually when the negative margins will fit the paper, otherwise is just a trick/hack that does not guarantee the user the required precision. As Pascal and you mentioned you don't want to molest your picture but crop it properly to the essentials so that it looks nice on your paper.

That was a comment for Pascal about how to do it in code, not something the user could do.

Obviously this could be also done in the Darkroom mode if it was an option to show what paper size you are targeting. Otherwise is will be a little hassle to go back and forth between darkroom mode and print mode.

Wouldn't you crop your image to look like you want it to look, then print as big as possible with your paper and then cut the white border away? If you want to avoid cutting you would probably crop to the aspect ratio of your paper of which most people only have one. Or two if they are from the US.

#22 Updated by Bogdan Hlevca over 4 years ago

Tobias Ellinghaus wrote:

I still don't understand. So you would be able to get papers filled completely with ink, but the result would just be a random part of the image, so the result is useless and to be thrown away. Or is a crop of the image wit the same physical size is all you want to compare printers? I really don't understand.

It will not be a random part because what I propose is that the current alignment system created by Pascal for dealing with the margins will let you visually select the part of the image yow want to be printed. It is exactly the same process done by the "crop and rotate" module, but with the added benefit that you can superimose the paper format and you can crop to that aspect ratio selecting the best framing.

Wouldn't you crop your image to look like you want it to look, then print as big as possible with your paper and then cut the white border away? If you want to avoid cutting you would probably crop to the aspect ratio of your paper of which most people only have one. Or two if they are from the US.

I am not in the US but in Canada and we use both cm and inch (because we are to0 close to the US). We have many paper formats A3+: 19x13 inch (ratio 1.46), A3:17x11 (1.54), Letter:11x8.5 (1.29), 7x5 (1.4) 6x4 (1.5) legal 14x8.5 (1.64). I don't print on postcards which have 1.5 ratio and will fit with no cropping on the 3:2 RAW aspect ratio. In photography I am mostly interested in large formats and I don't print postcards. I can do that at the photoprocessing booth at the street corner.

Sometimes you want to do this (cutting the paper), but sometimes you don't want that. For example RAW format is almost always 3:2 aspect ratio, but our natural vision (2 eyes see more on the horizontal directior) I would rather shoot in 16:9. However having a larger image due to the aspect ration lets me choose the best framing. Also if you targes a slideshow for screen viewing you need 16:9 and you need always to crop the images. It is the same with framing an printed image, you want the picture to fill the whole frame to look at its best and not use the 3:2 format just because the sensor has that shape.

For example if you have a set of frames (cheaper to buy them premade than to make custom frames) that have all the same size and want to create an exibition you need to fill the whole frame with the image. You can't cut the frame and making the paspartout larger may look ugly. Why should I make the features in the pictures look smaller when I am interested only in some things in the image. OK you can tell me that I should have done it when I took the picture, but you don't have always toe uxury of a studio and field pictures are ofter seizing some opportunities and you need to deal with what you have.

As I said the whole adjustment process of mathcing the image aspect ratio to the paper can be done in a previous step, but is more cumbersome to manually calculate the aspect ratio of your paper and match the image to it. Pascal's module doing it would be so much nicer and will allow to visually change the aspect ratio of the printed image. In addition it would offer the flexibility ot based on the paper size at hand on the fly.

In my opinion this feature would add the the already awesome features darktable has and the process will be more elegant. I understand that it is not a critical feature as ther are other ways of doing it, but it would be nice to have.

Also available in: Atom PDF