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

Fixed resulting pdf page size format #215

Merged
merged 3 commits into from Mar 17, 2017

Conversation

Projects
None yet
2 participants
@fgdrf
Contributor

fgdrf commented Oct 25, 2016

The resulting PDF page format scaled up and it depends from the selected DPI value. For 72dpi the page size was almost correct, if a user selected 144 DPI the page size doubled up and so on.

The fix is to respect select paper size and scales the image down to the page, resolution is as selected.

@fgdrf

This comment has been minimized.

Contributor

fgdrf commented Mar 10, 2017

@egouge What do you think from user perspective? Would you expect to get a different pdf format size at the end if the DPI has been increased? This fix uses the correct format settings for the pdf document (A4 = A4 in pdf format). The resulting pdf e.g. for A4 would fit on a A4 page in printer settings and has not to be rescaled in printer settings.

@fgdrf fgdrf added this to the uDig-2.0.0 milestone Mar 10, 2017

@egouge

This comment has been minimized.

Contributor

egouge commented Mar 14, 2017

I would want the paper size to stay the same. I know what what a 8.5x11 piece of paper is but not the implications of DPI (in term of paper size). So I would suggest keeping the page size the same and scaling the map.

@fgdrf

This comment has been minimized.

Contributor

fgdrf commented Mar 14, 2017

@egouge could you test the behavior and results of pdf exports. I'm interested in your point of view as you have contact to customers and users of uDig.

In the past the users I know were irritated a bit about the output (doubled DPI results into 4 times bigger image/pdf). The user had to re-scale the image to printer page size that was choosen in the export wizard - and was confused.
HTH

@egouge

This comment has been minimized.

Contributor

egouge commented Mar 15, 2017

@fgdrf This seems to work well in terms of maintaining the page size but I noticed some distortions which I don't think should be there when I print in landscape mode.
landscape
portrait

@fgdrf

This comment has been minimized.

Contributor

fgdrf commented Mar 15, 2017

@egouge Please correct me if I'm wrong. Are you saying that the first images is made as "screenshot" as it is displayed in map panel, whereas the secound is a screenshot of exported pdf or vice versa? However that would be a blocking issue for this pull request. I'm going to investigate whats wrong ..

@egouge

This comment has been minimized.

Contributor

egouge commented Mar 15, 2017

The second is a screen shot of the map exported to pdf in portrait mode. The first is the same map exported to pdf in landscape mode. The only thing I changed was portrait and landscape mode. Nothing else changed. I will try to attach the actual pdfs when I get the chance.

@fgdrf

This comment has been minimized.

Contributor

fgdrf commented Mar 15, 2017

I'm going to test what you have done in the current Release, to find out if this behavior has changed by my commits or was present already. I assume the change is th cause ;)

I guess there is no need to attach pdf's

@fgdrf

This comment has been minimized.

Contributor

fgdrf commented Mar 15, 2017

Confirmed, that the patch causes the problem, this is the output I got from the same extent for

  • landscape:
    bildschirmfoto 2017-03-15 um 21 57 00
  • portrait:
    bildschirmfoto 2017-03-15 um 21 57 17

There is obviously no distortions

@fgdrf

This comment has been minimized.

Contributor

fgdrf commented Mar 16, 2017

@egouge Fixed distortion problems. I stumbled about scale computation problems during export. If the user specify a scale denominator, lets say 700.000 the BoundsStrategy sets it for the RendererMap. After that the bounds are re-calculated. So far so good but quering the scale from the ViewportModel again returns a different value than set, e.g. 699999.9999995704 or 700000.0000001818 depenent from selected DPI

However, the computation is another issue we should not adress right here ;)

@fgdrf

This comment has been minimized.

Contributor

fgdrf commented Mar 16, 2017

And not to forget: The Dialog provides four fields to set margins (top, bottom, left, right) but only two of them are used (leftMarginSpinner and topMarginSpinner).

@fgdrf

This comment has been minimized.

Contributor

fgdrf commented Mar 16, 2017

Last commit fixes the margin applyment for each direction.

@fgdrf

This comment has been minimized.

Contributor

fgdrf commented Mar 16, 2017

@moovida Would you please have a look at final changes since your implemented the pdf export initally.

fgdrf added some commits Oct 25, 2016

Fixed resulting pdf page size format
Signed-off-by: Frank Gasdorf <fgdrf@users.sourceforge.net>
[pdf] fixed export distortions
Signed-off-by: Frank Gasdorf <fgdrf@users.sourceforge.net>
@egouge

This comment has been minimized.

Contributor

egouge commented Mar 16, 2017

@fgdrf this might be my problem but I updated just now and the SivecoExportMapToImageWizard has a compile error.
The rest of the changes look good to me - I don't get any distortions and the paper size is correct.

[pdf] apply margins correctly
Signed-off-by: Frank Gasdorf <fgdrf@users.sourceforge.net>
@fgdrf

This comment has been minimized.

Contributor

fgdrf commented Mar 16, 2017

Oh my fault, I fixed it and updated last commit.

@egouge

This comment has been minimized.

Contributor

egouge commented Mar 17, 2017

works fine now

@fgdrf fgdrf merged commit 98380d9 into locationtech:master Mar 17, 2017

@fgdrf fgdrf deleted the fgdrf:image2pdf_formatfix branch Mar 21, 2017

@fgdrf fgdrf added the bug label Sep 13, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment