Welcome to NeoOffice developer notes and announcements
NeoOffice
Developer notes and announcements
 
 

This website is an archive and is no longer active
NeoOffice announcements have moved to the NeoOffice News website


Support
· Forums
· NeoOffice Support
· NeoWiki


Announcements
· Twitter @NeoOffice


Downloads
· Download NeoOffice


  
NeoOffice :: View topic - iPad printing via PrintCentral/WePrint
iPad printing via PrintCentral/WePrint
 
   NeoOffice Forum Index -> NeoOffice Releases
View previous topic :: View next topic  
Author Message
dethell
Blue Pill


Joined: Jun 24, 2010
Posts: 3

PostPosted: Thu Jun 24, 2010 4:23 am    Post subject: iPad printing via PrintCentral/WePrint

I am trying to print XLS and ODT files from my iPad using the PrintCentral app. PrintCentral uses a Helper app installed on my MBP called WePrint. Unfortunately, NeoOffice does not work properly when WePrint tries to tell it to print documents. According to the support staff for PrintCentral:

Quote:
WePrint will use your default Excel file application to print Excel documents. There is a setting in Excel to open the new document wizard at startup that gets in the way of printing. To turn off that setting go to the Excel menu -> Preferences, click on general and then uncheck "Show Project Gallery at Startup"


And then they responded when I mentioned I didn't have Excel but used NeoOffice:

Quote:
NeoOffice probably doesn't support the standard system print command then.


Do you have any idea if they are correct? What happens right now if I tell the WePrint server program to use NeoOffice to print XLS or ODS files NeoOffice just opens the document and does not print it. Their support did mention that OpenOffice for Mac should work so I assume that means NeoOffice should as well.

I realize this is slightly out of scope, perhaps, but I wanted to see what you thought.

David
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Thu Jun 24, 2010 9:03 am    Post subject: Re: iPad printing via PrintCentral/WePrint

dethell wrote:
Do you have any idea if they are correct? What happens right now if I tell the WePrint server program to use NeoOffice to print XLS or ODS files NeoOffice just opens the document and does not print it. Their support did mention that OpenOffice for Mac should work so I assume that means NeoOffice should as well.


I think that they are correct. I just tested sending a print command to OpenOffice.org 3.1.1 (the version that NeoOffice 3.1.1 is based on) by opening the print queue for my printer in the System Preference's Print & FAX panel. Then I dragged an .odt file onto the print queue icon in the Dock and OpenOffice.org displayed its native print dialog.

So I think that this is a bug in our code. Somewhere in NeoOffice we are failing to convert the native print command to the matching OpenOffice.org print command. I will investigate this bug and I will post again when I have some news to report.

Patrick
Back to top
narf
The Anomaly


Joined: Jan 21, 2007
Posts: 1075

PostPosted: Thu Jun 24, 2010 9:21 am    Post subject:

I have created bug 3614 to track this issue.

Fran
Back to top
sardisson
Town Crier
Town Crier


Joined: Feb 01, 2004
Posts: 4588

PostPosted: Thu Jun 24, 2010 11:23 am    Post subject:

Patrick, if you haven't already seen it, this describes what methods AppKit looks for when passing off the print/'pdoc' AppleEvent to the application's own code.

My guess (without inspecting the NeoOffice codebase Wink ) is you'd need to implement one of those methods and have it call the OOo printing code.

Smokey

_________________
"[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Thu Jun 24, 2010 11:51 am    Post subject:

Smokey,

sardisson wrote:
My guess (without inspecting the NeoOffice codebase Wink ) is you'd need to implement one of those methods and have it call the OOo printing code.


I thought I made it clear in my post that I have implemented the proper native event handlers and that the problem is in the code that translates the native event to the matching internal OpenOffice.org code.

Patrick
Back to top
sardisson
Town Crier
Town Crier


Joined: Feb 01, 2004
Posts: 4588

PostPosted: Thu Jun 24, 2010 1:00 pm    Post subject:

pluby wrote:
I thought I made it clear in my post that I have implemented the proper native event handlers and that the problem is in the code that translates the native event to the matching internal OpenOffice.org code.

I suppose "failing to convert the native print command" could be understood as either "the existing code to handle the 'pdoc' event isn't talking to the OOo print code correctly" or "there's no code to handle the 'pdoc' event and call the OOo print code"; to me it sounded like the latter, not the former Wink Anyway, I'll let you get back to debugging the former Smile

Smokey

_________________
"[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Thu Jun 24, 2010 1:50 pm    Post subject:

I think that I fixed this bug. A minor typo in my C++ code was causing NeoOffice to use our "open document" code to be executed when NeoOffice received a native "print document" event. In addition, since OpenOffice.org will hide the document that it is printing, I have implemented displaying the print dialog in its own modal dialog if there are no documents visible in NeoOffice.

Can you install the following test patch and tell us if NeoOffice now properly responds to native print events?:

