I would think it would matter on the architecture of MobilePrint. I think that's x32 so I would think the x32 Office would suffice.
Can someone from Pharos confirm?
Sent from my BlackBerry Z30
From: Gerald Rezes
Sent: Tuesday, March 11, 2014 9:36 PM
To: Grzeczka, Timothy J
Subject: - MobilePrint Office x32 or x64 bit?
Pharos Community <http://community.pharos.com/?et=watches.email.thread>
MobilePrint Office x32 or x64 bit?
created by Gerald Rezes<http://community.pharos.com/people/grezes%40llu.edu?et=watches.email.thread> in MobilePrint (Customers and Partners Only) - View the full discussion<http://community.pharos.com/message/2738?et=watches.email.thread#2738>
I am aware that Publisher is not supported unless it has been installed on the MP worker servers, but other than that I believe that you may find that most of the printing that users are doing will not encounter these issue, if you do (or have), then by all means install it. I have left the decision regarding which version and platform of office up to my end users and I think most or all have used the 32-bit version of Office regardless of the OS platform. I posted the section of the guide you referenced below. No longer requiring a Microsoft Office license was a "feature" introduced in version 1.3.1. My recollection is that if Office is installed on the system, MobilePrint will use it instead of its internal MS dll's for document conversion. All of this to say, you may find that you do not need to install Office on your server, but if you do, the 32-bit version should work just fine if I recall correctly.
From the 18.104.22.168404 Advanced Configuration Guide
Out of the box, MobilePrint works without Microsoft® Office and most documents will print exactly as the user would expect. Some complex documents created with MS Office specific tools or functions may not. If you find that this is an issue, consider installing Microsoft Office on the MobilePrint Worker Server (server on which MobilePrint Worker Service is installed). If Microsoft Office is installed, MobilePrint will use it to render documents and an even higher level of print quality and document fidelity can be achieved.
Note: If you decide to install Microsoft Office to handle complex documents, please note of the following:
- MobilePrint supports the following Microsoft Office versions
- Microsoft Office 2007
- Microsoft 2010
- If installing Office 2007, install the Microsoft “Save as PDF Add-in”. This converts Microsoft Office documents to PDF. You can download this add-in from: http://www.microsoft.com/en-us/download/details.aspx?id=7. Office 2010 natively supports converting documents to PDF format.
- Make sure that the Microsoft® Office installed on your MobilePrint Server conforms to your licensing agreement with Microsoft. It is your responsibility to ensure that Microsoft® Office is appropriately licensed for this use.
- If your MobilePrint deployment includes multiple Worker Servers, Pharos recommends installing Microsoft® Office on every MobilePrint Worker Server to avoid possible inconsistencies in print quality.
That is good to know regarding Office. If the benefits are so limited in installing Office on the servers, I would suggest making it very clear in the documentation what customers can expect to archive if they install Office on the server; i.e. publisher rendering I guess. Thanks.
- MobilePrint supports the following Microsoft Office versions
Like Steven said, installing Microsoft Office(r) was a requirement prior to MobilePrint 1.3.1. However, in v1.3.1 and above, our software included a more robust conversion library that would handle PowerPoint(r), Word(r), and Excel(r) natively, in addition to the OpenOffice format (introduced in v1.3.2). When is there benefit? It's a short list:
- Support for rendering Microsoft Publisher(r) publications
- Marginal improvements rendering other Office(r) documents, usually in terms of fidelity surrounding LBOs (Lines, Boxes, and Ovals) and some placed images (notably WMF and EMF). I say marginal because when I look at "before/after" Office(r) installation output through my loupe (a 10x magnifier), the difference is very hard to notice, and mostly around gradients and the subtleties around 3D effects. In short, only the Fine Arts people would really get it, and they're probably not using Office(r) for their documents anyway .
What is important to remember about uploading raw documents to a server is this: local resources are generally not included. This means that if you're using the "Star Jedi" font (http://www.dafont.com/star-jedi.font) for the title text in your PowerPoint(r) presentation, it will either:
- Not print
- Print very rough
- Be substituted (with Times New Roman, for example)
because raw documents only include the pointer to fonts in their data, not the font itself. If you wish to preserve font choice and fidelity in your documents, convert to PDF prior to submitting via MobilePrint, ensuring that you are embedding fonts and that the Font Subset setting (if you have one) is set to 99%.
Any word on when Office 2013 will be supported? The campus rolled that out last fall. Any known issues with Mobo converting documents created using Office 2013 and printed via Mobileprint using Office 2010?
Any ideas when Office 2013 will be supported? The campus rolled that out last fall. Any known issues with Mobo converting documents created using Office 2013 and printed via Mobileprint using Office 2010?
Even though the documentation does not show that Outlook 2013 has been tested as a mail client, the document types (docx, xlsx, etc...) indicate overall that Office 2013 is supported. I believe the only issue we have outstanding has something to do with Excel defaulting to the A4 paper size. I would have to look into it again to see where that one stands. On the whole, Office 2013 has not presented any other issues I am aware of.
I was thinking along the same lines, that if the document type was supported, we wouldn't see any major issues.Occasionally we have seen issues with Word doc's that are upgraded to the newer version of Office when saved, i.e., Word .docx created using Office 2010 saved to the desktop on a workstation using Office 2013 and updated by Office 2013. It does warn users that it may change formatting; however, they don't read anything and then freak out when the document doesn't look exactly the same.
The bigger issue with Office 2013 is converting PDF's to Word docx's. We have a plethora of ancient PDF's, some created with versions as old as Adobe Acrobat 2. They usually fail when printing. Print as image works most of the time, or changing language level settings, but when all else failed they could usually convert it to a Word .doc(x) and it would print. Not so much with 2013. Office 2013 doesn't like older PDF's. Ideally CU would have faculty and staff update all their documents to the latest versions (or at least a version from the same decade) prior to uploading them to the D2L website, where they store active documents. They of course want to blame the Pharos software for all the printing issues, when realistically standardization would solve 99% of the problems. One of the many challenges of working in a University environment, but then again I get to wear T-shirts and shorts to work, so it's not all bad.
Just to clarify, the items in the documentation I posted in early March is for supporting Office on your server and using Office for document rendering instead of the built-in dlls that come with MobilePrint. My comment immediately above regarding not running into any problems is in reference to using the built-in dll files for rendering Office 2013 documents. I am not sure if/when official support for installing Office 2013 for rendering may come. I think that Publisher would really be the only potentially common complaint is Publisher 2013 files will not render correctly on Publisher 2010 (all of this presuming that Office 2013 is different enough that it does not work despite the lack of official support).