Can a circle be printed/drawn in a printfile with DDS? - printing

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.

Related

SharpDX numbered classes, where do i find their respective documentation/responsibilities?

I'm having a hard time everytime i look at SharpDX code and try to follow DirectX documentation. Is there a place where what each of the numbered classes map to and why they exist is clearly laid out?
I'm talking about things like :
DXGI.Device
DXGI.Device1
DXGI.Device2
DXGI.Device3
DXGI.Device4
SharpDX.Direct3D11.Device
SharpDX.Direct3D11.Device1
SharpDX.Direct3D11.Device11On12
SharpDX.Direct3D11.Device2
SharpDX.Direct3D11.Device3
SharpDX.Direct3D11.Device4
SharpDX.Direct3D11.Device5
SharpDX.Direct3D11.DeviceContext
SharpDX.Direct3D11.DeviceContext1
SharpDX.Direct3D11.DeviceContext2
SharpDX.Direct3D11.DeviceContext3
SharpDX.Direct3D11.DeviceContext4
Everytime i start from code i find it seems to be picked by black magic and i have no idea where to go from there, for example i'm using this (from code i found) and i have no idea why it's device3, factory 3 going with swapchain1 on which we queryinterface swapchain2 :
using (DXGI.Device3 dxgiDevice3 = this.device.QueryInterface<DXGI.Device3>())
using (DXGI.Factory3 dxgiFactory3 = dxgiDevice3.Adapter.GetParent<DXGI.Factory3>())
{
DXGI.SwapChain1 swapChain1 = new DXGI.SwapChain1(dxgiFactory3, this.device, ref swapChainDescription);
this.swapChain = swapChain1.QueryInterface<DXGI.SwapChain2>();
}
If full explanation is too large of a the scope of an answer here any link to get me started on figuring out what C++ DX maps to which numbered object and why is most welcome.
In case this matters i'm only interested in DX >= 11, and i'm using SharpDX within an UWP project.
SharpDx is a pretty thin wrapper around DirectX, and pretty much everything in DirectX is expressed in SharpDx as a pass-through with some naming and calling conventions to accommodate the .net world.
Real documentation on SharpDx is essentially nonexistent, so you will have to do what everybody else does. If you are starting with something in SharpDx then look directly at the SharpDx API listings and the header files to understand what underlying DirectX functions are being expressed. Once you have the name of the DirectX function, you can read the MSDN documentation to understand how that function works. If you are starting with something in DirectX, then look first at MSDN to understand how it works and how it's named, and then go to the SharpDx API and header files to find out how that function is wrapped (named and exposed) in SharpDx.
For the specific question you ask, SharpDx device numbering identifies the Direct3D version that is being wrapped.
Direct3D 11.1 device ==> ID3D11Device1 ==> SharpDX.Direct3D11.Device1
Direct3D 11.2 device ==> ID3D11Device2 ==> SharpDX.Direct3D11.Device2
Direct3D 11.3 device ==> ID3D11Device3 ==> SharpDX.Direct3D11.Device3
and so on.
Naturally each version has a slightly different ("improved") interface. Lower version numbers will work pretty much anywhere, and higher version numbers include additional functionality that may require something specific from your video card and/or your operating system. You can read about the API for each version in sections found here.
For example, the description of the new methods added to the ID3D11Device5 interface (i.e, what's new since ID3D11Device4) is here. In this case, Device5 adds the ability to create a fence object and to open a handle for a shared fence.
When example code uses a specific device number, it's usually because the code requires some functionality that wasn't there in a previous version of Direct3D. In general you want to use the lowest numbered device (and factory, etc.) possible, because that will permit your code to run on the widest variety of machines and video cards.
If you find example code that creates a SharpDX.Direct3D11.Device1 but doesn't appear to use any methods beyond those in SharpDX.Direct3D11.Device, it's probably for one of two reasons. First, the author may know that a later example will require a method or field that doesn't exist before Direct3D 11.1. Second, the author may know that every video card and operating system capable of running the example at all will be capable of running Direct3D 11.1.
For a person just starting out, I would suggest you just stick with Direct3D (and Direct2D) version 11.1, thus DXGI.Device1, SharpDX.Direct3D11.Device1 and SharpDX.Direct3D11.DeviceContext1. These are likely to run on any machine you'll encounter. Only increase the version number if you actually need some functionality that doesn't appear in that version.
One additional hint: if you read a thread about some Direct3D or Direct2D functionality and you can't seem to find it anywhere in SharpDx, look at the Direct3D API to see what version number first contains that functionality. Then go through the SharpDx API (or better yet the header files) for that version until you see a similarly named element. It may be wrapped in an unexpected way, but AFAIK it's all exposed, even when you have a hard time finding it.
Here you can find about all SharpDx objects, specifically for DXGI you can found here, There you can see the Device mapped to IDXGIDevice.
Note the words IDXGIDevice are hyperlink that references to documentation for C++ object. And on this way Device1 and Device2 etc.
You can see that there is a very simple logic here, SharpDx divides the name of the C++ object into Namespace and a class name,
For example instead of IDXGIDevice, you get Namespace: DXG and class Name: Device.
In the documentation for each C++ object you can find Requirements.
And there is detailed in which operating system you can use the object.
As the number is higher, the object will work in a newer operating system.
For example, IDXGIDevice1 works under Windows 7, however IDXGIDevice3 works under Windows 8.1 or higher.

Dynamically change print data

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?

Is it possible to use windows Ink (handwriting recognition) to analyze an image?

Is it possible to use the MS Ink API to analyze a scanned image of handwriting, or does it only work with tablet pen input?
If it is possible, where is the relevant documentation?
No, its not possible.
Windows Ink is technology that uses information from the writing process, such as pen up and down, as well as direction of movement. this makes handwriting recognition relatively easy, but only because it can get the live writing data.
Analyzing previously written handwriting is very different and much more difficult, and requires machine learning. In this case it is kind of using the same method of recognition as humans use. check out the developments in Intelligent Character Recognition and Intelligent Word Recognition. It requires a lot of processing power and thats why services such as google goggles have to send the image to a 'trained' machine, and even then it cant really read handwriting well. its cutting edge technology, not ready at all for mass deployment.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms698159(v=VS.85).aspx
This application demonstrates how you can build a handwriting recognition application.The Windows Vista SDK provides versions of this sample in C# and Visual Basic .NET, as well. This topic refers to the Visual Basic .NET sample, but the concepts are the same between versions.
And you must also investigate the main class InkAnalyzer.
http://msdn.microsoft.com/en-us/library/windows/desktop/bb969147(v=VS.85).aspx
This sample shows how to use Ink Analysis to create a form-filling application, where the form is based on a scanned paper form.

Proper Guide for printing Report in Dot Matrix Printers

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.

Printing from an embedded system

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.

Resources