Currently it will show N/A as number of pages in the windows spool queue, is this possible to show the number of pages and what page is printing with bi-directional support on? with this file format? surely the printer itself must know what page is printing/how many pages have printed. thanks.
I can only answer the PostScript part of this question, not the Windows spool queue. I don't know how you are inserting the PostScript into the spool queue, but assuming you are printing from an application then my very hazy memory suggests that it's the application which declares the number of pages in the job.
The printer doesn't know how many pages a PostScript program contains. In fact, in the most general case, it's not possible to determine how many times a PostScript program will execute the showpage operator. That's because PostScript is a programming language and the program might execute differently on different interpreters, or under different conditions. It might print an extra page on Tuesdays for example.
Or to take an admittedly silly example:
%!
0 1 rand {
showpage
} for
That should print a random number of empty pages.
There are conventions which can indicate how many pages a PostScript program is expected to execute, the Document Structuring Convention contains comments which tell a PostScript processor (not a PostScript interpreter, which ignores comments, a processor treats the PostScript as just data and doesn't execute it) how many pages it has, amongst other data such as the requested media size, fonts, etc.
Not all PostScript programs contain this information and it can sometimes be awkward to extract (the 'atend' value is particularly annoying forcing the processor to read to the end of the file to find the value). Additionally people have been know to treat PostScript programs like Lego bricks and just concatenate them together, which makes the comments at the start untrustworthy. This is especially true if the first program has %% Pages: (atend)
Most printers do execute a job server loop, which means that it is possible for them to track which page they are executing, even if they don't know how many pages there will be.
It's also certainly true that a PostScript program running on a printer with a bi-directional interface could send information back to the print spooler, but there's no guarantee that a printer has a bi-directional communication interface, and there's no standard that I know of for the printer to follow when sending such information back to the computer. What should it send ? Will it be the same for Windows as Mac ?
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'm doing this in a printer server. I am trying to make a program that will show up a Yes/No dialog box before proceeding to print a page printed by any application or from the network.
So far, it was easy to pause and resume a job. But haven't found a solution to pause and resume a page to be printed.
For reference, here's more about controlling the printer on Windows
https://msdn.microsoft.com/en-us/library/windows/desktop/ff686805(v=vs.85).aspx
I am using Windows 10 64bit. Any language will do.
Thanks.
I'm prepared to be proven wrong, but I don't believe this is trivially possible. The print spooler doesn't have a notion of where pages begin and end in a spooled print session.
The location of each page is language dependent, and the print spooler can hardly be expected to parse the stream to find the start and end of each page, it would be very slow for one thing.
The alternative would be for the print processor to note the beginning and end of each page and the offset of the spool file at that moment, and then pass that information separately to the spooler.
But there are problems with that too. the 'RAW print' capability allows the printing application to inject 'stuff' straight into the print stream, bypassing the print processor altogether. This is common with page layout applications when printing to a PostScript printer for example, particularly on Windows as supporting CMYK isn't really possible when printing on Windows, and spot colours are even harder.
The injected code can contain any number of pages and the print spooler has no way to know where each page is.
So in the general case, I don't think this is possible, at least not in the print spooler.
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 use the following to write queue contents to a file:
q -xb -ITESTQ -mTEST > messages.out
I had 3 binary messages in the queue that got written to the file successfully. Now I have a need to load the same file back to the queue (same queue at a later time). When I do:
q -xb -oTESTQ -mTEST < messages.out
It puts 9 messages instead of 3. I am guess the formatting is misread while the file is loaded. I've noticed there is -X option in the q program. What is the usage of it? What other options I have?
You really need to look at the QLoad program (SupportPac MO03) for this. Same author as the Q program and every bit as good a tool. Also free. As the author explains in the manual:
Ever since I released my MA01 (Q Utility) SupportPac I have had
periodic requests to explain how it can be used to unload, and
subsequently reload, messages from a queue. The answer has always been
that this is not what MA01 is for and that surely there must be a
utility available. Well, after sufficient numbers of these requests I
looked for a utility myself and didn’t really find anything which
fitted the bill. What was needed was a very simple, some would say
unsophisticated, program which unloaded a queue into a text file. The
notion of a text file was important because a number of users wanted
the ability to change the file once it had been created. I also find
that text based files are more portable and so this seemed useful if
we want to unload a queue, say on Windows, and then load the messages
again on a Solaris machine. The disadvantage of this approach is that
the file is larger than it would be in binary mode. Storing data using
the hex representation of the character rather than the character
itself essentially uses twice as much space. However, in general I do
not envisage people using this program to unload vast amounts of
message data but a few test messages or a few rogue messages on the
dead letter queue which are then changed and reloaded elsewhere.
I'm using the GoAsm assembler on a Windows 7 - 64 bit OS and I'll be asking you a few (not so dumb) questions.
First question :
How can I find the physical address of a file ?
Let's suppose file "Text.txt" is at the root of my C:\ partition.
Is there a way to get the exact memory address where this file is ?
Second question :
Is it possible to call a routine which will just do like if I invoked a C function ?
(i.e. : Consider a C function "WriteToScreen", is it possible to have the same function, but in assembler format, that means without having the need to use high-level invokes to do that work ?
Third question :
Are there somewhere on the net some include files for GoAsm containing useful routines like (move, copy, edit, erase) commands ? I've first thought of ms-dos interrupts but I can't manage to get them to work without crashing the program. I guess it just not compatible with Windows OS even though the command prompt acts like ms-dos... ?
Fourth question :
I've heard from different sources and myself that NASM works pretty bad on Win7 x64, is it just true, or am I doing it the wrong way ?
1
An hard drive, from a logical point of view, can be seen as a sequence of "blocks" (the more common name is sectors). How these blocks are organized physically on the disks can be disregarded, but the driver must know someway how to get data of course, though you send to modern hd driver "high level" commands that, as far as you know, are not strongly related to where data physically are (you can say "read the block 123", but there's no extern evidence of where that block lives).
However this way you can "name" a block with a number, and say e.g. that block 0 is the MBR. Each block contains several bytes (512, 1024...). Not all used blocks contain actual data of a file, in fact there are metainformations of any sort, depending on the filesystem but even related to the "structure" of the hd (I mean, partitions).
A file located on an hd is not automatically loaded into memory, so it has no memory address. Once you read it, piece of it if not all are of course copied into the memory you give, which is not an intrinsic property of the file. (Filesystems retrieve the blocks belonging to the file and "show" them as we are used to see them, as a single "unit", the file)
Summarizing: files have no memory address. The physical address could be the set of blocks holding data (and metadata, like inodes ) of the file, or just the first block (but if a block of data is N, N+1 could not belong to the same file - the blocks need no to be one next to the other). To know them, you have to analyse the structure of the filesystem you use. I don't know if there's an API to retrieve them easily, but in the worst case you can analyse the source code of the filesystem... good luck!
2
C functions are translated into assembly. If you respect the C calling convention, you can write a "C function" directly in assembly. Try reading this and this for x86.
3
You can call windows API from asm. Forget MS-DOS, MS-DOS is dead, MS-DOS is not Windows, the cmd is a sort of "emulation"... indeed no, not an emulation but just a command line interface that resemble the one MS-DOS users was used to. But it is not exaclty the same, i.e. there are no MS-DOS system interrupt you can use. Iczelion's assembly tutorials, though old, could be an interesting resource. (If links expire, try with the wayback machine)
4
I do not own Win7 and never installed nasm on windows, so I can't say anything about.
For the first question just drag the file into the address bar in the browser