We have a Gtk+ app running in Win. It relies on the GtkClipboard and related machinery to perform Cut/Copy/Paste (CCP) via the Win OS clipboard. All the CCP implemented thus far works correctly and we can CCP to/from our Gtk app with a variety of apps, for a number of Targets/formats.
However, there are strange differences between the Win OS clipboard "Targets" and the GtkClipboard "Targets", where "Targets" are the formats that the clipboard "owner" can convert into.
With the WinOS Clipboard Viewer (clpbrd.exe) running, and Copy'ing a selection from Excel, one can see the Targets that the clipboard owner (in this case Excel via OLE) can covert the currently copied selection. The Excel specific Targets are "greyed out" in the sense that clpbrd.exe can't convert into those, but the recipient programs may have the machinery to make the conversion, as per the image below. Presumably, this "greying" is due to Excel "attaching to the Win clipboard via the OleClipboard.
For example, we have code that can receive various Excel formats, such as SYLK, XML Spreadsheet etc. For instance, if the Excel Copy'd selection is pasted with Gtk Target chosen to be XML Spreadsheet, then on the Gtk-side, we receive an XML "text" stream that can be parsed with our XML parser etc. This is all as it should be.
However, if on the Gtk-side, one performs a gtk_clipboard_request_targets() to obtain the, presumed to be, same list of Targets (formats) that the clipboard owner (Excel) can convert into. However, we print out the Targets Gtk finds, it is a list as per this image:
Although there are a great number of similarities, the two lists are different. For example, the original (clibrd.exe) list had SYLK as one of the Targets/formats that the owner (Excel) was prepared to convert to. Yet, the list produced by Gtk does not include SYLK.
This discrepancy occurs for a variety of Win/Excel version combinations/permutations (XP, Win7, 32/64, Excel XP, Excel 10 etc).
... what gives? Clearly, in the OS clipboard, Excel claims to be able to convert to SYLK, so why does the Gtk query not see that? The Gtk query certainly sees Excel specific formats (e.g. any of the BIFF's etc), so why the odd discrepancy?
Related
I have a file located at C:\printme.txt
I want to print it to my printer which is named POS80
Is there not a simple command for windows in the command prompt to say Print C:\printme.txt to POS80?
It should be noted that POS80 is also the default printer so a command that does not include the printer name but just sends to the default printer would be acceptable too.
Your mileage can vary using the legacy command Print
It MAY work if you have a line printer set to LPT1 and worth trying
Print C:\printme.txt "POS80" However I expect you are getting the error message "Unable to initialize device PRN" that is not unusual as PRN was traditionally LPT1.
Later you say its USB connected. which means its serial (old Com ports) whereas Line Printer (old LPT ports) were parallel hence the potential needs for fettling, but in windows you can use the port name for the printer and that resolves ports issue (files can become ports or vice versa) thus no real problem.
Now you could try messing with printer port redirections to get around that but it would likely mess up other application printing. Thus by far the simplest is make the printer the default one which is what you have.
To avoid the Save Output File As dialog when adding a print job to the default queue, ensure that your default printer isn't Microsoft XPS Document Writer, Microsoft Print to PDF, or other print-to-file options.
So what is Windows 10 doing when you right click print? Generally it fires up the associated FTA (File Type Application) which for .txt (or similar chosen) is NotePad.
Thus the simplest way to command line print plain text is
NotePad /pt C:\printme.txt "POS80"
NotePad settings can be changed in the registry before and after you print, via the command line, even skewing letters (fun to prank colleagues if you use 1 degree off kilter), however you cannot set line spacing or add graphics, for those you need to step up to WordPad which will accept docx, rtf, odt and most simple text file types.
Several other file types can also be printed in a similar way such as graphics images, using mspaint.
Later you say you are sending html as text and want graphic output not textual.
So the x problem is the files are not plain.txt they are plain.htm so need translation from html by graphic conversion (rendering) to pass through a printer language converter (printer driver) That's a totally different question but the answer is still much the same.
Traditionally you would simply use
rundll32.exe mshtml.dll,PrintHTML "C:\printme.txt"
But security exploits have made that simplicity more of a challenge thus
best to run it like this.
cd /D C:\Windows\System32 & rundll32.exe mshtml.dll,PrintHTML "C:\printme.txt"
And Microsoft Current Policy is "User confirmation is needed to print an HTML page through MSHTML.DLL." thus you need to hit print using sendkeys.
If your preference is FireFox rendering, from the command line you needed to install an extension, however with tightened security in windows 10, I dont know if that's still possible.
If you wish to print xml or html graphically in windows 10+ you can ask Edge --headless to print those for you to PDF, either as screen shot or rendered text, silently without enforced html confirmation ! And again you can print html automatically by using sendkeys to replace the user.
However printing PDF from the command line is where the real fun begins.
It is possible if the PDF is the correct type prepared for the printer (even a simple thermal or inkjet) then an old school copy /b file.pdf "printer" may work but dont send a big file to test, just a tiny Hello World!, or your carbon neutrality is instantly wiped out by reams of paper with one or two letters each.
My dirt cheap HP accepts files that can be viewed as PDF that start textually like this i.e. which have the PCLm 1 comment.
%PDF-1.7
%PCLm 1.0%
223 0 obj
<<
/Type /Page
/Parent 2 0 R
/Resources <<
/XObject <<
/Image0 3 0 R
/Image1 4 0 R
For most POS printers a PDF either needs to be processed in middleware or usually top end firmware such as onboard Direct PDF
Thus we come back to using html bitmap and text directives that will either need a print driver or be programmed to a port or file for later copy /b to device.
As you no doubt know Microsoft have not made it simple to print file.html default in fact the opposite resulting in many third part apps for win xp-win 11 such as https://www.bersoft.com/htmlprint/index.htm#overview amongst many other options.
I've been generating payloads on Metasploit and I've been experimenting with the different templates and one of the templates you can have your payload as is exe-small. The type of payload I've been generating is a windows/meterpreter/reverse_tcp and just using the normal exe template it has a file size around 72 KB however exe-small outputs a payload the size of 2.4kb. Why is this? And how could I apply this to my programming?
The smallest possible PE file is just 97 bytes - and it does nothing (just return).
The smallest runnable executable today is 133 bytes, because Windows requires kernel32 being loaded. Executing a PE file with no imports is not possible.
At that size it can already download payload from the Internet by specifying an UNC path in the import table.
To achieve such a small executable, you have to
implement in assembler, mainly to get rid of the C runtime
decrease the file alignment which is 1024 by default
remove the DOS stub that prints the message "This program cannot be run in DOS mode"
Merge some of the PE parts into the MZ header
Remove the data directory
The full description is available in a larger research blog post called TinyPE.
For EXE's this small, the most space typically is used for the icon. Typically the icon has various sizes and color schemes contained, which you could get rid of, if you do not care having an "old, rusty" icon, or no icon at all.
There is also some 4k of space used, when you sign the EXE.
As an example for a small EXE, see never10 by grc. There is a details page which highlights the above points:
https://www.grc.com/never10/details.htm
in the last paragraph:
A final note: I'm a bit annoyed that “Never10” is as large as it is at
85 kbyte. The digital signature increases the application's size by
4k, but the high-resolution and high-color icons Microsoft now
requires takes up 56k! So without all that annoying overhead, the app
would be a respectable 25k. And, yes, of course I wrote it in
assembly language.
Disclaimer: I am not affiliated with grc in any way.
The is little need for an executable to be big, except when it contains what I call code spam, code not actually critical to the functionality of the program/exe. This is valid for other files too. Look at a manually written HTML page compared to one written in FrontPage. That's spamcode.
I remember my good old DOS files that were all KB in size and were performing practically any needed task in the OS. One of my .exes (actually .com) was only 20 bytes in size.
Just think of it this way: just as in some situations a large majority of the files contained in a Windows OS can be removed and still the OS can function perfectly, it's the same with the .exe files: large parts of the code is either useless, or has different than relevant-to-objective purpose or are intentionally added (see below).
The peak of this aberration is the code added nowdays in the .exe files of some games that use advanced copy protection, which can make the files as large as dozens of MB. The actually code needed to run the game is practically under 10% of the full code.
A file size of 72 KB as in your example can be pretty sufficient to do practically anything to a windows OS.
To apply this to your programming, as in make very small .exes, keep things simple. Don't add unnecessary code just for the looks of it or by thinking you will use that part of the program/code at a point.
What I'm trying to accomplish is to always keep a parsable duplicate of all printed documents, and execute a secondary process for each print.
(i.e.: Be able to parse all text, account for pages, vectors, images, etc).
Processing the document can either be done immediately or deferred (immediately is desirable).
As formats go, any PDL might be suitable, my best guess is XPS would probably be the best bet for a parsable format, any recommendations for other formats are appreciated.
Ideally, I'd like to not mess with the user interaction with the printing (e.g.: print settings page; or create a virtual printer, which could save a XPS and then forward the print job to the physical printer).
Since users might not be tech savvy to either set up/use it properly and/or mess up the process at a later date.
What I'm looking for at this time:
Documentation on the print process and flow (WDK, PDL, what else?)
How this could be accomplished, if at all possible; are there any existing solutions?
Any directions into what I should be looking at.
It's only part of an answer, but rumor has it you can tell Windows to keep spooled documents (right-click the printer, choose "Printer Properties", Advanced, "Keep Printed Documents").
You could enable this, and then create a scheduled task (or system service, etc.) that watches the spool directory and moves all files older than a certain threshold to a more appropriate location for further processing. (The age threshold would be a reasonable way to avoid trying to move files that are currently being written.)
Then you'd have to find a program to convert the .spl files to whatever format you like, or try interpreting it yourself. It looks pretty low-level but Microsoft does offer some documentation about the MS-EMF and MS-EMFSPOOL formats that might be a start.
I know that this is an old topic for vfp programmers. Still, I want to ask for advices that can improve the printing time for my particular case.
I recently asked to change a report written in vfp. It use commands such as fputs, etc. The user prints this report in a dot matrix printer and of course : no problem. But the user asked for column addition and some complex calculation in the report. We tried to avoid paper size changes. So my initial solution was to rework the report using report designer, and set the page orientation to landscape. The result is so slow when printed.When I open the print queue, it even shows error - printing status!
I've tried to instal the printer driver in my local PC ( the machine where I compiled the exe) and selected this printer, both with 'save printer environment' checked and unchecked. Still the same result.
Any suggestions? Other tricks for my case are welcomed. Thanks in advance.
Sometimes, and not sure if its your case, when creating a report in VFP, it saves the printer environment based on the computer used to develop it (ie: your machine). To check, and since all reports are nothing but .DBF tables renamed, try the following. Open the report as a table
USE YourReport.frx (you have to explicitly include the .frx extension)
BROWSE
The first line in the report is your environment information that includes paper size info, orientation and even printer information. Double click in the column "Expr". The only things you probably need in this column are
ORIENTATION=1 (or 0)
it may have other stuff and look something like
DRIVER=winspool
DEVICE=\some\printershare
OUTPUT=IP_192.168.1.22
ORIENTATION=1
PAPERSIZE=1
SCALE=100
ASCII=0
COPIES=1
DEFAULTSOURCE=15
PRINTQUALITY=600
COLOR=2
DUPLEX=2
YRESOLUTION=600
TTOPTION=3
COLLATE=0
You can remove the rest of it. Next, close this column and tab over about 10 more columns to "Tag" and "Tag2". They are also MEMO type fields. Open them up. Remove ALL data out of these two columns... BUT ONLY FOR THE FIRST ROW!!!! If you open them, you would see more embedded stuff about the printer, just remove it completely. Do NOT do a global replace to blank for all rows as that will kill the report content... ONLY the first row.
All this being said, I can't guarantee, but it may be the culprit... but then again, doing direct output on old dot-matrix printers might actually be faster than all the fancy rendering the printer drivers are doing.
Trying to print a report from the report designer through the windows driver to a dotmatrix printer will never be acceptably quick.
That's why they originally did the report using commands.
Your choices are either change the printer to a laser printer (probably not possible I'm guessing) or change the report back to the old style.
It's hardly difficult to print fast on a dot matrix printer with VFP reports, you should do it on a raw mode, but not on ?? or ??? way, I mean on API calls like this:
--- RawPrint VCX ---
http://www.universalthread.com/ViewPageNewDownload.aspx?ID=9556
You can use a wrapper, with kind-of "Formats" support it's a commercial software but it's worthy if you need to do a lot of reports with this kind of printer:
--- DosPrint 4 ---
http://www.victorespina.com.ve/hs/es/index.php/DOSPrint4_%28VFP%29
(disclaimer: the developer of DosPrint 4 it's a friend of mine, and I worked with him testing and supporting on the previous version DosPrint 3 on the spanish MS-VFP newsgroups and http://Portalfox.com)
Try using the Microsoft Generic Text only print driver
I'm looking for a method of converting .epsf to .eps for a publication I'm submitting. The submission site requires .eps (even though my understanding is that modern renderers should be able to read .epsf as well - the site is archaic, I have to upload all 100 images individually.) My co-author sent me the zipped files to upload (and now to convert) - I didn't make them myself. Further, the programs that made these images may exist on my co-authors computer but where is uncertain.
I've tried this in Mathematica 8 to reasonable but not full success - as in colored files become black and white, files with duplicate entries (as in Fig11a.eps and Fig11a.epsf both exist though they are different, it seems that the .eps is the background and the .epsf is the foreground layer) convert incorrectly. My attempt was to import the .epsf files to Mathematica and export them as .eps.
Also, I've using a middle man format - e.g. gif/tiff/png/jpg - with similar results. I haven't been able to find a program that's free (I assume photoshop could pull this off) that I could use - also I'd like to do it as a batch. A method that uses requires python/Mathematica or XP/Linux OS's would be fine. Thanks.
You do not need to convert anything. Encapsulated PostScript files can have both extensions (both EPS and EPSF). If you publisher refuses to accept files with an EPSF extension just rename them to EPS.
Any processing/conversion you do on the files (using GhostScript, Mathematica, etc.) carries the risk of corrupting the graphics in some way. But there's no need to do it. Send them as they are or rename them if you prefer.
(If you have any doubt, you can check the EPS Format Specification from 1992 which says that on the Macintish the recommended file extension is .epsf while on DOS it's .EPS)