Is it possible to make that javascript command (i think it's "window.print" or simply "print") work with MUI(RA)OWB? How much work will be needed to implement a working version? I wouldn't care if a base version would send the stuff to prt: but of course it would be nicer if it respects the Printer Prefs
Yes, i know there are workarounds like this It also works when i would choose to use clipdown...
What i like to know is the reason why this js doesn't work (probably because it sends commands which are ment to be interpreted by windows?) and if it is possible to support (probably through a system hook that catches the commands sent and translate it into OS4 useable commands?)
Maybe it´s possible to save the whole page via wget to ram:T and then start a script or html interpreter who convert the data to pdf or other format to print several pages directly in one turn.
Raziel wrote: But which part of the browser interprets that js command?
I'd guess it would be the JavaScript interpreter. But the interesting thing is not just which part interprets it, but which part executes the action tied to it.
Quote:
If i would know where to look i could do a i.e. a script myself and automate it
Note that making a JavaScript print command work and making it possible for the user to print a page in a browser are two very different things. As others have mentioned, MUI-OWB has a menu item for saving the current page as a PDF. Unfortunately, I don't think this functionality is available for invoking from e.g. an ARexx script, is it? If it were, it would be relatively easy to create a context menu item which saves to a file in T: as PDF and then invokes Ghostscript on it to print it.
So, do you specifically need the JavaScript print command to work, or do you just need to be able to print? If the former, you would have to have the source code for the JavaScript interpreter (which e.g. in IBrowse is a separate library, but in other browsers can also be statically linked into the main program), fix or even create the implementation of this command in the JavaScript language implementation, and make it call some appropriate function of the browser for printing. In OWB-MUI, that function could have been what I described above - if that were possible to create in the first place.
So, do you specifically need the JavaScript print command to work, or do you just need to be able to print? If the former, you would have to have the source code for the JavaScript interpreter (which e.g. in IBrowse is a separate library, but in other browsers can also be statically linked into the main program), fix or even create the implementation of this command in the JavaScript language implementation, and make it call some appropriate function of the browser for printing. In OWB-MUI, that function could have been what I described above - if that were possible to create in the first place.
The short answer ... there is no short answer.
What i would need is to make the js print command work as OS print command There is no need to explicitely use gs or anything else to print, only to be able to send the (printable?) page to the OS printer via OS4s channels (so the data will already be handled the right way, thus no need to explicitely tell any program what to do).
I know that it would be kind of difficult to change the source from a project like OWB...i just wonder how the other OSs do it.
Ideally it would work like OWB invokes window.print()...and sends the (already printable data? - one thing i do not know is if the data is processed to be printable or if that wrk is lft to the OS functions) page to ... somewhere (i also don't know) OS4 intercepts it (maybe?) and relays it to the printer set in PrinterPrefs (thus, again, with no need to further process the data, because all would be done by the OS printer?)
Of course neither do i know what that window.print() command does in the first place (does it send the page in RAW form to some temp dir? does it compute it before to make it printable?) nor if the other OSs do the rest of the work (like changing the data to printable form)
What i would need is to make the js print command work as OS print command There is no need to explicitely use gs or anything else to print, only to be able to send the (printable?) page to the OS printer via OS4s channels (so the data will already be handled the right way, thus no need to explicitely tell any program what to do).
I know that it would be kind of difficult to change the source from a project like OWB...i just wonder how the other OSs do it.
I don't know either, but it wouldn't at all surprise me if what OWB/WebKit does is actually create a PDF or PS version of the page, probably based on a re-interpretation of the page source/CSS etc., taking any CSS media=print specifications into account. This would be a very natural thing to do in the Linux world, where printing is often implemented within the #?ostscript concepts. And since MUI-OWB has that menu item for creating a PDF, I figured it might be using existing code within the upstream implementation, code which might have been available also for the Reaction OWB, should anyone have chosen to use it (and fit it into the port, no idea how much work that required for Fab and/or the OS4 porters).
Quote:
Of course neither do i know what that window.print() command does in the first place (does it send the page in RAW form to some temp dir? does it compute it before to make it printable?) nor if the other OSs do the rest of the work (like changing the data to printable form)
See, what you (probably) didn't consider was the possibility that what to you (and the old AmigaOS printer concepts) is "printable" is not necessarily what you want, as that would be a pixel-to-pixel dump of the already rendered page, or rather the part of it fitting the window. If I'm somewhat correct in my above guesswork, it might already be better off (at least in MUI-OWB) by re-rendering the whole page as a (vector-based and thus scalable) PDF, which can then be printed by one of the best printing methods the OS currently has to offer: Ghostscript - unless you happen to have a printer directly supported by the old printer drivers still maintained and included.
The PDF export function in OWB MorphOS reuses a generic WebKit method (and by the way, you can choose to disable background by unchecking the "Print backgrounds" option in prefs->content).
The problem is i currently don't compute a proper resolution/DPI for the PDF export. The width isn't really suited for A4 printing (or anything else). Ideally i should also show additional export options (page number, DPI, ...).
As for the window.print() binding, it would surely be trivial to add, and it would also be even easier to add a PRINT REXX command (actually it already exists, it just does nothing).
Fab wrote: The PDF export function in OWB MorphOS reuses a generic WebKit method
Cool, more or less what I suspected .
Quote:
The problem is i currently don't compute a proper resolution/DPI for the PDF export. The width isn't really suited for A4 printing (or anything else). Ideally i should also show additional export options (page number, DPI, ...).
Right, I did notice that on the few occasions I used it so far, but it's a minor detail compared to finally actually being able to print a web page on the Amiga!
Quote:
As for the window.print() binding, it would surely be trivial to add, and it would also be even easier to add a PRINT REXX command (actually it already exists, it just does nothing).
Can - or could - the PDF export functionality also be callable via ARexx? It would enable a context menu/script solution like described earlier.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
