I can print out using the "window.print" command with javascript, but when I run my web application with webview, this command does not work. I searched for a long time and learned that javascript functions such as print or file are not allowed in webview applications, so I started to search for an alternative way, for example, adding an android button to the field I want to print out. . When I click on this button, I want to be able to output the div whose id I specified and its contents, of course, the css & styles applied to those divs should also appear in the output.
Related
There is web page, that has the "Print" button. I load it using DCEF3. If user clicks the button, the Printer selection dialog is shown. I want to disable printing once and for all.
I have been trying to pass command line parameters using the example.
So, I tried the following:
--disable-print-preview
--kiosk
--kiosk-printing
But none of them did the trick. Am I missing something?
CEF3 doesn't support "silent" printing, that is, printing without a printer selection dialog.
All you can do is :
Print to a temporal PDF file and then print the PDF file.
Take a snapshot from the browser and print the bitmap.
Modify the CEF3 libraries to hide the printer selection dialog.
These functions are much easier to use with CEF4Delphi or OldCEF4Delphi. To print in a PDF file all you have to do is call TChromium.PrintToPDF and to take a snapshot you need to call TChromium.TakeSnapshot
Not all the Chromium flags or command line switches are supported by CEF3. --kiosk and --kiosk-printing are not supported as you can see here.
You may even have to modify the JavaScript code in that web page to replace the "print" button function with a custom JavaScript extension registered with CEF3. That extension would send a message to the main browser process to print using your custom function.
I'm putting together an installation using Processing, where users type and their text is printed on a receipt printer.
I've got Processing saving out time-stamped text files to a folder, and a folder action in Automator watching that folder and sending to print.
My problem is that these .txt files need some intervention...
Format > Wrap to page
Change margins
Select 80mm receipt roll in Page Setup
I think I have the margins thing figured out by adding some code to the file header on the Processing side. With the rest, I'm drawing a complete blank.
I've tried setting the receipt roll as the default page size in 'Print and scan' in system prefs, but the receipt page size doesn't show in the list in system prefs, only shows on the page size list from within Text Edit application.
I suppose what I'm asking - is there a way of setting TextEdit's default to page wrap, certain page size, certain printer - then a folder action can just print away (I hope).
The idea is that these text files spit out of the receipt printer automatically with no intervention. Does anyone have any ideas? Thanks in advance.
Have you experimented with the settings available for TextEdit in AppleScript? If you look under the print settings section (in TextEdit's Script dictionary), there are a number of options available, which may help you achieve something pretty close to what you want. You could then drop the AppleScript into a Run AppleScript action in your Automator folder action.
Alternatively, you could go completely nuts and design a template in Pages that meets your criteria, and then extract your text, paste into your Pages template, and print that out. A whole lot more work, but once it became functional, you would only need to change the Pages template in the future to meet changing needs.
I am updating an old application, and have been asked to change the old Print routine (which just invoked the print command via javascript, and printed out the html), to one that prints out a pdf (the theory being that we then have more control of the pdf / how it looks etc across all printers.)
Using the Rotativa library, I can generate my pdf's, either on the fly or to a file.
After doing some reading, it appears impossible to stream a pdf from memory, and it has to be created as a file first, sent to the browser, and then deleted.)
the last line of my controller is;
return File(#"D:\Development\Source\Workspaces\ConsumerCreditLicenseSystem\Code\ConsumerCreditSystem\CCLSystem\_Idd\1.pdf", "application/pdf");
What I am strugglign with is getting that page to invoke the Print Dialog. If I send it to a new view with javascript to do this, then I am back to square one as the page is html not my pdf. Is there any way I can mark that my pdf is for printing, or combine it with some html so I can have the old faithful of
window.print();
in the document?
A PDF is not a webpage; it's a binary. When you send the PDF as a response to the user, you have no control over what happens on their end. If their browser is capable of viewing a PDF in place, it will display it; otherwise, it will prompt the user to download it. Either way, it will be up to the user whether they want to print it or not, and it will also be up to them to go back or whatever. You cannot redirect the user automatically at this point.
A slightly better option would be to redirect the user to another page, with a link to a view that will send the PDF down to them. Then, you can do things like force the PDF to download (so it's not rendered inside the same tab/window, effectively taking the user away from your site), or force the link to open in a new tab or window. However, you still will not be able to prompt the user to print.
I created a WiX 3.5 setup with a custom license file by putting this into the .wxs file:
<WixVariable Id="WixUILicenseRtf" Value="License.rtf" />
This works perfectly and the link is displayed when I run the created .msi file.
(I'm using the WixUI_InstallDir Dialog Set)
Now I want to put a hyperlink into the license file.
I just put the link into the file by opening it in WordPad and pasting http://mylink.com (WordPad turns it into a hyperlink automatically).
When I compile that in WiX, the license agreement dialog shows the link like this:
<http://mylink.com>
I noticed that this seems to relate to WordPad creating a hyperlink automatically (see above).
When I remove the http:// part from the link in the license file, WordPad doesn't recognize it as a link anymore and in the compiled .msi file, the < and > in the license agreement dialog go away.
Any ideas how I can get rid of the additional < and >, except putting the link into the license file without the http:// part?
EDIT:
Okay, maybe I didn't think enough when I used the word "hyperlink".
What I actually meant was: It does not have to be an actual clickable hyperlink.
I just want the adress of my web page to be displayed at the top of the license file.
I'm perfectly fine if it's just the URL as text (not clickable), but I want it to be displayed as I entered it, and not with < >.
The problem is that WordPad automatically turns any URL into a hyperlink as soon as I enter it, so I have no idea how to get the license agreement dialog to treat it as normal text.
Windows Installer doesn't support hyperlinks in the scrollable text control. This is why the link is not displayed correctly. Even if it was, nothing would happen when you click it because Windows Installer doesn't handle this event.
A hyperlink in a scrollable text control works only if you use an external UI which handles it.
Edit:
If you just want to display some text as a link, the usual approach is make it blue and underlined. As you already noticed Windows Installer doesn't show conventional hyperlinks correctly.
If you want to show a link as normal text, simply open the RTF file with a normal text editor (for example notepad.exe) and remove the hyperlink markers. Just follow the normal text formatting and you will easily spot the markers you want to remove.
I'm trying to make a program that fetches information from this webpage, www.sio.no , but when I try to view the sourcecode from my web-browser I only see some javascript commands.
Is there a way around this so I can access the text on the webpage?
Definitely possible, the "head" does have a lot of "script" tags in it, but if you scroll to the bottom you should see some html spaced by bazillions of newlines.
You should be able to parse the html from this page without problems. I used firefox to check that.