Cannot print from wine (Microsoft Office Word Viewer)

Martin,
the Linux program Wine does not hold ALL the Windows programs to run in Linux.

This is because of the fact that many of the so-named "people" want to gain money from knowledge.
So windows-developers-ass-givens-for-money do not want anybody to know what they know. They hide the drivers, to say. Why? - Errrr ... to get money from you because you didn't pay to MS for it's windows'es and to punish you you are not with them to pay them money for almost nothing...

And the real people spread the knowledge to everyone who can take it.

So look for "winehq" site to find which Windows programs could probably run in Linux under Wine.

I'm sorry but this is the truth.

And let's go practical - open your Windows word files with Linux program like Gedit, OpenOffice and so on and print it under Linux.
If you don't know how to do it just ask one more time.

Thanks for your reply. However, I am pretty sure Wine is supposed to be able to use CUPS printer. I you take a look at winehq in the documentation you'll se this (http://www.winehq.org/docs/wineusr-guide/misc-things-to-configure#AEN429):

3.3.4. Printers

Wine can interact directly with the local CUPS printing system to find the printers available on your system. Configuring printers with Wine is as simple as making sure your CUPS configuration works. Wine still needs the command lpr(from CUPS), when printing a Document.

If you do not use CUPS, the old BSD-Printing system is used:

    * All Printers from /etc/printcap are installed automatically in Wine.
    * Wine needs a PPD-File for every Printer (generic.ppd comes with Wine)
    * The command lpr is called when printing a Document

But I do get an error when I press the print button, which is why I posted here.

If you're courious to why I want to be able to print from Word Viewer, read this: http://www.andrewcullison.com/2008/10/openoffice-30-notes-feature-printing-notes/

Cheers,
Martin

HI :)

If you could post into that persons blog to ask them then i'm sure they might be able to help. It looks like we are a bit stumped for the moment!

Good luck and regards from
Tom :)

All that I know Wine is supposed to transfer Windows programs to work in Linux.
Supposed but not sured.
Because of the meaning of my ugly but true words up here.

Thanks Vihar, but you don't really answer my question. Anyone else? I have not got any comments from the blog.

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Hi :)

Have you been able to try the new Ubuntu 10.04 before it gets officially released?
http://www.ubuntulinux.org/testing/lucid/beta2
Trying it as a LiveCd or as an extra dual/multi-boot would be ideal. Developers and everyone are keen to try to iron out any problems before 10.04 gets officially released so you might find faster & more effective answers to your bug reports which would make 10.04 work better on your system for you

Thanks and regards from
Tom :)

RE: cannot print (http://appdb.winehq.org/objectManager.php?sClass=version&iId=4992)
by Harley T. Davis on Thursday September 13th 2012, 13:25
Method 1: Wine is a wrapper. Take a usb printer and plug it in... ...no go. But, create a pathway to a COM output file, and have your system (linux) process it as a stream to the usb print stream... ...and you're good to go. The printing has to be handled by your system, even though you can set most of the parameters for the print in the normal winX dialogue (it will all go to the COM data file). Make sure to have your system delete the COM data file when the print is finished. This may require you to have an extra queue for that printer; that way you can set your system to use that queue for wine print, and have it delete the associated COM file after every print job is finished. The downside... ...only one print job can be processed at a time through wine, or you can set the delete to happen when you clear the queue in wine... etc etc... ...You can output multiple docs to one output file, but all will be printed again and again until the whole file is deleted. If you can set up a way to number COM data files, you can program your wine wrapper to check against a value, then number the files, and delete them when finished. When you do, please submit the algorithm you use... ...I'm sure they'd love to code it into wine.
Method 2 (not surefire, but possible):
Wine under most systems will utilize networks and ip addresses. Get a network printer, and you might be able to load a network driver to your WINE... ...This includes wireless drivers as they just package the data for wireless connections, but actually use the same basic programming underneath as the hardwired connections. You will have to have your printer already set up on your network, but it's a possiblity... This will send data over your network in packet formats that match windows, and are printed as if from windows, provided that the driver uses extremely compatible code. I'll make attempts with this soon and get back to you, but for now, I urge you to try this yourself. The networking does not use com port streams, but it does use network streams to carry formatted packets in two directions... An interesting prospect.
Method 3:
Install a compatible PDF print function. Print to pdf in wine, then print that from your main system. You can probably program a folder to accept the PDF, then automatically print it, save to a backup folder and delete the original. Then have the backup folder delete any files older than a day or two. This allows you to get around printer problems. If you have multiple printers, you can set up multiple folders this way and simply select the folder that matches your chosen printer. You can then use drag\drop to reprint a doc, or open and print it manually when there is an error in the first run, etc.

by Harley T. Davis on Thursday September 13th 2012, 14:51
Wine does not send usb data to printers, but to output files. You need to have your system set up to stream that data to the printers. USB of your system and COM data from WINE should be compatible streams, just read the data-file as a stream out to the printer (ps. In most programming techniques, files are Streams from the hard drive; you have to pour that stream into a COM data stream to make it COM again, then output the COM stream to a USB stream to the printer). Read my reply to the other person, and you might get a few ideas. You might also try sharing printers from a windows machine... This might work across the network because the queue and stream are not on your computer, but in a separate location. It is all handled by streaming the output to the other computer and letting that computer process the actual print job. Upside: I've had this work with only one printer and it was really old (used COM command structures in the driver natively, even though a usb connection). You might still get away with it on others.
Downside: you need a windows comp to handle the output.
Experimental:
Try a print server that has a queue of it's own... ...connected by network. This will pass the data over the network and into a queue, much the same as using another comp that is native windows. The print server processes the queue. Unfortunately, using a driver program built by the printer manufacturer for windows is sketchy at best. You may try this, but I recommend using a generic driver in windows that matches the print language your printer uses (PCL, PDL, PostScript etc). Most PCL6 printers can use PCL5, the generic. PDL or KPDL are less generic and can usually be overridden by PostScript drivers (the copy machines that tend to use PDL also have a PostScript or PCL language they can fall back on internally at the printer), so PostScript generic drivers are best for this situation.

I hope this information is helpful to you. I get the feeling you're not the programmer type, or even the design type (programming logic), and that's just fine with me. I applaud your question, even though the WineHQ has it in their FAQ pages that usb printing support is not contained in wine (neither is USB support in general; the commands in windows would have to be output to a library in your distro that complies with the GPL (licensing), and most systems have that library protected under their own license, making it difficult to utilize except on a purely UNIX system (not just Unix-like; EG, Linux, Mac, etc)) You wanted to understand, and you asked. The answer is much more complex than you might imagine, and I'll lay out what I've found below. The simplest form of the answer is that USB is not supported in WINE due to the fact that wine does not emulate a machine or hardware. It's a redirection engine. It takes the calls for folders and files and points them to the files in the Wrapper that match. Many of these files are not the actual windows component, but an open source copy that works in your unix, and actually allows your system to pick up the slack or missing pieces. Some is actually open source code that parallels the third party drivers. USB streams have to be tied to one machine (it's an enumerated port and that number is machine specific). Network streams are not so unforgiving. Mice are handled by number values taken from the system, not from a usb port, when in wine. Network streams are handled using uniform formatting and can be easily passed from place to place using the streams from your system as if they are only a proxy. But USB is both system and machine specific, and needs 2way communication for native usb stream calls. It can process and carry COM data, which is one way, but the underlying connection between the two streams must be handle by your OS, or programmed specifically. Since wine sends out COM data, and your USB is handled by your Linux, you'd need to create a connection between the WINE COM port stream and your USB on your own, for each driver on your system. Not easy to do, and it varies between systems so much that it's not practical to try to program it into WINE.
If you want to get a better understanding, keep reading.

