ThinkGeo.com    |     Documentation    |     Premium Support

Raster stretch using PrinterGeoCanvas

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

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

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

Hi Ethan,

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

Regards,
Jonathan

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

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

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

Hi Jonathan,

Thanks for your update.

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

Regards,

Ethan