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.
Regards,
Zak
Raster stretch using PrinterGeoCanvas
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
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
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
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
Hi Zak,
I am glad to hear that works.
Any question please let us know.
Regards,
Ethan
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
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
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
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
Hi Ethan,
Thanks for the information and look forward to some positive developments soon.
Regards,
Jonathan
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
Extra Note: I suspect that the same might apply to other derived layers, such as the ThinkGeo’s own LabelPrinterLayer.
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
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
Hi Jonathan,
Thansk for your further information, I think’t it’s helpful.
Regards,
Ethan
Hi Ethan,
That’s good, it feels to me that the scale of the fix needed has reduced quite a bit from what is seemed initially. When do you think you will hear from your developers?
Regards,
Jonathan
Hi Jonathan,
It’s not be a simple fix, and most of our developers are focus on the new GisServer, so the task list is longer than before.
I will ask our developer to process this problem higher priority.
Regards,
Ethan
Hi Ethan, thanks - much appreciated.
Jonathan
Hi Ethan,
I getting a lot of pressure from users my end about this problem, not just because of raster images but the way title boxes and quite a lot of other text is shrunk to an unreadable level. Do you know what the latest is from your developers?
It appears that generating an image (e.g. a .BMP) using PlatformGeoCanvas doesn’t have any problems, so we are thinking of replacing the existing printing method with the something along the lines: User clicks print, we create a temporary BMP file, we send that to the selected printer, we tidy up by deleting the temporary file. Do you know if there could be any problems with this approach?
Thanks,
Jonathan