Does anyone have any examples of using GoXam in Silverlight to output a diagram to a large format printer? I have tried setting the PrintManager.Scale to various values, however the end result is always the same. When printing to a PDF or XPS printer as a test, it seems that once the selected paper size exceeds A3, nothing happens when Print is clicked in the print dialog.
Sorry, but it looks like that is a limitation with Silverlight.
http://forums.silverlight.net/forums/t/191396.aspx
http://forums.silverlight.net/forums/p/190815/446150.aspx
I suspect it’s because the printing implementation renders a high resolution bitmap of each page.
With larger size pages, the bitmap is too big, so it would run out of memory, or some similar kind of reasoning by Microsoft.
Thanks for the quick followup.
Are there any issues with large format printing if using WPF?
I’ve never heard about such a problem, either with GoXam or without, when using WPF.
But I suppose you could search the web for that.
Are there any workarounds for this with GoXam? Can a high res bitmap be generated from the diagram and then saved to the client?
If you think about how large such a bitmap would be, I do not think you would want to implement such an approach.
You could generate many smaller images using Diagram.Panel.MakeBitmap.
Use the overloaded version that takes an Action argument to make sure the bitmap contents have already been rendered by Silverlight.
I am not sure what the advantage of the smaller bitmaps would be. Is there any way to get vector based output that could be used to generate a pdf or xps document for printing? The bottom line is how would you go about printing a diagram on a large piece of paper?
Silverlight 5 will have support for vector printing to PostScript printers.
I would hope that that would include support for printing on large surfaces, but I have not tested that.
Strange !
I have successfully printed to A2 size selected on our HP plotter.
Jim
Did it cover most or all of the sheet? Or did it just need to cover a small fraction of the area?
Walter,
Just got into work and I have seen that I trimmed the graph down.
That said it still measures 570mm x 356mm so bigger than A3.
Jim
OK, thanks for the information.
In any case the print size limits of Silverlight are not something that any of us have any control over.
You do have control over export formats, and export to a vector based format such as PDF, XPS, SVG, or GraphML from Silverlight essentially solve the large format print issue.
We tried http://www.componentone.com/SuperProducts/PDFSilverlight/ which tries to walk the visual tree and create a PDF, but it is beta and fails on the GoXam control. We are hopeful their control will improve if Northwoods does not add some sort of vector export in the future.
A competing graphing control for Silverlight we are evaluating offers GraphML export which can be imported into their free GraphML editor/viewer and printed without limits direct to the windows print system along with PDF export. It also has much smoother layout animation, but that is a no where near as important as the print/export abilities.
Now that Silverlight 5 is out, I am not clear on how to force vector based printing. Is it possible to do that without an updated release of GoXam and can you provide an example?
I don’t know if that is possible using the 1.2 version of GoXam which is compiled for Silverlight 4. I suspect not, but I really don’t know.
You could try the 1.3.1.5 (beta) DLL for Silverlight 5 and see if it does vector printing to a printer driver supporting PostScript.
But wouldn’t GoXam have to have vector based printing explicitly exposed as an option? From what I understand, forcing vector printing requires passing the new PrinterFallbackSettings object in to the PrintDocument.Print method. When using the GoXam PrintManager.Print method, I don’t have access to those settings.
No, I believe it defaults to vector printing, but will automatically fallback to bitmap printing if required.
However, if this is a problem, we could extend GoXam’s PrintManager to provide that control. But at the current time I do not believe it’s necessary.
The problem is that if you have any elements with an opacity other than 1.0, or anything else PostScript doesn’t understand, Silverlight silently falls back to bitmap-based printing. There is a ForceVector property on the PrinterFallbackSettings object which forces Silverlight to print in vector mode, even when postscript-incompatible items exist in the visual tree. There is another property for OpacityThreshold which sets the value over which Silverlight will treat an element’s opacity as 1.0 to support PostScript printing. So right now, there is no way to set these properties using the GoXam PrintManager.
Ah, so you want to try to print in vector mode even when the results might look bad.
OK, we can add that functionality. Give us a few days.
In the meantime, please try the 1.3.1.5 version of GoXam for Silverlight and see if it works for you – not only for printing but for everything else.
Also, could you update your member profile with your corporate e-mail address?
I’ll send you e-mail with the pointer to the new DLL.