On Fri, Nov 6, 2020 at 2:02 PM FG74 <[email protected]> wrote: > I know it is possible because in another job we used a product similar to > Guacamole that generated a virtual printer and when sending the print job > there a new browser tab was opened with the print dialog form ready to > press > the "print" button in the default local printer (the user can change the > printer). > Unfortunately I am a functional user, not a programmer, and I only could see > a temporary pdf was generated on the server and the new browser tab was > redirected there with the instruction to print, not to download a file... > > Right, I think that's what I said was the possibility, but this doesn't give you a completely seamless experience where a print from your remote connection spools up on a client printer. But it sounds like it would work for what you're trying to accomplish.
That said, that doesn't mean it's a trivial change. Today, Guacamole Client does not know the difference between a file transferred because the user requested it via file redirection and a print job. Assuming you're talking about printing from RDP connections, the print file download is started here: https://github.com/apache/guacamole-server/blob/9df3e294c3f5cb42a51efcea00c7dc384e0b093d/src/protocols/rdp/print-job.c#L138-L140 and then other functions within that file take care of sending along the chunks of data. However, as you can see in the source code above, all this does is send a file to the remote client. So, in order to make the browser behave differently for a print job versus a file download (via drive redirection or SFTP), you would have to do one of the following things: 1) Create a new channel (instruction) for printing and modify Guacamole Client to handle the print channel differently from the File channel. 2) Modify the file instruction and put a flag that tells Guacamole client to try to display (or print) the file in the browser instead of downloading it automatically. 3) Within Guacamole Client, examine the file type of the incoming file stream and make a determination about whether to try to display supported files automatically in the browser if they are of a certain type. That's just my guess at what it would take without doing much digging. Of the above, #1, if doable, would definitely achieve what you're looking for by allowing for the print dialog to be created when the "print" instruction/channel gets data. #2 could attempt to display the data in the browser, and possibly generate a print dialog you're looking for depending on how it was implemented. #3 doesn't really get you seamless printing, just gets the files displayed automatically in the browser, at which point you could print it and maybe save a little time of having to open the file before printing. -Nick
