Printing score under Mac OS X about frescobaldi HOT 29 CLOSED

the print score button is only enabled if there is a PDF open in the music view. Frescobaldi prints the PDF using the lpr command if it can be found, first converting it to a PS at the printer dialog's paper size. I copied this behaviour from Okular, KDE's PDF viewer. But probably Frescobaldi calls the Mac OS X lpr with the wrong commandline arguments.

The print source function is entirely handled by Qt's QTextDocument itself.

from frescobaldi.

Something I didn't manage to get working is printing a score; I've never had problems with source code printing, it only occurs with the pdf rendering.

In both cases, the beginning of the process is normal:

clicking the menu line (print score or print source code) gives the same Print dialog box (I guess QT calls for a standard OS print dialog).
Then, in the case of source code, printing starts (if I choose to print to a pdf, the pdf is created without problem). If it's about printing the score, I got the message "Could not send the document to the printer".

I can confirm this behaviour on Mac OS 10.6 and 10.8.
Apparently another user has the same problem.

I am willing to help with testing, just tell me what you need.

from frescobaldi.

Frescobaldi simply tries to send the PostScript file to a command like "lpr". The code is in fileprinter.py.

What is a good working command that should be used for that on Mac OS X?

from frescobaldi.

What is a good working command that should be used for that on Mac OS X?

I'll try to investigate.

from frescobaldi.

I could make the printer command configurable, or enable printing via poppler (but that would result in raster images being sent to the printer).

from frescobaldi.

OK, the problem is that the printer name is different between Qt and lpr.

See QPrinter Class Reference:

When printing directly to a printer on Windows or Mac OS X, QPrinter uses the built-in printer drivers. On X11, QPrinter uses the Common Unix Printing System (CUPS) or the standard Unix lpr utility to send PostScript or PDF output to the printer.

I tried to manually set the printer name to the lpr-enabled printer name and the print is correctly launched.

There's also another problem: on Mac OS X there is a "PDF" menu in the print dialog that allows among the other to print to PDF: Frescobaldi deals with it correctly when printing the source code (printed through Qt) but not when printing the music (printed directly through lpr).
Also, all the other buttons in the dialog, but "Cancel", act as the "Print" button: this is no surprise, given that the dialog is used only to change printer settings, but the actual print command is given as a direct subprocess.call to lpr.
When printing the source code, every button in the print dialog has the expected behaviour.

I tried to see if it is possible to retrieve the lpr-enabled printer name from the Qt/native-Mac-OS-X printer name, but with no success; by the way, even if this is actually possible, it does not take into account the other problems.

A solution could be to rasterize the PDF through Poppler at the printer resolution (as specified in the printer dialog or as default) and send the images to the printer using Qt, which takes care of these problems.
This would work correctly for printing, but it would result in raster images sent to PDF (yes, it does not make sense to print a PDF file to another PDF file, but it should anyway work correctly).
I didn't find a way to disable the "PDF" menu.

Another solution, although less elegant, would be to open the PDF file in the default PDF reader and let the user launch the print from that application, which obviously results in the correct behaviour.
(This is very easy to implement: if I'm not wrong, it reduces to subprocess.call(['open', filename]).)
This is the solution adopted by TeXworks: when the user chooses to print the PDF, a yes/no dialog window pops up with the message
"Unfortunately, this version of TeXworks is unable to print Pdf documents due to various technical reasons.
Do you want to open the file in the default viewer for printing instead? (remember to close it again to avoid access problems)"

Unless you think that the "rasterized PDF file sent again to a PDF file" thing makes sense, in which case the first solution already solves all problems, I think that we should do something similar to TeXworks on Mac OS X, at least until we find a better way.

What do you think?
(I hope I've been understandable enough; let me know if I need to clarify some parts.)

from frescobaldi.

@wbsoft and @philmassart Opinions on this issue?
I think that the priority should be to avoid the print command that seems to work but actually doesn't: it isn't nice to mislead the users.
So we should implement the TeXworks-like solution before the October 16th release (it is very simple, as I noted in my previous comment).
Then, even after the October 16th release, we could try to solve the issue in the more elegant way of having a working print command.

from frescobaldi.

Opening the PDF in a (default or user-set) PDF viewer can already been done using LilyPond->Generated Files. (The PDF viewer can be configured in Settings->Helper programs.)

So yes, we should use the raster method for printing (as is used in Windows). There it uses 300dpi images because of memory issues, but we could default to 600 on nowadays computers. We could make a preference for the resolution, or use the value from the dialog (if it is settable in the print dialog).

I think it is not difficult to change popplerprint.py to pick raster printing on Mac OS X. Maybe remove the dialog warning raster printing results in inferior output.

from frescobaldi.

I tried to let lprCommand() not return a command, adding if not sys.platform.startswith('darwin'): before the for.
When I try to print some music, I get the warning dialog about print resolution and then the system print dialog, but an empty page is printed.
I don't know why this happens and what should I do.
Any ideas?

from frescobaldi.

@wbsoft Can you comment on the "empty page" issue?
I'd like to help but I don't know how.

from frescobaldi.

I need to investigate. I tested raster printing on Linux long ago then it worked. But on Linux the PostScript file is printed directly. I think we should fall back to raster printing when on Mac OS X and Windows, and test the printing on both platforms.
update: just tested, on Linux putting cmd=None just before the if not cmd in popplerprint.py causes rasterprinting to be used; and it works perfectly. So I don't understand why it does not work on Mac OS X. Maybe a vague memory issue. What happens if you write p = Printer(app.qApp) in line 95 of popplerprint.py (instead of p = Printer()). Maybe the printing thread gets garbage collected too soon.

from frescobaldi.

Windows XP, Frescobaldi 2.0.10: raster printing works as expected.
Mac OS 10.6, both Frescobaldi 2.0.10 and latest master, both with and without app.qApp: raster printing produces blank pages.

from frescobaldi.

I overhauled the printing stuff: now you can specify a printing command, whether Frescobaldi's dialog should open, and the resolution for raster printing. It is not yet tested.

On Mac OS X, is a progress dialog shown? (e.g. for a 10 page document, does it show that it prints 10 pages?)

from frescobaldi.

The progress dialog is shown now, and was shown also before.

Some new information:

• I didn't test with a multipage document before, because I kept trying to print a simple example ({c'}).
• I tried with a 2-page example: a 2-page document was printed, the second page was blank and the first page had some very big notes.
• I produced a PDF from the Mac print dialog (the PDF was identical to the printed example) and opened the first page with Inkscape: it included the complete first page of the example at the desired resolution, but the image didn't match the page size (which was an A4, as expected). The same for the second page.

