I am looking into a way to manipulate the data sent to a printer (inkjet for now. Probably an HP 2460).
I want to change the data dynamically each time the printer tries to print.
Ie. at point 1, the print will be of the page kept normally, but the paper might change its position, so I am looking for a way to rotate the input image to counter the rotation of the paper.
I think I am looking for a way to specify the data to be printed pixel by pixel in real time.
Data input available :
rotation
position of the print head with respect to the corner of the page at
each instant provided in real time
What I have so far:
I have seen one instance where a particular HP inkjet was modified to work directly off an arduino but I would like to do it directly from the computer for now for 2 reasons:
I need to submit a proof of concept system as soon as possible
I don't have much easy access to logic analyser/scope to reverse
engineer the communication protocol (nor probably the expertise).
I am looking into PostScript, GhostScript but from what I understand so far, I wont be able to modify the data dynamically (Still trying to figure it out, so pardon me if I'm wrong). Would this approach work? Or do I need to look into drivers or something else?
I am aware of the restrictions of asking questions and how ill-researched questions are frowned upon. I am still trying to figure out how to get this done and have been looking into all the things that came up in my mind and I am coming across while looking through. But, so far, whatever I've seen doesn't seem to be capable of doing what I want (or I'm missing it). I'm asking this question in the hope of getting some pointers as to what to look into.
if you mean to manipulate each page, ie this page landscape next page portrait, etc then i would work on the postscript input, and not even think about the specific hardware communications.
On the other hand you want to grab the print head and manipulate things real time after printing has started then the approach will obviously depend on the specific printer.
I would try to do this at a higher level if possible. Best would be if you take control of how the postscript is being generated, then you can insert <<...>> setpagedevice to change printer parameters.
One problem is that most printer manufacturers have stopped distributing documentation on the printer command language.
Another problems is ghostscript output devices are hopelessly out of date, like dot matrix printers. (see problem one).
For a screen printing output application, I reverse engineered the epson 1400 print command language and wrote a program to output a bitmap to the printer. Then I wrote a ghostscript printdriver based on a .bmp driver which created bitmaps and converted the bitmap to epson commands. Since you want to use an HP, this code unfortunately won't help.
Having gone down that road, I can tell you it isn't easy. Inkjet's don't allow rotation, so you'd need to rasterize the inkjet, then re-create a rotated image. Ghostscript is itself tricky to get running to a printer using gsprint and redmon, but if you already have postscript job that prints upright, then the image can be rotated and shifted with postscript commands.
I don't understand what you are trying to accomplish. Can you use a pc with a webcam to preview the orientation, then generate a bitmap and print it to the printer or do you need to wait till the paper is in position before generating the print data?
Related
Using DDS I know I can print a box and color it in using the the BOX keyword:
A R BOX5 BOX(2.5 0.5 5.1 6.3 0.2 +
A (*COLOR *HIGHLIGHT 3 75)
Is there something similar to create a circle?
According to the DDS Reference: No. I can't find any keywords to directly draw a circle.
My guess is that back in the heyday of high volume impact printers, there was no fast way to print such circles. Note: Impact isn't necessarily the same as dot-matrix printers. Lines were possible with special characters, though. The "language" to steer such a printer was called SCS (SNA Character String).
But you can create a circle as desired with external programs, convert the result to a page segment, using specialized IBM software, and load that via DDS onto a page. See the PAGSEG keyword on the linked documentation for information and caveats. Especially the need to use AFP might pose a serious obstacle. (AFP is — overly simplified and thus not entirely correct — like PCL or PostScript, a page description language. IPDS can be roughly seen as equivalent to PJL.) Ricoh printers sometimes have native IPDS/AFP support. Also, there were some manufacturers for converter boxes, faking an SCS or even IPDS/AFP printer to the host side, and appearing as a PJL/PCL printer data generator to the printer.
The built-in Host Print Transform feature which can be enabled for printer devices converts the spooled output to PCL, so it can be sent to stock printers. The drawback is, it uses local CPU resources which might not be desired. Older releases of the OS might only support SCS with Host Print Transform.
Newer IBM I releases include InfoPrint Server, a java-based background task enabling to convert print jobs on the machine to PDF. I assume this should work with AFP. Not talking about resource usage, though…
Printing on IBM i is a deep rabbit hole in itself. See the accompanying documentation.
Is there a command line tool to remove all spot color channels from a vector input image (type can be ai, eps) and keep only the CMYK or RGB color channels .
What I ve been able to come up with so far is using ghostscript tiffsep device and then recombine the color channel images to one image using imagemagicks -combine option. The drawback of this method is that it is quite compicated and I end up with a tiff image, instead of the original (vector) format.
'Image' has a defined meaning in PostScript, it means a bitmap, a raster. I think, from the context, that you mean something more general.
The simple answer is no, in general you can't do this, and I don't know of any tool which will.
The reason is that to do so would lose information; the marks defined in Separation or DeviceN space would be lost entirely, and its generally regarded as a Bad Idea to discard random parts of the document.
Perhaps you could explain what you are trying to achieve with this (ie why are you doing this), and it might be possible to suggest an alternative method.
If you are a competent C programmer you could produce a Ghostscript subclass device using the existing FILTER device (in gdevflt.c) as a template. That device looks at the type of operation, and either passes it on to the output device, or throws it away. It would be reasonably simple to look at the current colour space and discard Separation or DeviceN space. If you then uses the pdfwrite/ps2write/eps2write outptu device you'd get an EPS, PostScript program or PDF file as the output.
Whether you go down this route, continue with what you have, or find an alternative approach, there are a couple of things you need to think about; how do you plan to tackle Separation inks with process colour names ? Eg /Separation /Black. What about DeviceN spaces where some of the inks are process colours ? Eg a duotone Black and Pantone ink. Should these be preserved or dicarded ?
Your current approach will use the parts of the object which mark process plates, but not those which mark spot colorus, which could give some very peculiar results.
[EDIT]
PDF, PostScript and EPS don't have 'layers' (PDF has a feature, Optional Content, which uses the term 'layers' as a description in the specification but that's all).
An application such as Photoshop and Illustrator can have layers, but in general what they export to has to have those 'layers' converted into something else. That 'something else' depends on what you are saving it as.
Part of the problem is that you are apparently trying to deal with 3 different kinds of input, you say Illustrator (PDF, more or less), Photoshop (raster image) and EPS (PostScript). There is little common ground between the 3, is there a reason to support all of them ?
If you are content to stick with just Illustrator you might be able to do something with Optional Content. I'm not terribly familiar with modern versions of Illustrator, but wouldn't it be simpler to save two versions of the file, one with the answer layer and one without ?
Anyway, Ghostscript can honour Optional Content, so if you can save a PDF file (not PostScript or EPS) from Illustrator, it may be that the layers will persist into the PDF as Optional Content. I suspect they will going by a quick Google. In that case you might be able to run the file through Ghostscript, telling it not to honour the Optional Content portion, and get a PDF file without it present.
Another solution (again limited to PDF) would be to open the PDF file with an editing application such as Acrobat Pro, and simply delete the bits you don't want. Deletion of that kind is relatively reliable.
It still feels like rather a long-winded way to get a PDF file with some of the content removed though. I can't help feeling that just saving two versions from the creating application would be easier.
Is there anyone that could give some proper guideness in Printing Reports (e.g. XtraReports)
in Dot Matrix Printers? Or any information printing in Dot Matrix Printers. Can i just print the report as i could print in InkJet/Laser printers? Should i use Stream to LPT1, export the report as RTF and print as bytes[]? Use Escape Codes? Any info for the above targeting C# .NET? I should handle printing my business object for every property to a specific location? HOW?
If it were me (and 20 years ago it would have been) I'd concentrate on writing the document in GDI properly as a good, well-structured C# program. From there Windows can render it onscreen or to just about any printer you've got drivers for.
Let Windows worry about the print drivers for actually rendering the GDI document onto paper and handling system things like what port it's connected to (USB, Parallel, etc..) and all of the nasty protocol details.
Please don't wire things to "LPT1", "COM" ports or any of that crap. Your admins and future users of your software will hate you for it.
I need to add printing capabilities to an app and I have been looking around for information about printing. Logical/physical sizes, dpi, font scaling, etc, lots to digest since I never programmed printing into any app before.
Are there any sites that would offer a primer on the topics of page sizes, margins and all the other elements required to understand printing on Windows? I've been looking around for a while but what I find is either cryptic or years old...
I've been playing around with TPrinter, but I would like to build solid printing functionalities and understand what I'm doing better.
Using a report solution is not an option, even though I'm sure it would provide better results much sooner.
Two links to get you started:
Printing with TPrinter
Printing via the TPrinter Canvas
I think that you are looking too lowlevel.
Try looking at the build reporting tools (Rave or whatever is in your product).
Personally i am using a product called Report Builder from Digital Metaphors.
But if you want to do the lowlevel stuff lot og good information can be found at efg's computer lab - printing
Well, I have done things a variety of ways in the past, including the "hard way" with TPrinter. In fact, I recently had to do that again to run a special inventory label printer.
On the other hand, sometimes you are better off taking work others have done and using it for your benefit. I agree that ReportSmith isn't so great, and also it's Delphi (and Windows) specific. Using Excel or Word has those limitations, plus the fact that the user has to actually have them installed.
One thing I have done to make printing easy for some simple applications is just to generate an HTML file and call the user's web browser, then they can print it. HTML tables can be created relatively easily for numerical data, and you can include photos, etc. as well. This works well for some applications, and works on every platform where a web browser is installed. The downside, of course, is that HTML isn't the most precise layout language.
The version of Delphi you´re using is important. A number of Delphis came with print engines like ReportSmith (ugh). Another option thinking laterally is to use MS Word as a print engine. I´ve hooked into instances of Word & Excel before & utilised their functionality. As to raw printing using TPrinter or the print method of TForm you´d have to be pretty desperate. I seem to recall the Pacheo / Texeira Delphi books coming with a pretty good overview so you might want to see if you can find a copy of that somewhere.
We are making a lab instrument using an ARM9/RTOS system. The client has asked about printing simple reports from the ARM9 system. In this case, we have USB Host support in the RTOS. I'm thinking about printing bitmaps in generic PCL, hoping that will cover the widest range of printers. Is there a better way to approach this? I'm assuming the RTOS does not have printer drivers, and I don't want to support a lot of printers.
We also support USB device mode on our system, so you could plug in a photo printer, and our device would appear to be a USB stick. So that would work, but it's a bit clunky. This will be a C/C++ embedded system
Pretending to be a digital camera and interfacing with a PictBridge printer actually sounds pretty clever. It would remove the need to deal with different printer drivers, and if my understanding of the technology is correct, you could even control the operation of the printer right from your device.
On the other hand, as someone who has used a fair number of computerized lab instruments (oscilloscopes etc.) I find the ability to save screenshots from an ethernet/web interface to be much more useful. Print is dead.
Have you looked at what all the scope vendors are doing? They all have print options (I think) and I don't know what they are doing to solve this problem.
Last time I was involved with something like this, we used serial ports to talk to HP printers using PCL. That backfired as everyone quickly stopped making serial printers!
PostScript is natively supported by most printers, so you could just send it over the wire, but it would be a lot more cumbersome than straight ASCII. There are libraries, but they're bulky.
Since your device can appear to be a USB stick, a simple solution would be to generate a report as a JPEG image and then have the printer open and print it. This way, the people who want paperless output can use the image as-is, and everyone else can print it.
If I understand you correctly, you could write a formatted text file and do a "print" command through Windows in the "usb stick" mode.
For a simple report, it would be best to stick to straight ASCII. If you need some graphics, PCL would be a good choice for B/W laser printers, but I'm not sure how universal it would be for the more common ink-jet printers.
Edit: the PCL Reference Manual is available as a PDF from HP.