X window systems using the X.ORG server components do have some port component architecture, but these pull their data from your active system, then put that in their own streams, for a multitude of reasons. USB support will probably not appear in Wine for similar reasons... ...the main one being that a usb device is tied to a single system at a time. In print servers, the print server is the single system. Other devices work differently with different command structures and streams. The data from them is captured and processed. The captured data (in the system memory, not in usb port) is then hijacked by the X.ORG server, and the X window processes the numbers (like what happens with mice and track pointer equipment). With wine, your main system is that single system that USB gets tied to, and wine can only pour it's print data into output streams that go to files because the usb device is already linked to your OS (which it must be in order to activate the USB stream operations; and WINE doesn't hijack any streams for windows ops, it just has its own streams); the OS can carry an interface to capture the data and send to printers, but you must have that programmed specifically for your system, and one set for each printer, complete with a queue function to delete the stream from wine and your system when finished. X.ORG is a great way to do this, and using Wine based on this package really does make life easier. It takes your default printer and allows you to print to that device from X.ORG streams, but there is only a generic driver language, and it calls your system to make the print with very little previewing support. You can switch between printers by changing the default printer in your main system, Easy peasy, but that printer really needs to support the CUPS system or PostScript. Besides, emulators are often more effective with certain types of printing.
Emulators often allow you to hijack a USB or other stream from the system, so you can run that stream in another OS by pouring output from the GuestOS (like windows in your case) into that stream directly. It's all binary stream data, so one OS is as good as another when it comes time for the device and system to chat. Any calls between the device and the system are processed through the emulator mechanism for that stream set (that particular port is "given" to the emulator, making that port belong the the emulated, or "fake" machine). WINE= wine is not an emulator. No stream hijacking, but it can create streams that go through some ports like networking ports using the redirection built into its code... ...those are piped packets that are tagged and carried between systems that check the tags, then process the data for that tag. Remember, the data goes through the output module in wine as a network stream, then gets output by your systems network streams, which still belong to your system... The tagging and data are sent in repeating binary packets that are then sent on to the device at the other end and decoded. With mice, only numbers from the system are used, not the direct interface to the mouse. Networking streams do have an open source license and are pretty uniform across systems for the interface, so using them is easier. USB is a protected component, and thus, there is a lot less they can do with it. COM is open code too, and can be processed over usb, but you do have to write the interface yourself, mainly because you have to create the stream and point it to your particular device yourself.

Thus, in wine, you might get away with sharing a printer from a print server or other computer with windows running because the data is sent over networking ports and tagged for use by a printer. The driver is then used by Wine for formatting the image in the printer's language, and not for the actual connection, Queue or Stream. The data is sent over a network stream and poured into the queue, then streamed out by the computer running windows or print server. I have had this work only once (only tried it with an old hp laser connected to a win comp), but it worked when the laser was connected by COM port (long connector) or USB (system just uses COM formatted streams because that's all the printer can read).
If you have better luck with newer printers, please note it here by type (ink, infrared, laser) and connection (shared from comp or print server, usb, comport, networked, wireless, etc).

update :: could be interesting

http://appdb.winehq.org/commentview.php?iAppId=31&iVersionId=4992&iThreadId=79606

http://appdb.winehq.org/commentview.php?iAppId=31&iVersionId=4992&iThreadId=78407

http://appdb.winehq.org/commentview.php?iAppId=31&iVersionId=4992&iThreadId=79719