templates - map label quality control
Hello,
I'm trying to make print and label report templates that result in good quality output (PDF and JPG). I seem to be running into some problems balancing quality output resolution with readable map labels. I have put a fair amount of time developing base maps services that include scale-dependent labels for street names and house numbers. The map services are cached. All looks good via the Silverlight viewer. But... If I create a print template with a 96 dpi resolution, the output map has labels of a legible size, but of poor quality resolution. When I up the resolution to 300 dpi for quality printing, my labels (and line weights) shrink to a point where they can't be read.
Is there a good technique to balance both output resolution and label legibility, all while keeping a good looking map in the viewer? Is this something to be controlled at the ArcGIS service level vs. Geocortex?
Thanks for any help...
Alice
-
This old chestnut....
If LG actually put a PNG into the PDF rather than a poor excuse for a JPG and then mashed it together - you would not be having these issues. As a test - print to PNG format from the Essentials Viewer and see what you get.... cached tiles that look good!
We've given up on the whole quality thing - it's bearable at best, and for proper mapping we are using arcpy mapping via workflow - where you get true PNG quality in a pdf. Try exporting pdf from ArcMap and you can see the difference!
I love the product - but he whole printing thing out of the box is a real let down, and they are not doing anything about it, which is a shame.
cheers
Gareth
0 -
Gareth
We are also struggling with printing high quality prints. You pointed arcpy mapping via a workflow. Can you share your ideas/workflow?
Thanks
Jimmy Brink
0 -
Folks, two different issues are being reported here.
Alice, the label quality is related to print template generation when you have a cached service. Because we are requesting a 300DPI image, ArcGIS Server will use a cache level that provides images that have enough dots to simulate 300DPI, assuming 96DPI is normal. So, it is using images from a larger scale to make the resulting output image.
It's equivalent to standing farther back from your monitor to see more area - you will see more but things on the monitor will appear tiny. I posted some more info in our Knowledge Base while ago: (https://support.geocortex.com/printing-and-exporting-images-with-a-cached-service-) Printing and Exporting Maps with a Cached Service .
Gareth, the use of JPEG within the PDF happens because of the PDF generation library that we use. I suspect that it does this to ensure backward compatibility to the PDF standard. It may be possible to use PNG instead when we do an asynchronous print; I will investigate that.
Regards,
-Malcolm
0 -
@Malcolm,
thanks for investigating the potential of putting a true png type image in the print. I found out some time ago that the pdf engine was the culprit.We have a similar product over here that does the same thing unfortunately. I think one thing that would help in the meantime, would be to have the option of taking our 'current extent' as the default option for the print scale. This in my view exacerbates the problem of printing at scales that do not suit a tile caching regime. If the default was 'current scale' and if you are using the snap to levels in the viewer then you would see like for like - although you do end up with a lossy jpeg at the end of the day... but food for thought and I know many on this forum are asking for this feature.
@Jimmy,
Yeah - we have a combination of OOTB printing from the SLV, and workflow driven ArcPy templates that are used in our control centres etc.. for better mapping. The users can choose from a list of pre-defined templates A4-A0, with precanned text, legends etc. by taking advantage of sending the print task to a geoprocessing job - on another server also! I'll PM you the details as the python side of things was outsourced and I was the glue with the workflow side of things...
cheers
Gareth
0 -
Malcolm, thanks for the explanation. It sounds like the short story is to use only dynamic maps services to guarantee high quality printed map output.
Exporting as a PNG or PDF produce the same results.
I was a bit confused about one statement: "In order to provide high resolution printing, the screen image must have its resolution (DPI) increased – screen resolution is considered to be 96dpi." To me, this implies there is a way to increase screen resolution beyond 96dpi - but I don't think that's possible?
Since my initial post, I experimented with creating a 300 dpi cache within AGS. Unfortunately, this did not fix the problem - which Malcolm's explanation corroborates. I had hoped that if the Essentials / Silverlight viewer had access to a higher resolution source image, it would be able to take advantage of that for the print output, without having to shrink a larger scale's image to match my desired resolution.
The catch-22 in all of this is... If the user creates there print at 96 dpi AND at one of the pre-defined cache scales, they get a readable map. But, other aspects of the template, e.g. north arrow, corporate logo image, degrades to match the 96 dpi. I feel a bit stuck in a bit of a Bermuda Triangle of limitations bounded by application performance (caching), map output quality, and total template product quality. In the scheme of things, we'll sacrifice logos and north arrows for readable printed maps and a high functioning application. But, I'll still wish for utopia... :)
0 -
Jimmy - PM me with your email address. It's not on your profile.
0 -
Gareth
I didn't see your email in your profile, so I sent you an email per email address I found on your fire-and-other-emergencies website.
Thanks
Jimmy Brink
0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
7 Kommentare