I'm trying to print a report (just text in columns) from my Silverlight 4 application. The only way I know about is to use PrintDocument and set the PageVisual to a framework element showing the report. However, this results in an insanely large print job (like 120 MB). This is not what my customer wants. Is there any other solution?
The problem with Silverlight 4 is that everything you go to print is produced as a rasterized image at 600 DPI. This explains the large job size you are seeing. This is also why text from Silverlight can look very fuzzy compared to what you'd expect from your output. Silverlight 5 will address this with Postscript vector-based printing, but for now you are facing the reality that without third-party solutions you are effectively stuck with the out of the box limitations or using HTML.
If you are willing to generate the report from HTML being served server-side you may have the best solution considering what you're doing. In that case you would at least not have to worry about complexities like pagination as part of printing from Silverlight.
A good third-party solution for reporting, but perhaps more than what you need, is to use Reporting Services coupled with this product: http://www.perpetuumsoft.com/Silverlight-Viewer-for-Reporting-Services.aspx?lang=en
One easy solution is to print web page directly from browser (I assume this is not what you want).
I think the PrintDocument and PageVisual is the only way how to print from inside of SL.
I did some printing even with large visual structures, but I haven't checked how large my print job is, so I can't tell you if it is normal or not.
Anyway, you can try not to print directly the element you want to print, but made some other lightweight one which will serve only for printing purposes and fill it with same data and print that lightweight element.
You can convert your text into picture and then print picture.. mb this will help you
http://www.andybeaulieu.com/Home/tabid/67/EntryID/161/Default.aspx
http://www.snowball.be/Printing+In+Silverlight+3+Yes+We+Can.aspx
Related
I need to create application, using which user can handle text in graphical interface.
User can move text objects inside parent panel/canvas or something, change fonts, change size of characters (height, width), spacing between characters and so on.
Target of application:
in the end of handling text (or while handling) user will get a position of every character, height and width of characters, distance between characters (spacing). And all those measures must be in same unit of measure (pixels, points).
So question is: What kind of framework (.NET, Silverlight, XNA, Flash, Java, HTML 5, Javascript and so on) can be used for this.
I am “sold my soul” to Microsoft (worked before only with .NET), but have some experience in Flash, HTML, Javascript, Java. So all proposals are welcome
Trying to approach with Silverlight, but only problem was with spacing (dynamically change), when trying used Glyphs it worked in some way,
only problem was: when with Glyphs spacing was changed(same for all characters), in visual spacing was different for all characters. So spacing problem is biggest for right now.
Another approach can be a handle text as a collection of characters, and calculate by myself distance between characters. But in application every user can use own custom fonts (here my knowledge not enough). So i afraid that we will need to create (draw) every character of font before can use custom fonts.
I found in Internet some applications which doing almost same thing (done in Javascript), but before start want to get more information about other possibilities.
With nobody give some advices about this,I decide to answer own question, because found already a solution how will approach to this project.
So I found a new(for me at least) version of Silverlight hav a new Property CharachterSpacing for Elements which handling with text(TextBox, Label and so on). Using this property I can change dynamically a text spacing.
Documents tell us that this property use as a unit integer which is 1000s of font's em unit. About em:
"Em size is a typographical measure that specifies the approximate width of the capital letter "M" in the Roman alphabet, measured in the units that are prevalent in a particular technology. Silverlight em sizes are given in pixels. The apparent visual size of the em size varies per font.”
So this give a very good basement for counting a real distance between charachters.
I'm trying to write an CAD-like application in WPF(.NET 4.0) that needs to be able to display a lot of 2D points/lines. It will be used to display CAD-plans of entire cities with zoom, pan, rotate and point snapping on mouseover.
Right now I purely use WPF. I read the objects from the CAD file draw them into a StreamGeometry, use it as stroke of a new Path and add it to a Canvas, with several transforms.
My problem is that this solution doesn't scale well enough. It works fine with small CAD-files, but when I want to display like half a city(with houses and land boundaries) it is very very delayed.
I also tried to convert my CAD-file to an image, but
- a resolution a 32000x32000 is sometimes not enough
- when zooming out the lines are too thin.
In the end I need to be able to place this on a Canvas(2D/3D) as background.
What are my best options here?
Thanks,
Niklas
wpf is not good for a large 3d models. im afraid it is too slow. Your best bet is direct 3d or openGL
However, even with the speed of direct3d,openGL you will still need to work out how to cull as many polygons/vertices as possible before the rendering of the scene if you are trying to show an entire city.
there is a large amount of information on this (generally under game development)
there are a few techniques including frustrum culling, near and far plane culling.
also, since you probably have a static scene you may be able to use binary spacial partitioning.
As I understand the subject is 2D CAD system within WPF.
Great! I use it...
OpenGL and DirectX are in infinite loop OnDraw always. The CPU works all the time.
WPF/Silverlight 2D is smart model.
Yes, total amount of elements (for example, primitives inherited from Shape) must be not so much. But how many?
I tested own app (Silverlight). WPF will be a bit faster I hope...
Here my 2D CAD results. Performance is still great. Each beam consists of multiple primitives.
Use a VirtualCanvas like this one from Chris Lovett.
I've developed application using Silverlight, and now I need to implement printing, I've used
PrintDocument class, it looks like this:
PrintDocument printDocument = new PrintDocument();
printDocument.PrintPage += new EventHandler<PrintPageEventArgs>(printDocument_PrintPage);
printDocument.Print("My docuement");
But I've faced with problem - it takes much time if there are 20-30 pages, and if I open printer's queue, it shows that printing size is about 1.2GB for 10 printed pages. I've tried to print canvas (800*1000) with only one textblock with simple text like "Test printing".
I'm using Silverlight 5.
Did anybody faced with such problem? Is there any way to avoid it?
My guess is that the content to be printed is send as a bitmap instead of a more efficient vector format.
This might be due to the driver. If the driver of the printer is not able to translate the Silverlight graphics into vectors, all it can do is print it as a bitmap.
I tried to force Silverlight into using Vectors but my printer didn't support PostScript.
So I switched to a printer that does and suddenly it's just kilobytes.
I see only two ways to avoid bitmap printing:
Get a PostScript printer or
Create a printer friendly document (PDF, Word, text) on the server and allow the client to download and print it by hand.
I've just created my first WPF application (3 calculators inside 3 different tabs).
The entire application has been built using widths/margins/paddings as static values, since I originally didn't know that dynamic values can be used by just putting an asterix after the value.
The client has come back to me though and has asked me to increase the size of the app, that includes form fields, tabs, font-sizes, grids etc...
What would be the easiest (and/or quickest) way to do this? I'd hate to go value by value resizing every single element since there are quite a few.
I can provide code but there is lots of it and I'm not sure of how much help it would be.
Appreciate your help,
Marko
Put it all in one ViewBox, play with viewbox size to change the app size
Write an XSLT transform to take your XAML as input and spit out appropriate modified XAML, which you put back in your app.
When I read books about WPF, I saw the authors mention XPS like it was something important. Windows also includes its XPS viewer, and I've seen that listed as a "feature" of Windows.
But why? What's the point? Who the heck uses it? It's my understanding that XPS is, basically, like PDF, xhtml, or ePub (which is just xhtml)...or even Word's docx format. Many of the features are the same among those formats.
It doesn't seem to have any major benefits compared to any of those other formats. It seems to me that xhtml would be so much more useful than XPS as a way to save and load FlowDocuments from the RichTextBox. I've looked at multiple blogs about converting between the two. Most or all of the rich text on the internet is (x)html. Beyond that, I don't think anyone uses it just to publish their docs; PDF is preferred. It seems like XPS is just some random format that MS made and decided to push. I generally love MS, but they do have a habit of that kind of thing. Couldn't MS have made an api using xhtml instead? That would have been more useful in a lot of situations, I'd think.
So, is there a point to using XPS, particularly in comparison to one of the other formats I mentioned (or any I haven't)? Have you ever used XPS in your programs or otherwise?
As U62 already stated, WPF comes with a DocumentViewer control which enables you to view XPS documents. The DocumentViewer also has some useful fonctions like Print, Zoom, FitToPage etc... So you don't need to implement that or use a third party tool.
What I just finished an hour ago using XPS and the DocumentViewer was some kind of "Adress label print preview". Allow the user to select some contacts from a list of contacts, click "Print Preview". This opens a new XAML Window which contains a DocumentViewer control and a ListBox with the choice of different Labels (e.g. 1 sheet with 12 labels [2 columns, 6 rows], 1 sheet with a single label whose width and height can be user defined).
Based on the users selection, I generate an XPS Document in the layout the user selected with the adresses of the selected contacts. If e.g. the user selected 4 contacts and wishes to print them on "SingleLabelSheet"'s, I generate 1 XPS document with 4 pages, each page containing 1 Adress. Then I display the XPS in the DocumentViewer and the user can print the labels on our Label Printer.
Once I understood how the XPS API worked (at least the Basics), it was a matter of 2 hours to get this up and running.
So, basically, I see XPS as an easy to use API to display FixedDocuments which are to be generated on the fly. But I wouldn't personnally go about saving them to my HDD or somehow modify them or whatever you generally do with documents.
The only actual advantage I can think of is that you have a control for viewing XPS documents in WPF applications. The other formats you mention mean you would have to bring in a 3rd party renderer (or write one yourself if you have a year to spare).
btw. I don't know much about ePub, but XPS isn't directly comparable with XHTML, it's more like PDF in that it's designed to have a fixed layout.
XPS to WPF is like WMF to Win32/WinForms, it's a persistent format that let you store and print native WPF graphics.
XPS is used to print from WPF (even when you print directly from the application without saving, the internal printing system is built on XPS) so what should MS do:
Create a new file format that exactly fit with what they are trying to do
Build a 100% perfect translator from WPF to a format they don't control like PDF (and hope Adobe doesn't break all WPF applications out there with the next release of Acrobat Reader).
What would you do?
Saving XPS files is just a nice bonus.
Look, I may be a pessimist on XPS as a report generation solution, but I gave it a go and found the initial documentation to be hard to understand, with less real world samples out there than what I would have liked. When I put it into a real world business application I found it to be frustrating, particularly in LOB apps that require tables that span over multiple pages.
Things may have changed since then but as soon as I started looking at tables that spanned over several pages and I wanted column headers to go to the top, etc. I found that the API required me to do what I would call excessive workarounds with unnecessary complexity.
So, things may have changed since then (about 8 months ago), but I went from XPS to using ITextSharp and that has been a lot less painful.
So the only advantage I would say, like everyone else, is the built in viewer in WPF - but other than that I feel the API may need to "mature" a bit more before I will attempt something again in it.
Actually I found a really nice reason to use XPS. I wanted to print from multiple sources, merge documents and specify duplex and stapled. Finally it should be printed as one document with duplex and stapled. I was having a difficult time doing so but found that by printing to XPS (saved to disc) I could accomplish my goal with minimum fuss. I haven't found any other method that is so easy and straightforward.
Dim PrintServer As New SysPrint.PrintServer("\\" & My.Computer.Name)
Dim PrintQ As New SysPrint.PrintQueue(PrintServer, "Ricoh Main")
Dim Jobs As SysPrint.PrintJobInfoCollection = PrintQ.GetPrintJobInfoCollection
Dim able As SysPrint.PrintCapabilities = PrintQ.GetPrintCapabilities()
Dim CurrentTicket As SysPrint.PrintTicket = PrintQ.CurrentJobSettings.CurrentPrintTicket
If able.StaplingCapability IsNot Nothing AndAlso able.StaplingCapability.Count > 0 Then
If able.StaplingCapability.Contains(Printing.Stapling.StapleTopLeft) Then
CurrentTicket.Stapling = Printing.Stapling.StapleTopLeft
End If
Else
Debug.Print("no stapling capability")
End If
CurrentTicket.Duplexing = Printing.Duplexing.TwoSidedLongEdge
Dim fiName As String = "S:\Temp\PS\XPS\Test.xps"
Dim TestJob As SysPrint.PrintSystemJobInfo _
= PrintQ.AddJob("Test job", fiName, False)
XPS (code named "metro") was clearly designed as the Microsoft alternative to PDF and PostScript in Windows Vista. See this old article here: Microsoft Readies New Document Printing Specification
There are different approches when inventing document formats:
Some are made for quick view on screen (say low def) like HTML, doc.
Some other are (or can be) very respectuous of printing contrains (say quality based) like PDF, XPS.
So XPS whiches to be as good as PDF, plus it is formated in XML, so "maybe" it is more standard than the stream approch in PDF.
The black spot of XPS is maybe the management of special colors (Pantone, paper effects).