Tim Sneath - Inside Windows Vista Printing

Seeing all these wonderful and spectacular features in Windows Vista makes Windows XP seem just that much worse. There were many limitations I didn't know about. I can't wait for beta 2 of Windows Vista, perhaps then it will be a workable main OS. Overall the improvements made sound wonderful!

I've never been so excited about someone talking about printing
PS: love the line "so buying windows vista will make your printing better". how many product teams can say that without asking developers to use a new API

When can we expect to see a "blank page" filter? And perhaps a large print job/duplicate pages print job warning so administrators can stop uses wasting paper?

Is it safe to say that XPS is a subset of the WPF (sans animations & stuff) expressed via XML w/ a few paper-specific stuff? Say, the markup for "Hello world" would be identical in XAML and XPS?

or to put it another way, XPS is just the WPF states frozen in time?

this seems a lot like what postscript can do to me.  you can do just about anything in postscript, including things you wouldn't expect a printer to do like raytracing.

postscript (for those who don't know) is a document description language, and it is a superset of PDF.  (PDF is postscript where all the processing is already done)

I've been very pro-microsoft lately but this seems like a reinvention of the wheel.

Now... I haven't watched the video - so this may be a feature already; but when are we going to be able to set the printing system to print the pages in reverse order? Printers (like most inkjets) which dump the pages face up on top of each other always need someone to go through the pages and reverse the order... can't the printing system just reverse the page order already?

Oh, and if that's a feature already I apologise... and if not I want 5%.

 With the filter pipeline in XPS drivers however it would become simpler to do this for any application from inside the driver.

Reversing page order is something the application has to do at the moment.

However, the downside from reversing page order in the driver is that the printer doesn't receive anything until the last page has been spooled.

A better (mechanical) solution is a smarter design of the output tray.

Peter

Ps. Nice to see the people we met at DevCon. Special thanks go to John for showing us the way to the Irish pub in Seattle

LarryOsterman wrote:

Andrew Webber FX wrote: I've never been so excited about someone talking about printing PS: love the line "so buying windows vista will make your printing better". how many product teams can say that without asking developers to use a new API

/me raises hand

It's interesting.  The thing that surprises me is that there's no XPS logo program.

So I'm in CompUSA looking at a wall full of printers.  Some of them will print unbelievably cool documents because they support XPS natively.  Others don't do nearly as well because they don't support XPS.

But I (the customer) have absolutely no way of differentiating between the two printers, because there's no logo program.

That seems "surprising" to me.

I have to completly agree, i mean imagine going out to buy a new TV for my xbox360 and feeling gutted when my new $1000 purchase doesnt support HD [C]

 

"It's interesting.  The thing that surprises me is that there's no XPS logo program."

Glad to hear you like it enough to make a purchasing decision based on it!  While there is no specific XPS logo program, we have incorporated XPS and some related technologies like PrintTickets into the Designed for Windows logo program.  We also intend to provide a conformance suite so that purchasers can determine whether the printer implementation is correct. 

Hardware manufacturers can make the determination as to how much marketing they want to put around the XPS features.  The output quality is clear to the untrained eye, so overt advertising of the capabilities might be a natural path for the IHV. 

Vicki

Yes, the XPS markup is a subset of WPF XAML, with only the things needed to put marks on an electronic piece of paper preserved.

- Andy
http://blogs.msdn.com/andy_simonds

That's an application and/or driver feature.  The print subsystem supports it. 

Vicki

This was one of the most fascinating videos I've seen lately. Especially the last part, about the Windows Color System. I learned a lot. Keep up the good work.

So will we have this feature in all of windows and any app that comes with it, or will dev's need to integrate it.

Will this also be part of "Metro"?

I want to quit printing with my Mac...Boooooo!

Metro was the codename of XPS print path.

As a developer you would need to support 'Avalon' XAML.
As a printer driver developer you would either 'enhance' your existing printer driver with the XML based DeviceCapabilities and PrintTicket API's, or build a XAML printer driver from the ground up.

As a user with an Okidata color laser printer (C5150N) what does this mean for me?  Do I have to wait for Okidata to come up with a new driver?  Is it time to start pestering their tech support?

Will Vista ship with any XPS drivers out of the box?


Thanks!

The printer would need a new interpreter for XPS.
However, the print path in Vista should also have optimized conversions to Postscript/PCL, probably in the GDI to EMF conversion area, so you should get better print-out. I wonder however if this will be a Vista-only feature for older drivers... (they are backporting the new print-path to XP/2003, but also these optimalisations?)

Vista would ship XPS drivers out of the box for printers that are going to be released/updated around the time of Vista release, but that's up to the printer manufacturer. In the corporate market customers generally update the printer drivers with the latest ones from the manufacturer. In the consumer market it helps to have a printer working out-of-the-box. Depending on the consumer's technical skills they could still decide to update to the ones from the manufacturer CD/website/windows update.

There are restrictions on the size of the drivers you may inbox in Windows, and you need to share source code, so that Microsoft can also compile your driver against the latest driver development kit at any time and do regression tests.

Peter

Wow, cool video. I particularly enjoyed the last segment regarding color spaces. Good stuff.

This stuff looks cool.

A question on the DRM and Digital Signature.

As a developer of a web based finanicals application two things we constantly get requests for...

1. Users want a direct to printer experience. The feeling is since the checks are printed and renedered to PDF on the server and send to the client, these PDFs can be saved and they are unsecure.

2. Users want a secure way to generate a "wet signature" on the check. Basically we are using Sig Cartaridge with a sig font on it. Some what better but still not 100% secure.

Will XPS solve these problems?

Can a MIME Type be set up so that a check run generated on the web server will be sent directly to the users printer? Or something?

Is there anyway an XPS document can be protected so that only a certain person, perhaps a person with that card you showed would be able to print the doc? It seemed that you demonstrated the reverse where the scanned doc would be digitally signed by the smart card?

Thanks,
BOb

I think you confuse two things:
One thing is the ability to print a document. This is something that PDF also has, not allowing printing. With XPS you can allow only certain people to print.

Second is the ability to send an encrypted job to the printer. The printer should then show a dialog prompting the user to authenticate. This is something that is currently implemented by many printer manufacturers, and is done in the printer driver.

My guess is that the first scenario is handled by the XPS viewer.
The second scenario should be handled by the printer, as with XPS encryption/authentication isn't a driver feature anymore.

My 2 cts
Good luck with your application. If I were you I would contact several printer manufacturers and ask if they could support your use case.

The thing I'm most hyped about with XPS is that (according to this video) spooler size is much smaller than it use to be (approx 1/5th).

Perhaps the companies I work at never have enough printer memory, or this is a hardware issue, but I've found color laser printing to be extremely slow, even when working in reasonable DPI (ex: I often use 300dpi in Photoshop, which in laser terms is considered very low) and printing a 5"x5" image can take up to 5 minutes while the printer spools!!!!

Although the spool file reduction would more benefit vector graphics applications I've also got curious about the Windows Media image compression file format from reading the XPS spec. I wonder what the compression/quality factors are and if it will also become pitched as a gif/jpg replacement just like png.

"...this seems like a reinvention of the wheel."

Reinvention for the sake of reinvention is fundamentally a bad idea.  Re-engineering the print path was a long-overdue effort, where we revisited a lot of current components to see how we can wring out known problems and insert significant improvements.  Using a subset of WPF in the spool file format was key to improving fidelity and enabling advanced graphic features such as transparencies and gradients.  Resource reuse and ZIP were key to reducing spool file sizes.  Taking into account the limitations with embedding the format in a device enabled us to also create a device consumable PDL.  So, yes, many components were "reinvented".  WPF was a reinvention of GDI and XPS was a reinvention of the EMF spool file format and a PDL (PDLs exist such as PCL and Postscript).  The XPSDrv filter pipeline was a reinvention of the GDI print driver model.  Reinvention is progress.  The key point here is that the customer will realize value through the effort.

Vicki

Andrew Webber FX wrote:

LarryOsterman wrote: Andrew Webber FX wrote: I've never been so excited about someone talking about printing PS: love the line "so buying windows vista will make your printing better". how many product teams can say that without asking developers to use a new API /me raises hand It's interesting.  The thing that surprises me is that there's no XPS logo program. So I'm in CompUSA looking at a wall full of printers.  Some of them will print unbelievably cool documents because they support XPS natively.  Others don't do nearly as well because they don't support XPS. But I (the customer) have absolutely no way of differentiating between the two printers, because there's no logo program. That seems "surprising" to me.

I have to completly agree, i mean imagine going out to buy a new TV for my xbox360 and feeling gutted when my new $1000 purchase doesnt support HD

Wow, you can get a HD screen for $1000 ? That's like way cheap. Well I suppose it depends on what size we're talking about. But over here prices are A LOT higher. I suppose you can thank the masses of buyers in the states for those nice pricetags. Too bad it won't color off here anytime soon though

I am not seeing any performance improvements with XPSDrv driver.

As compared to my legacy drivers(PS3 / PCL6), performance is no way better. For e.g., for a 700 KB MS word document with some graphics and text in it,-

1. My legacy driver renders the data much faster. Some 500 % faster than XPSDrv drivers(that uses MXDWDRV.dll as rendering module)

2. Output file is some 77MB with XPSDrv, 20MB with my PS3 / PCL6 drivers.  One more time, this 77MB is direct output from MXDWDRV.DLL!

So as of now I dont see any improvements but degrades as compared to my regular PS3/ PCL6 drivers.

-Vijay

La traducción automática te puede ayudar a comprender la esencia del texto traducido, pero no es sustituto de un traductor humano profesional