Printing Support?


  • Right now our 1.1 plans do not include printing support. We are evaluating this and this might change. Are there specific printing scenarios you need?

    Program Manager
    This post is provided "as-is"

    Wednesday, May 02, 2007 6:18 PM

All replies

  • Right now our 1.1 plans do not include printing support. We are evaluating this and this might change. Are there specific printing scenarios you need?

    Program Manager
    This post is provided "as-is"

    Wednesday, May 02, 2007 6:18 PM
  • I was just thinking that it might be convenient to be able to print say a Canvas and its contents directly from client side code instead of having to replicate that drawing code server side to generate XPS or PDF to send to the browser. It would also lessen the load on the server having to generate those documents.

    Also, I was hoping we might see a Silverlight based cross platform XPS viewer to replace the rather "heavy" WPF-based Windows only one now available. And if Silverlight could generate and pass that XPS document to such a viewer (or have "XPSView" as a control) all on the client side that would be pretty neat too.



    Thursday, May 03, 2007 7:22 PM
  • Being able to catch a print event and return either say a canvas object or an xaml file could prove invaluable without being to much of a strain on current design plans.

    Chris Craft's Blog

    Saturday, May 19, 2007 8:59 PM
  • I would like to add my vote for printing support.

     In scenarios where you have Silverlight applications (no html controls just a slick Silverlight interface) I can see many situations where printing support would be required. i.e. printing an order confirmation, printing off a report, a logged call reference number, an article etc. Yes you could probably take the content and add it to an aspx page but then you may have to worry about formatting (i.e. how will it look on a Mac compared to IE on Windows etc) which is something we wanted to stop worrying about.

    If I remember correctly Flash had this problem a while back but have now overcome it. I know it may be a little box to some but ticking these boxes (printing support, back button support, history support, search engine friendliness etc) makes it a lot easier to justify it's use (over something like Flash).



    Tuesday, May 22, 2007 7:19 AM
  • I would like to add my vote for printing support.


    Me too. 

    Wednesday, May 30, 2007 2:43 AM
  • I vote for printing support as well. Of course, much like opening and saving files, I would expect users to have to explicitly allow the printing to happen.

    We have a product that allows clients to "print-on-demand" from an XML content repository.

    We are currently limited to the layout and styling that HTML can support because our users will not accept the "heaviness" of PDFs. We are also subject to the various rendering decisions and font availability of different browsers and versions, including different headers and footers, margin sizes, and low-resolution graphics.

    It would be easy to directly produce XPS on our server and send it to Silverlight. If Silverlight had the ability to print, we could produce reliable page layout, fast and high-quality output.

    Tuesday, June 05, 2007 5:20 PM
  • I vote for printing as well. its critical to desktop applications that plan to use silverlight

    Wednesday, June 06, 2007 1:09 PM
  • This is a feature I would like as well, we currently have an application written in flash that we would like to port but are unable to because of the lack of printing support.

    Friday, June 08, 2007 7:10 PM
  • Yes please,

    We are using XAML vector elements for generating maps and floor plans in Silverlight. In this domain printing support is a must. To start with normal printing through the browsers print functionally will do as long as the aspect ratio of the graphics is preserved (this is not the case right now)

    Later on it would be great to be able to control what will be printed through pre/post printing events, also possibilities to contol print scale would be great.




    Wednesday, June 13, 2007 5:00 PM
  • another vote for printing support.

    We would use it to print labels. Since labels use non-standard paper sizes and special (not default) printers it is hard for users to print generated PDFs or print using browser. Ideally we need  to specify page/job information programmatically without any user interaction.



    Monday, July 09, 2007 5:25 PM
  • Prinitng is essential. And may I add SCANNING ?? At least basic TWAIN support would be great. We want to add document managment to our web based solution, that requires printing and scanning Joe
    Thursday, July 12, 2007 9:32 PM
  • Did I got it right? We're talking about making professional applications without printing support? C'mon... In my company we've been using .NET controls hosted in Internet Explorer, printing was available, so we expect to continue in the same manner.

    Of course, printing is not needed if SilverLight is targeting entertainment software, dunno-what-to-do-today software, games, etc...



    Friday, July 13, 2007 5:33 AM
  • Another vote for printingsupport.

    Crossplattform Businessapps with printing would blow away most competitors.
    Without printing there would be only laughing.

    Saturday, July 14, 2007 7:21 AM
  • Another vote for printing support!

    We would love to move our app online and this is our number one barrier.  HTML printing doesn't give us the pagination and header/footer control we require.  Embedding .NET WinForms will work but being able to use Silverlight would make deployment/user access MUCH easier.

    Tuesday, July 24, 2007 9:47 AM
  • I'll vote too. We would like to be able to create an app where we let the user design their own trading card and then be able to print it. We would also love to have a way to store the contents of the canvas to an image. Is this possible?

    Tuesday, July 24, 2007 9:55 AM
  • I don't know why I didn't put my vote in here a lot earlier, but yeah, printing support would be great.  As it is now, I have to use GDI to create an image from the xaml, and then print the image.  Which, by the way Bill, is the only way I know of right now to convert xaml to an image.  It wasn't all that hard for me, but my app isn't using too many different xaml elements, either.

    Tuesday, July 24, 2007 12:11 PM
  • Printing support is very important for enterprise deployments. i vote for it too. One example is Page Turn sample, how a journal viewer is useful without print support
    Tuesday, July 24, 2007 12:26 PM
  • I vote for it too!

    Sunday, September 16, 2007 10:23 PM
  • I vote for it !

    Monday, September 17, 2007 1:25 AM
  • Another vote!

    I would also like to add the ability for the client to send back the current state of the Canvas to be captured by the server, kind of like a screenshot of the current view but sent to the server for processing (logging, export to PDF, generate an image, etc...) 

    Wednesday, September 26, 2007 9:09 AM
  •  Printing would be vital, export to different formats (ie pdf) would be nice. Maybe plugging in with the Reportviewer?

    Wednesday, September 26, 2007 9:58 PM
  • One more vote!

    Friday, October 19, 2007 6:07 AM
  •  I vote for this as well. We are currently using Java for a solution as Flash & Flex would not work for our needs. We also needed the ability to send straight to the printer without a print dialog. This is because we needed to control the number of copies being printed.

    Friday, November 02, 2007 1:56 PM
  • I vote for it !

    Sunday, November 04, 2007 8:58 AM
  • I vote for it too. I am fine with creating Postcript code myself (using XSLT from XAML, or programmatically from DOM)

    Saturday, December 01, 2007 1:24 AM
  • Please add printing support, in my view it is critical for serious applications!


    Wednesday, December 05, 2007 5:12 AM
  • Nah Printing is for wimps  Smile

    Friday, December 07, 2007 8:38 AM
  • Printing has its place.I want it as soon as it can be established.I have more in my brains than some people.And if I am able to print out a hard copy I can put it in a file for later reference and don't have to try and remember.What was it and where was it.A wimp would never be that smart.

    Saturday, December 08, 2007 1:44 AM
  • Yes ! We need the canvas printing ! Big Smile

    Tuesday, December 18, 2007 9:14 AM
  • Printing is a deal-breaker.   Do we really need to vote on this?

    Tuesday, June 03, 2008 12:07 PM
  • Printing is a deal-breaker.   Do we really need to vote on this?

     You are absolutely correct, but they don't otherwise seem to be getting the point. I'm starting to get the feeling they don't care about giving customers what they need. Instead just the features that have no real business value, which I can only assume they feel they do have business value, just not to the real world.

    Tuesday, June 03, 2008 1:20 PM
  • *Gasp*   No printing?  Geesh. Lame.

    I need it TODAY.

    Thursday, June 12, 2008 12:16 PM
  • I vote for it too!

    Monday, July 14, 2008 3:47 AM
  •  I would like to add my vote for Printing.

    Tuesday, July 15, 2008 4:55 AM
  • Vote For Printing. It's very essential for silverlight to support pdf and generate pdf from canvas. 

    Tuesday, July 15, 2008 7:40 AM
  • Votes for printing AND RenderTargetBitmap supprt. These are dealbreakers for several apps we're looking at. Thanks.


    Wednesday, July 30, 2008 12:39 PM
  • I vote of Printing support... control content printing... canvas printing..

    Sunday, August 03, 2008 11:28 AM
  • I vote for printing support to. I have developed a visualization appliaction that works wonders, but doesn't support printing it out on paper. I know this is going to be very important soon and there doesn't seem to be an easy workaround.

    Wednesday, August 20, 2008 5:02 PM
  •  add my vote also ..its really important ....

    Tuesday, September 30, 2008 2:12 AM
  • and mine too...currently i'm working on a web reporting solution using some silverlight controls to render charts, but it's totally useless without a chance to print the canvas. So, to avoid this limitation, i'm moving to flash charting components because Flash supports canvas printing.

    Monday, October 06, 2008 3:56 AM
  • Could me in - I vote for printSupport

    Monday, October 06, 2008 7:42 AM
  •  Does Silverlight 2 RC0 supports this somehow?

     If not, here is my vote... this is a core requirement for us....

    Tuesday, October 07, 2008 6:47 AM
  • I actually askes this in the teleconference with ScottGu (see my transcript) and:

    Printing :
    samples are coming to support bitmap to browser printing command, more advanced features are coming later on. for now its BitmapPrinting though.

    Wednesday, October 15, 2008 3:27 AM
  • Yeah count me on.  Printing is a MUST HAVE.
    GO Microsoft GO

    Of course Printing would be too cool like Printing a CrystalReport kind of report.  I mean You know, with preview etc.  Imagine the user need to print data that he/she received on a grid and would like it to be the way he want it to be,  You know, formated with a nice image in the upper left corner,  with a tittle, with footers etc. ..the kind of normal report you do with Crystal Report

    Anyway.  You see what I mean


    Friday, October 31, 2008 5:43 PM
  • I vote for printing, seems pretty much a given someone would need it.

    Saturday, November 01, 2008 12:15 AM

    I hope print will be add too.
    Friday, November 21, 2008 9:36 PM
  • +1 for printing support.


    Sunday, November 23, 2008 10:11 PM
  • +1 for printing and +1 for XPS Viewer. Thanks.
    Monday, November 24, 2008 4:57 AM
  •  1+ for printing and 1+ for access to audio and video source, as microphone and webcams

    Monday, December 22, 2008 9:44 AM
  •  +1 for printing

    It's not enough if Silverlight control would be printed, when you print page from a browser. It's desired to have full printing API, where you can enumerate printers, get their caps and draw to the printer you choose (output canvas there maybe).

    Wednesday, December 24, 2008 4:16 AM
  •  An update: Just listened to a podcast on DotNetRocks about Silverlight and it looks like Printing support will probably not make it into release 3 of Silverlight Crying

    Since this has been a request for such a long time I would have thought it would be high up on the list of priorities (although I do understand that they can't satisfy all enhancement requests it would have been nice to be able to print off a Silverlight confirmation view).


    Wednesday, December 24, 2008 4:34 AM
  • How has this been an important feature request for so long and it still will not be implemented?  That's very dissapointing.

    Thursday, January 15, 2009 3:49 PM
  • I feel pretty stupid, having developed for quite a long time without checking on something so basic as print support.  Now I find it isn't there?  WTF????? 

    What are people doing to print confirmations, invoices, etc., etc., with any real app?

    For those on the Silverlight team that might response, seriously what are you all thinking leaving out this vital function for real life applications?  This is horribly dissapointing to hear it's not present now AND isn't going to make it into the next release either?  Suckage....


    Saturday, January 24, 2009 4:56 PM
  • +1 for printing support and +1 for easy conversion of xaml to png

    Sharker Khaleed Mahmud

    Sunday, January 25, 2009 3:32 AM
  • This is enough to put my company off using Silverlight for future projects. People need to be able to print text-based information, reports, charts, etc. I simply can't believe Microsoft's attitude towards this for all this time. I guess they don't want Silverlight to be a viable platform for business applications.

    Thursday, January 29, 2009 10:27 AM
  • Likewise our company is looking for our future web UI tool.  I was championing Silverlight and loving it, till I found that it can't do something as simple as printing.

    Who doesn't need to print except maybe game developers?

    I guess Silverlight is for game develolpment only?  (or at least not for real business apps)

    Monday, February 02, 2009 2:40 PM
  • +1 for printing support and +1 for easy conversion of xaml to png

    I want too.

    I want to print runtime Canvas (verctor graphics!)

    Tuesday, February 03, 2009 10:24 AM
  • I need printing too! As quick as possible or I have to use an alternative to silverlight :-/

    Wednesday, February 18, 2009 8:21 AM
  •  I'm voting pro Printing Support +1.

    Wednesday, February 18, 2009 9:04 AM
  • I also vote for printing support or at least a built-in document viewer like WPF.
    Thursday, February 26, 2009 5:11 PM
  • This thread is a joke.

    Could Microsoft SilverLight team at least post something to say about SilverLight 3 implementing printing support ?


    Saturday, February 28, 2009 5:59 PM
  • I hope version 3 supports printing, I started seriously writing LOB applications with silverlight and printing is a must have.

    Sunday, March 01, 2009 11:05 PM
  • What are people doing to print confirmations, invoices, etc., etc., with any real app?

    Well, for us, we're going to deliver PDF documents which the user can then print (or email, or whatever). But our output needs are not XAML/canvas related so we can do that.

    I also vote for printing support. We want to use it in the future to [more] seamlessly generate output directly to a printer (eg. labels).

    Thursday, March 05, 2009 7:37 PM
  • In SL 3.0 you could use writeablebitmap and using the html bridge create a popup print page and inject img tag using the data tag inject yourbitmap stream and run JS window.print()
    Friday, March 20, 2009 5:25 PM
  • Looks nice. But sadly we do not have HTML DOM manipulation and Javascript bridge available when we're running out-of-browser.
    Saturday, March 21, 2009 3:05 AM
  • Hi, Does this mean that SL 3.0 does not have printing support?

    Wednesday, March 25, 2009 9:47 PM
  • That's correct. SL3 currently doesn't have printing support.
    Thursday, March 26, 2009 2:50 AM
  •  me too,.

    Saturday, March 28, 2009 6:22 AM
  • Correct me if I'm wrong, but couldn't you generate a pdf or xps document in code, and then redirect to the resulting file in the browser and volia you have printing support? I realize this doesn't give you drill down etc directly, but with the new deep linking support, it should be possible to do the drill down functionality.

     But yes, printing should be available out of the box.

    Wednesday, April 08, 2009 9:35 AM
  • Yes you can generate a PDF or XPS in code. But you would need to save this file somewhere. You could show a Save File Dialog... But then again how to create a PDF in Silverlight? Maybe iTextSharp can be ported to Silverlight?
    Wednesday, April 08, 2009 2:55 PM
  • I would assume that XPS would be easier to generate since it's a variant of XAML....


    Wednesday, April 08, 2009 3:07 PM
  • To Microsoft on this one:

     I need to be able to have a 3rd party control manufacturer do everything that Crystal/Active/Xtra Reports does. I.e. you need to port the printing stuff that is already in the .net framework to Silverlight.

    Wednesday, April 08, 2009 3:08 PM
  • Never tried XPS, but might be something that can be done.
    Wednesday, April 08, 2009 3:13 PM
  • Hi,

    I've finally managed to implement printing in my Silverlight 2 application. My solution is to extract the XAML from the plugin, post it to the server where an XPS or PDF file is created and finally stream it back to a new browser window. The solution works great for scenarios where the printable content contains only objects known to WPF like Canvas and various Shape objects, UserControls and other 'non-standard' XAML cannot be printed because the server has no idea of how this should be rendered.

    My app is a CAD-style vector graphics viewer where the XAML can be as big as 2 Mb and the solution works just great. I use the XamlWriter from Silverlight Contrib to serialize the XAML, XPS creation on the server is just five lines of code and the PDF-conversion is done with a commercial third-party component (I've tried abcPDF.Net and it seems like a great choice so far).

    The ideal solution would of course be to create the XPS/PDF entirely clientside but for this to happen I guess we have to wait for Silverlight 4 or 5 :-(


    Friday, April 10, 2009 4:05 AM
  • Need native Printing support.

    Monday, April 20, 2009 9:06 AM
  • Essential for business applications. As a minimum would expect XPS support.

    Tuesday, April 21, 2009 8:06 AM
  •  We all do need printing support without it Silverlight application is handicap

    Tuesday, May 12, 2009 1:04 AM
  •  We all do need printing support without it Silverlight application is handicap

    Tuesday, May 12, 2009 1:06 AM
  • I vote for it too.....We really need printing option
    Thursday, May 21, 2009 5:43 AM
  • What option do we have until Silverlight supports printing ?

    Because I have an important customer that whish to have a POS and it needs to print receipts
    Thank you.


    Friday, July 31, 2009 6:06 AM
  •  Two options I see:

    1. Use HTML to launch a new window and use something like XtraReports or Crystal or something to either generate an HTML version, or better yet, generate a PDF.

    2. Generate your report using XAML, display it, and when printing it, send it to an HTML page that generates an XPS from the XAML.

    Either way is non-optimal. #2 has the benefit of allowing you to be fully interactive, and it *can* be easier to create really rich reports. In theory it could be customizable as well unlike most HTML based report generators that can't allow you to customize reports etc.

     Short version, this is a PITA no matter how you go right now.

    Friday, July 31, 2009 8:27 AM
  •  I just can't understand why printing support is not yet available, Developers are asking for printing support since 2007 and I don't see a commitment from Microsoft on when We will have printing support available.

    I can't beleive why the director of Silverlight can't assign a resource to this matter, it should take 2 month to develop this functionality if the guy is a slow developer.

    I mean, We are not asking microsoft to build a rocket, just printing support, Have you seen a LOB without printing support, Microsoft can't just involve everyone on a new technology and don't give the basic tools, ups He did, how unrespectful.

    Please don't say: don't use silverlight.

     This is a wonderful framework never seen before.

    Sorry for my english, it's not my native language.

    Friday, July 31, 2009 1:41 PM
  •  First before they can call this a Line of Business application they have to give us a working way to actually get data. Right now you can't, or if you use DataServices you're going to be pulling huge amounts of data and generate a clunker of an application because every query you do is a select *. RIA doesn't work with most databases not of trivial complexity and that won't be solved until .NET 4.0 is released because of bugs in the way Entity Framework was implimented (that thing wasn't ready for prime time for sure!) and still doesn't support doing simple linq queries that return a new anonymous array.

     Until this stuff is working, the point about printing is moot because you can't even get data to print anyhow.

    My suggestion to MS is to get someone to drive LOB and build real applications using real methodologies so that those of us building WinForms finally have something that we can switch to first. Get the data scenarios working and native and fully functional with partity with Linq To Entities at the very least, and then worry about the rest (RIA is a whole lot of code for nothing, I just need dataservices that allow me to intercept and add security conditions and can return anonymous typeed arrays of values so that I don't have to be doing Select * all of the time.)

     Once that's done, then fix printing, and a bunch of other things that make it difficult but not impossible to work with. Right now you can't build a convincing data scenario with this thing so unless you're building video games, there's no point to it, and if you're going to be building games, then use flash cause everyone has it already.

    Friday, July 31, 2009 1:49 PM
  •  Hi John I like your point of view, I think Microsoft could give us printing support right now, for most of us the current CRUD support through RIA is enough.

    Friday, July 31, 2009 1:59 PM
  •  I pitty your users while they wait for your screens to load...

    Friday, July 31, 2009 2:08 PM
  •  John with all respect, please don't change the main topic on this thread, If you need to talk about data, open another thread.

    Friday, July 31, 2009 2:20 PM
  •  My comments about data are directly related to printing.

     If you wanted to print something, you would have to get your data. You'd need specific fields from multiple different tables for almost any report you can conceive of in a LOB application. To do so you would right now have to do a Select * on all tables for all intents in purposes which would cripple your application, thus to print, we need functionality that doesn't exist and apparently isn't even on the radar even though until it's there Silverlight is useless for these scenarios.

     At least you can shell out to HTML and generate it by doing direct SQL calls I guess, but you can't even do that in Silverlight with data and the alternatives are all busted so before you can print this has to be solved no matter how you go about it.

    Friday, July 31, 2009 2:28 PM
  • um, what? Printing isn't just for large reports. I have a confirmation page I'd like the user to be able to print, for example, in our upcoming cruise application. Today I can't do that, I have to work around it and do it using a completely different set of technologies and user experience. It. Sucks. There is NO reason why printing support can't be in Silverlight, it just was NOT a priority for the team and someone in the leadership group DECIDED to exclude it. It's really as simple as that from my POV.
    Friday, July 31, 2009 2:49 PM
  •  Even a simple invoice will require at least:


    Invoice Details

    Products (Items)

    Company Information

    Payment Terms

    etc. etc. etc.


    With the current data methodology you're going to have to do a select * on all of those tables to get the information you need. The overhead for that is enormous.

     With Linq to Entities or TSQL you can pick what you want and it only queries for that information, and just as importantly, only returns that information.

    With Dynamic Data or RIA Services, you can't. Thus you get a HUGE amount of data queried for in the database, which creates huge overhead on your database server, thus killing any ability to scale AND you send a HUGE amount of data over the wire.

    All for a couple of K of text that you really wanted.

    Hence even in the most basic scenario of reporting your application can't scale, kills server performance, and will be slow as hell just generating the report, even if you could print it. (which you can't)

    Hence for any SERIOUS LOB application Silverlight is still completely useless regardless of printing requirements, but especially with printing requirements which demonstrate the need very very clearly.

    But at least with printing, you can use an HTML request in the backend to use a tool like XtraReports or Crystal to generate a PDF and display it in a popup browser window, which the user will likely not ever notice isn't directly a part of your silverlight application....

    But first you have to get the data to your silverlight application, which they still haven't addressed.

    Saturday, August 01, 2009 9:58 AM
  • i really have zero clue what you are talking about.  our Silverlight application utilizes WCF services which hit our SQL Server behind the scenes with LINQ to SQL, we have middle tier logic that deals with those results, and streams back to the Silverlight application data it needs {we have over 30 services that are consumed by the SL app}.  There is no "HUGE amount of data over the wire" at all, don't know where you get that idea from.  We send back what the application needs, and those responses are generally in the 10s to low 100s of k in the worst case scenario. In the scenario that i need printing support, the only data transferred back to the SL app is a booking number, terms and conditions of carriage and contact information for the end-user to call support for their bookings.

    the entire SL application with this approach is very responsive and very scalable.  

    your "first you have to get the data to your silverlight application , which they still haven't addressed" comment doesn't match our experience with the technology at all.

    Saturday, August 01, 2009 10:44 AM
  • haha

    I'm laughing about this Data thing the guy is talking about.  Printing is not a problem at all even with large data since this is working the same way it is with DataGrid right now and using WCF you get all the data you need for your report.

    Please do as people said.  If you need to talk about Data start another thread because this has nothing to do with the request we do here which is supporting printing directly from Silverlight like a receipt or a CrystalReport or whatever they'll call it.


    Saturday, August 01, 2009 4:04 PM
  • I vote for printing as well.

    Wednesday, August 05, 2009 5:44 AM
  • doy un voto a favor para que se incluya la impresión, exportación y guardar dentro de silverlight a diferentes formatos (pdf, excel, word...). Saludos a todos.
    Monday, August 24, 2009 2:09 PM
  • Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin-top:0in; mso-para-margin-right:0in; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}

    Monday, January 11, 2010 3:00 AM
  • Could anyone please update me on the latest re printing support?

     We had planned to use Silverlight to deliver more sophisticated applications to browsers, with the apps picking up data direct from webservices and displaying the results graphically (financial analysis charts etc). Being able to print these charts immediately from the browser is essential. I was very suprised using our prototype that, when clicking on "print preview" in IExplorer, I just got two blank pages. Are you serious that Silverlight cannot support such a basic requirement straight out of the box?



    Tuesday, May 25, 2010 4:21 AM
  • We also needed the ability to send straight to the printer without a print dialog. This is because we needed to control the number of copies being printed.

    In specific scenarios, you could achieve the direct printing to the default printer with Silverlight 4:

    Monday, July 11, 2011 4:55 AM