ThinkGeo.com    |     Documentation    |     Premium Support

Raster stretch using PrinterGeoCanvas

#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

#25

Hi Jonathan,

Thansk for your further information, I think’t it’s helpful.

Regards,

Ethan

#26

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

#27

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

#28

Hi Ethan, thanks - much appreciated.
Jonathan

#29

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

#30

Hi Jonathan,

I will ask our developer about the progress. Just like I mentioned it’s not a easy works because the printing change maybe related with structure modify.

I think your thinking is worth trying, because found a workaround for you is important. Your solution looks like double buffering, in fact our map have similarly logic for solve flikcer.

If you met any problem about it please let us know.

Regards,

Ethan

#31

Hi Jonathan,

Enhancement the logic is more complex than our thought and won’t get a result quickly, so our developer sent a workaround for high dpi printer, could you please view it and see whether it works for your high dpi printer?

Please notice:

  1. The deviceDPI in MapSuiteExample should equal your printer dpi
  2. For the function GetPosition, the parameter PrintingUnit.Point cannot be changed to PrintingUnit.Meter

8947_Sample_2.zip (2.1 MB)

Regards,

Ethan

#32

Hi Ethan,

Thanks, I will try that out today. The help is much appreciated.

Regards,
Jonathan

#33

Hi again,

I hit an initial snag with running the example. It compiles OK, but when running says the licence has expired, however checking with product centre it all looks fine.

Regards,
Jonathan

System.InvalidOperationException
HResult=0x80131509
Message=Your Software Assurance Plan for Map Suite Desktop for WinForms has expired, please contact sales@thinkgeo.com to renew or use the version that was built prior to 10/22/2018 00:00:00.
Source=ThinkGeo.MapSuite.WinForms
StackTrace:
at ThinkGeo.MapSuite.WinForms.Validators.jEU=()
at ThinkGeo.MapSuite.WinForms.Validators.CheckInvokeRequired(Boolean invokeRequired, String controlName)
at ThinkGeo.MapSuite.WinForms.WinformsMap.set_CompositingQuality(CompositingQuality value)
at MapSuiteExample.Form1.InitializeComponent() in C:\Users\User\Documents\From ThinkGEO\2283aa7b96c75a6e955830338cb3b24588a4bb40\MapSuiteExample\Form1.Designer.cs:line 38
at MapSuiteExample.Form1…ctor() in C:\Users\User\Documents\From ThinkGEO\2283aa7b96c75a6e955830338cb3b24588a4bb40\MapSuiteExample\Form1.cs:line 17
at MapSuiteExample.Program.Main() in C:\Users\User\Documents\From ThinkGEO\2283aa7b96c75a6e955830338cb3b24588a4bb40\MapSuiteExample\Program.cs:line 19

#34

Deactivating and reactivating seems to have sorted out getting it to run.
Jonathan

#35

Ethan,

First indications are good, I think it will take a bit of working through properly and I’m going to be out of the office for a week or two, but will try and get it all sorted. Thanks for the help.

Regards,
Jonathan

#36

Hi Jonathan,

Thanks for your update.

If you have any question when back and test it please let us know.

Regards,

Ethan