ThinkGeo.com    |     Documentation    |     Premium Support

Raster stretch using PrinterGeoCanvas

#5

Hi Ethan,

I have now sent a copy of the example to the FTP.

I have removed the packages from the project to reduce the upload size.

Regards,

Zak

#6

Hi Zak,

Thanks for your update, our developer will look into it when he back to work, any question or update I will let you know.

Regards,

Ethan

#7

Hi Zak,

We get your data and reproduce that, the solution is add this line:

printerGeoCanvas.Dpi = 100;

That’s because the default value of printer geocanvas is 96 but printer document is 100, reset the value can solve that.

PrinterGeoCanvas_dpi_100.pdf (574.1 KB)

Regards,

Ethan

#8

Hi Ethan,

Thank you, that has fixed the issue.

Were you able to recreate the problem of the black parts of the scale bar being misaligned with the rest of the scale bar?

Regards,

Zak

#9

Hi Zak,

We cannot reproduce that, if you found how to reproduce it please show us the screen shots or the steps so we can look into it.

Regards,

Ethan

#10

Hi Ethan,

It is noticeable on the example I have shared if you zoom in on the scale bar. It might be marginal, but it shows up worse once it’s printed off.

image.png1242×581 125 KB

Regards,

Zak

#11

Hi Zak,

That’s strange because when I tested that, the scale bar works well, could you please let us know how to reproduce that, for example some special extent?

Regards,

Ethan

#12

Hi Ethan,

It was done using my example. When printing, the extent is programmed to stay the same in this example.

I’ve tried loads of different extents and scales and they all show the same results for the scale bar.

Is the one you’re showing me in the print preview screen? Or is it on a printed version?

Zak

#13

Hi Zak,

Our developer had fixed that.

Please try the sample, and the package in sample is the fixed version.

8947.zip (2.1 MB)

Regards,

Ethan

#14

Hi Ethan,

Sorry for the long reply but I’ve been away.

The solution works and the scale bar is now showing up fine.

Thank you for all your help.

Regards,

Zak

#15

Hi Zak,

I am glad to hear that works.

Any question please let us know.

Regards,

Ethan

#16

Hi, sorry for reviving an old topic but I’m working in this area and picking up on some of what Zak had done. The fix to set printerGeoCanvas.Dpi = 100 worked fine, however people are pushing us to print at significantly higher resolutions as the printed raster quality is considerably below what it could be.

I tried printerGeoCanvas.Dpi = 300 but that, not too surprisingly, exaggerates the original problems. I thought I could get there by setting the printer document to the same value, but have not been able to work out how to do that. I tried a few things, such as:

        PrintDocument printDocument = new PrintDocument();

        PrinterResolution printerResolution = new PrinterResolution();
        printerResolution.Kind = PrinterResolutionKind.Custom;
        printerResolution.X = 300;
        printerResolution.Y = 300;

        printDocument.PrinterSettings.DefaultPageSettings.PrinterResolution = printerResolution;

        printDlg.Document = printDocument;

But with no success.

Do you have any suggestions for setting higher resolutions when printing, bearing in mind that we are likely to have a mixture of raster and vector data.

Thanks,
Jonathan

#17

Hi Jonathan,

For vector, whenever how you print it, the quality is well. But for raster, if you expand the shape, the render quality will reduce, we cannot modify it exception the source data have better precision. They follow different render logic.

We set the dpi to 100 is because in the scenario the device dpi is 100, so that means, you need to set the dpi equal the device default dpi, if you modify it but not modify the device dpi, the problem will appear. Modify the dpi is not helpful for get high quality image.

Wish that’s helpful.

If I misunderstand your scenario please let me know.

Regards,

Ethan

#18

Hi Ethan,

For vector, whenever how you print it, the quality is well. But for raster, if you expand the shape, the render quality will reduce, we cannot modify it exception the source data have better precision. They follow different render logic.

That is a good point. We have a number of different image source types but they are most often the source data is higher quality (better the 100 dpi)…

We set the dpi to 100 is because in the scenario the device dpi is 100, so that means, you need to set the dpi equal the device default dpi

It would be difficult to know what printers customers are likely to use but I have a very standard HP printer but even the Draft quality is 300x300 DPI and Normal is 600x300 DPI (there are higher modes). Setting the printer to draft and printerGeoCanvas.Dpi to 300 results in the raster being re-scaled to a third of it’s size and vector features no longer sitting correctly on top - like in Zak’s original message - but greatly exaggerated,

if you modify it but not modify the device dpi, the problem will appear. Modify the dpi is not helpful for get high quality image.

Not sure I understand this bit? How would I modify the device dpi? I notice there is a PrinterResolutions class that list the available modes. But then how would I respond to the devices dpi to get printing to work correctly?

Thanks,
Jonathan

#19

Hi Jonathan,

Thanks for your further information.

Our developers discuss about it today, it looks it’s a complex if you want to make the DPI to higher and keep raster and vector layers keep match, that’s related with how our classes implement the print logic.

So it maybe cannot get a result quickly, but any update I will let you know.

Regards,

Ethan

#20

Hi Ethan,

Thanks for the information and look forward to some positive developments soon.

Regards,
Jonathan

#21

Hi again,

I have noticed something else that rather changes the situation.

The raster layers I was having trouble with were of type MultiGeoRasterLayer (derived from Layer) and normal raster layers actually respond fine to changes in the canvas DPI. Now MultiGeoRasterLayer is based on ThinkGEO example code and includes an overridden DrawCore(GeoCanvas canvas, …) and it looks like the canvas that reaches this method does not have the same DPI as the canvas being drawn on in printing.

Regards,
Jonathan

#22

Extra Note: I suspect that the same might apply to other derived layers, such as the ThinkGeo’s own LabelPrinterLayer.

#23

Hi Jonathan,

It looks I misunderstand your information in this reply, so I modify it.

Do you means you tried to modify the dpi in DrawCore of your raster layer, but it’s not helpful for solve your problem?

Regards,

Ethan

#24

Hi Ethan,

Quite a bit has changed / been uncovered whilst investigating this problem so it might be easier to try and re-summarise the problem. The current situation is:

If I print a map with a mixture of raster and vector layers with a DPI higher than 100 (set for a PrinterGeoCanvas type object) it sometime works fine and it sometimes shrinks the raster layer to just sit in the top left corner of the paper.

The raster layers that respond correctly are of type NativeImageRasterLayer
The raster layers that have problems are of type MultiGeoRasterLayer (not a standard type but from a ThinkGEO example).

Additionally I have noticed that certain text, such as that used in title boxes (type LabelPrinterLayer) also suffers a similar fate to the raster layer and ends up very shrunk.

I noticed that the MultiGoRasterLayer overrides DrawCore and, by setting a breakpoint, I was able to check what canvas was being passed in. it looked to be the correct type but had a 96 DPI value and not the 300 DPI value set for the canvas. This makes me think that not all the layer attributes are being maintained between layer.Draw(printerGeoCanvas, simpleCandidates); and MultiGeoRasterLayer.DrawCore( … ). I am just guessing that something similar may be happening with LabelPrinterLayer.

Regards,
Jonathan