So the PDF is correctly rasterized, but the size and position of the image are not correctly set with respect to the page.
If you want I can send you an example PDF output (as I said, it is identical to the printed example).

from frescobaldi.

I see the progress dialog. The resulting image on my test file is a "magnified version": it looks like each page is filled with a zoomed version of the center of the page.

from frescobaldi.

Ok, so linux and windows have working raster printing, but on Mac os x the image is way too large. Thanks for testing!

from frescobaldi.

To be complete: I defined lpr as the printing command in the preferences, and it prints. But:

• as it skips the printing dialog, it's impossible to define a page range. The complete document is printed
• first, the upper part of the score was not printed. In fact, the lpr command built in OS X doesn't use the user's settings for the printer: it seems that CUPS settings and OS X printer settings are not the same. I had to set paper as A4 in the CUPS preferences (http://localhost:631/) to have a correct print.
• that step is of course difficult for average user

from frescobaldi.

can you put lpr $ps as a preference? And check the checkbox "Use Frescobaldi's print dialog" The PS generating step does use the correct pagelist (also the raster printing)

from frescobaldi.

as it skips the printing dialog, it's impossible to define a page range. The complete document is printed

Also, you cannot choose the printer and the default one is always used.

can you put lpr $ps as a preference? And check the checkbox "Use Frescobaldi's print dialog" The PS generating step does use the correct pagelist (also the raster printing)

Using lpr $ps the page size seems correct.
There are some problems with margins, but maybe they can be corrected through the printer settings.

Using lpr or lpr $ps as the print command and checking "Use Frescobaldi's print dialog" results in a misfunctioning print dialog, where

• the "PDF" and the "Preview" buttons both act like "Print" and send the file to the printer,
• the choice made in the printer dropdown list is disregarded and the file is always sent to the default printer.

I didn't test other settings in the printer dialog, but this is enough for me to think that we should focus on making the raster printing work in an acceptable way.

from frescobaldi.

Ah, indeed, it should then be lpr -P $printer $ps. That would at least send the PostScript file to the correct printer. I'll see what I can do about the buttons... but at best we should try to fix the raster printing on Mac OS.

from frescobaldi.

With lpr -P $printer $ps and the frescobaldi dialog, I have the same error message we had since the beginning

from frescobaldi.

Ah, indeed, it should then be lpr -P $printer $ps. That would at least send the PostScript file to the correct printer.

No. As I said before, the printer names are different between lpr and the system print manager.
This is the cause of the original problem ("Could not send the document to the printer"), see also the last comment by Philippe.

I'll see what I can do about the buttons...

As far as I understand from http://qt-project.org/doc/qt-4.8/qprintdialog.html, you can't have much control over the native Windows and Mac printer dialogs.
I'm afraid that the only way to have a fully working print dialog is to print through Qt.
This means that

but at best we should try to fix the raster printing on Mac OS.

is the best thing to do.

from frescobaldi.

thanks for you concise help!

from frescobaldi.

I tried to play with the resolutions, page sizes, rectangles, viewports in popplerprint.py and qpopplerview/printer.py, but the result was always the same.
I'd like to help some more, but I'm really clueless right now.

from frescobaldi.

I think that we won't solve this issue in a day.
@wbsoft Would you reconsider the TeXworks-like solution (see #30 (comment)) for tomorrow's release?

The "print music" function right now is almost unusable on Mac (raster printing prints the images at the wrong scale; lpr printing uses only the default printer and creates a misfunctional the system print dialog).

It is true that the TeXworks-like solution would duplicate the functionality that opens the compiled document, but the point here is not to mislead the user promising to print the document with the system dialog and then either print a completely unusable document (raster print) or ignore the user settings and use the wrong printer (lpr print).

(Just to be clear, this would not affect the "print source code" function, that works perfectly.)

from frescobaldi.

I think because of lack of time I 'll disable the print function on Mac OS X for the release and just call the PDF open command instead, because the current printcommand blocks Frescobaldi.

We will try to fix Mac OS printing via raster but that will be in 2.0.12. I plan to release more often anyway.

I really would need to have a Mac to be able to debug the raster printing. It should be possible to get it to work...

from frescobaldi.

That's what I meant.

This is the TeXworks-like solution: when the user chooses "print music", a dialog is shown with buttons "yes" and "no" and the message

Unfortunately, this version of TeXworks is unable to print Pdf documents due to various technical reasons.
Do you want to open the file in the default viewer for printing instead? (remember to close it again to avoid access problems)

This avoids the surprise of the user when a program is launched instead of the print.
Maybe you could add a similar dialog.

I'll be happy to help fixing raster printing in the next weeks.

from frescobaldi.

Yes, let's to that. Will look into it.

from frescobaldi.

Done.

from frescobaldi.