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.
Related
I'm drawing certain images in WPF which will be displayed by a game (developed by a third party). I currently produce the images using a RenderTargetBitmap. Unfortunately it seems that this only supports the Ideal text formatting mode, resulting in blurry small fonts. The application is a third-party game and thus there's no way around using images.
Can I tell the RenderTargetBitmap to assume that it's drawing an image destined for one of the current montiors? Is there another way to get WPF to use the Display rendering mode for off-screen drawing?
I understand why this might seem wrong in the theoretical sense, but in practice there are reasons why I think this is not an unreasonable thing to do:
One of the things the Display mode allows is aliased text, which looks better at small sizes than the Ideal rendering, and is completely independent of monitor properties such as gamma.
A screenshot of small Display-mode text rendered in ClearType looks far better on any screen, even those with different gamma, than Ideal-mode text.
Can the WPF rendering engine do this, or do I have to fall back onto GDI? (which has no difficulties with using Aliased or ClearType rendering off-screen)
There is certainly no obvious way of doing this. I guess drawing to images was never a goal of WPF; the fact that it can actually do this fairly well most of the time must be accidental.
It seems that this works now. Could someone else verify? Here's the relevant code:
var textBlock = new TextBlock();
textBlock.Text = "Hello World";
textBlock.FontFamily = new System.Windows.Media.FontFamily("Arial");
textBlock.Background = System.Windows.Media.Brushes.Transparent;
textBlock.Foreground = System.Windows.Media.Brushes.Black;
textBlock.FontSize = 50;
// . Set Formatting Mode Works! Setting the rendering mode doesn't.
System.Windows.Media.TextOptions.SetTextFormattingMode(textBlock, System.Windows.Media.TextFormattingMode.Display);
Edit: Forgot to mention I'm using the .NET 4.5 framework
Edit2: The difference between Display and Ideal is especially noticeable at smaller font sizes.
I'm developing an application that shall receive images from a camera device and display them in a GTK window.
The camera delivers raw RGB images (3 bytes per pixel, no alpha channel, fixed size) at a varying frame rate (1-50 fps).
I've already done all that hardware stuff and now have a callback function that gets called with every new image captured by the camera.
What is the easyest but fast enough way to display those images in my window?
Here's what I already tried:
using gdk_draw_rgb_image() on a gtk drawing area: basically worked, but rendered so slow that the drawing processes overlapped and the application crashed after the first few frames, even at 1 fps capture rate.
allocating a GdkPixbuf for each new frame and calling gtk_image_set_from_pixbuf() on a gtk image widget: only displays the first frame, then I see no change in the window. May be a bug in my code, but don't know if that will be fast enough.
using Cairo (cairo_set_source_surface(), then cairo_paint()): seemed pretty fast, but the image looked striped, don't know if the image format is compatible.
Currently I'm thinking about trying something like gstreamer and treating those images like a video stream, but I'm not sure whether this is like an overkill for my simple mechanism.
Thanks in advance for any advice!
The entire GdkRGB API seems to be deprecated, so that's probably not the recommended way to solve this.
The same goes for the call to render a pixbuf. The documentation there points at Cairo, so the solution seems to be to continue investigating why your image looked incorrect when rendered by Cairo.
unwind is right, cairo is the way to go if you want something that will work in GTK2 and GTK3. As your samples are RGB without alpha, you should use the CAIRO_FORMAT_RGB24 format. Make sure the surface you paint is in that format. Also try to make sure that you're not constantly allocating/destroying the surface buffer if the input image keeps the same size.
This has been my problem since I started using openGL.
What code am I going to use to show text and get value. I could not use printf and scanf and my only header file is glut.h.
This has been my problem since I started using openGL.
What code am I going to use to show text
Difficult subject, because OpenGL itself doesn't deal with text output. You can:
render text to an image and display that
create a texture atlas from the glyphs of a font, then render from that font texture
draw the font glyph outlines as geometry
If you Google "OpenGL font rendering" you'll get a large number of results of papers on the topic. Recent and old ones alike.
and get value.
Not with OpenGL. OpenGL is a drawing API. You send it points, lines and triangles, and it draws nice pictures for you. User input is outside the scope of OpenGL. That's on part of the GUI system. Most likely one of
Windows GDI
MacOS Cocoa
X11
Standard user input event processing applies. Usually one uses a toolkit like Qt, GTK or similar. Those toolkits deal with user input processing through their event mechanism.
http://linux.die.net/man/3/glutstrokestring
How about this?
#include <openglut.h>
glutStrokeString(GLUT_STROKE_ROMAN, "I will draw this string at the origin of the model");
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
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).