Intel:
http://joe.neooffice.org/test/NeoOffice-3.1.1-Patch-1-Test-7-Intel.dmg

PowerPC:
http://joe.neooffice.org/test/NeoOffice-3.1.1-Patch-1-Test-7-PowerPC.dmg

Patrick
Back to top
dethell
Blue Pill


Joined: Jun 24, 2010
Posts: 3

PostPosted: Thu Jun 24, 2010 7:26 pm    Post subject:

It's better than it was in that now it correctly tries to print the document, but there are some issues resulting:

1) It opens the print dialog rather than just printing the document. I believe the standard behavior for the print command from outside the app is to print it without interaction from the user. This is especially important in my scenario since I'm on the iPad and not in front of the machine to handle the dialog box.

2) It has odd behavior for XLS files compared to ODS. In both cases it shows the print dialog. In the case of my XLS file when I click Preview nothing ever gets sent to the Preview app (save to PDF is the same). When I do the same for the ODS file it properly previews/prints/PDFs the file. Not sure why it would be different for XLS than for ODS.

Thanks for such quick turnaround on this bug. This whole issue is just a perfect example of why OpenOffice on the Mac is just not enough and why NeoOffice is necessary for dealing with native behavior like this. Keep up the great work!
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Thu Jun 24, 2010 7:52 pm    Post subject:

dethell wrote:
1) It opens the print dialog rather than just printing the document. I believe the standard behavior for the print command from outside the app is to print it without interaction from the user. This is especially important in my scenario since I'm on the iPad and not in front of the machine to handle the dialog box.


Unfortunately, that is not feasible within NeoOffice. Due to the way that printing is implemented within NeoOffice, you will always see the print dialog appear no matter where the request to print originates from. Not that this helps you, but this is the same behavior that you see in Microsoft Office 2008.

dethell wrote:
2) It has odd behavior for XLS files compared to ODS. In both cases it shows the print dialog. In the case of my XLS file when I click Preview nothing ever gets sent to the Preview app (save to PDF is the same). When I do the same for the ODS file it properly previews/prints/PDFs the file. Not sure why it would be different for XLS than for ODS.


I have bad news: it appears that OpenOffice.org 3.1.1 cannot print even a simple .xls fils when such files are opened using the native print command. In the case of NeoOffice, we start the print job but the underlying OpenOffice.org 3.1.1 Calc code prints nothing. In OpenOffice.org 3.1.1 and 3.2.1, it is even worse in that the print dialog does not appear at all.

So, from what I can tell, NeoOffice's underlying OpenOffice.org code only supports printing of .odt, .ods, .odp, etc. files using the native print command.

Patrick
Back to top
dethell
Blue Pill


Joined: Jun 24, 2010
Posts: 3

PostPosted: Fri Jun 25, 2010 2:08 am    Post subject:

Well, at least I'm seeing the coded behavior and not something crazy. I appreciate your efforts in looking into this.

Here's a final question. Is there a way to tell NeoOffice to convert a document (odt or ods or xls) to convert to PDF without any dialog? I'm just wondering if that could be accomplished I might be able to get the doc to PDF first and then have Preview.app print the PDF without a dialog.
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Fri Jun 25, 2010 8:57 am    Post subject:

dethell wrote:
Here's a final question. Is there a way to tell NeoOffice to convert a document (odt or ods or xls) to convert to PDF without any dialog? I'm just wondering if that could be accomplished I might be able to get the doc to PDF first and then have Preview.app print the PDF without a dialog.


In theory, that is possible. However, you would need to write a macro using the OpenOffice.org Basic language that does the "export as PDF" action. You would then using the Tools :: Customize menu and click on the Events tabs to get your macro to run when you open the document.

Writing macros is custom programming so although I can't help you write such a macro, I do know that you would also have to hardcode the file name that you want to save the PDF file to because if you don't, the native Save dialog will appear.

One other thing to be aware of is that if you implement such a macro, you should send NeoOffice a native "open document" event, not a "print document" event. The reason for this that NeoOffice's underlying OpenOffice.org code opens your file with macro execution disabled when it responds to a print document event.

Another possible option is to store your documents in NeoOffice Mobile. Then, if you log into NeoOffice Mobile from Safari on your iPhone or iPad, selecting a file will automatically download a PDF copy of your document.

Hope that helps.

Patrick
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Mon Aug 09, 2010 1:51 pm    Post subject:

FYI. I have included the fix for the "print document" event bug in NeoOffice 3.1.1 Patch 2. The patch can be downloaded from the NeoOffice patch download page.

Patrick
Back to top
Display posts from previous:   
   NeoOffice Forum Index -> NeoOffice Releases All times are GMT - 7 Hours
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Powered by phpBB © 2001, 2005 phpBB Group

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © Planamesa Inc.
NeoOffice is a registered trademark of Planamesa Inc. and may not be used without permission.
PHP-Nuke Copyright © 2005 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.