I am using CUPS with the printer driver which use "application/vnd.cups-raster 10 rastertopj" and i am trying to get the look of dither 4x4 print/output but i am clueless where to change the setting for choosing different dithering/halftoning pattern..
i also contacted the cups and they said dithering is done by the driver and also told that If the driver is Ghostscript-based you may be able to change the dither as you’d like, and yes this is indeed Ghostscript-based printer driver/filter cause when i open .PPD file i see *Product: "(ESP Ghostscript)".
Can you please guide me on how or where to change the dither of the printer filter/driver?
Edited:
this is the halftone output its printing: https://imgur.com/a/18hkC1H or https://imgur.com/download/7pTksX4
this is the output i am looking for: https://imgur.com/a/KZTQrkp or https://imgur.com/download/5FnpKEM
Thankyou
Ghostscript supports the full range of halftoning defined in the PostScript Language Reference Manual. It also has its own stochastic screening code.
To change the screening, you put the relevant commands in the PostScript file. If you are starting with a PostScript program, then that's where you put the screening. Otherwise you'll have to inject it into the PostScript, which is where you modify the PPD file.
I can't tell you how to do that (because its a CUPS thing, not Ghostscript), nor can I tell you what the PostScript you need is (because I have no idea what the screen you want looks like), you'll have to experiment to match the output you want (note that halftoning is not the same as dithering). Worst case you can use a type 3 halftone dictionary which should produce something similar to what you want, at the cost of needing a lot of data to set it up.
<<
/HalftoneType 1
/Frequency 37
/Angle 45
/SpotFunction {180 mul cos
exch 180 mul cos
add 2 div}
>> sethalftone
For what its worth, the above is a type 1 halftone dictionary defining a round spot shape and with what I beleive are 'reasonable' values for a 300 dpi monochrome output device.
As to how you get that into the PostScript that Cups sends to Ghostscript, or onto the Ghostscript command line, I can't tell you.
Related
Retro printer day: I have an old IbmPro compatible dot matrix printer connected by a USB parallel adapter to my Ubuntu 20.04 system. It works great! One major trick in setting it up: set the URI to /dev/usb/lp0 and make sure the lp user is in the right group to write to that dev. That took me a while to figure out. I use the IBMPro generic printer driver and it's great. Other critical hints: 9600 baud, 8 bits, no stop bit, hardware flow control.
The one remaining problem: the print area is offset about 0.5" to the left. I'm sure I know what's going on: the tractor feed area is about 0.5" and so I need to somehow indicate, don't count the tractor feed area within the page margin. In other words, the full page width is about 9.5" but only print 8.5" of that and offset it 0.5" to the right.
I've tried editing the PPD file including changing the values in HWMargins and ParamCustomPageSize WidthOffset. None of this seems to have any impact. I've read a bunch of documentation about PPD files and it's just not clear what to do. I guess I could set up a custom paper size of 9.5" width but I would prefer to just have all my documents be the same and print correctly by offsetting everything as it's generating printer output.
There must be a simple setting for this.
Edit: tried a lot more things including:
Go to Printer Properties and go to Job Options. There's a left margin setting. I set it to 36 points, or half an inch, and that moved printing over. Adjust as desired. But that didn't work. I also tried to make this change in the PPD:
ImageableArea Letter/US Letter: "18 36 612 756"
and that didn't work.
It is fixed. The order of parameters for the gs line in the PPD must be just right and it's not obvious how to get it working. After much trial and error, this line works:
*FoomaticRIPCommandLine: "gs -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE &&
-dNOMEDIAATTRS -dNOINTERPOLATE -sDEVICE=ibmpro%A%Z &&
-sOutputFile=- &&
-c "<</PageOffset [36 0]>> setpagedevice" -f -"
It must be in exactly that order. Adjust the offset values (36 for the horizontal offset, 0 for vertical, in this case) as needed. This really should have been easier, given that it's going to be quite normal to adjust offsets on any dot matrix printer. I hope this question is useful for anyone else in this situation. Yes do pay attention to the HTML escapes used in the line above, they are correct. I tried before using ' and that didn't work. It must be ".
This was really a lot of effort to figure out although would probably be obvoius to someone experienced in PPD files.
I am using http://shakithweblog.blogspot.kr/2012/12/getting-sobel-filter-application.html for zynq processor.
I am using his filter design in the PL part and running the hdmi test.
I am inputting this file
and my filtered output is coming like this:
I am trying to display 1920 * 1080 pixels.
Now lets assume its difficult for you see exactly my design/ or download the design and check it or even you are not familiar with the zynq board and all but is it possible to make some guess that why the filter output could be like this? and what can I try to make it correct. I need some suggestions.
Many printers have a "feed and cut" or "cut paper" command (I'm talking about POS - printers here).
Since using POS.NET is not always possible (horrific driver incompatibilities) and GDI can do so much more, we would like to utilize the paper cutter also when printing using GDI.
Is there a way to do so? Possibly when issuing EndDocument()?
Or maybe even from .NET?
GDI and even the abstract Windows printing model are probably not going to help you here. You're going to have to send the feed and cut command to the printer in the language that it expects to typically receive data.
For example, an Epson TM-T88III thermal receipt printer speaks the ESC/POS language natively, not a sequence of GDI or PCL commands. However, most of these printers do come with printer drivers that make Windows see them as regular GDI printers. The way these drivers typically work is that they rasterize all of the GDI commands into one big bitmap in software, and then dole out the bitmap to the printer for printing via its native-language "print the bit-image" command. This usually has less-than-desirable effects:
It is much less efficient (in sense of time required and data transmitted) to send a lot of bitmap data to the printer than a sequence of binary commands that it knows how to interpret. (Would you rather send an image of text to print, or just the actual text and a font size specification? Analogies with HTML/CSS vs. an image of text.)
These printers typically have low resolutions and are monochrome (that is, all black or all white, no grayscale or color). Their pre-loaded fonts are designed to work well under these limitations for crisp, clear rendering. By rasterizing to a bitmap, we lose this careful design as pixels are snapped and rounded off of the grid, resulting in jagged text rendering on the actual printout. If you're trying to draw something that's really sensitive to this kind of rounding, like a barcode, you're SOL, unless you're painstakingly keeping the DPI of the printer device context in mind while working with GDI.
For example, here is a snippet of code from an extensive example on my usually-irrelevant blog. You can see near the end how I fill the BinaryWriter with the necessary sequence of bytes that equals the "feed paper and cut" command on our Epson thermal receipt printer (AsciiControlChars is just a static class with constants):
using (var ms = new MemoryStream())
using (var bw = new BinaryWriter(ms))
{
// Reset the printer bws (NV images are not cleared)
bw.Write(AsciiControlChars.Escape);
bw.Write('#');
// Render the logo
RenderLogo(bw);
// Feed 3 vertical motion units and cut the paper with a 1 point cut
bw.Write(AsciiControlChars.GroupSeparator);
bw.Write('V');
bw.Write((byte)66);
bw.Write((byte)3);
bw.Flush();
return ms.ToArray();
}
You can then just send the bytes directly to the printer as a RAW document, either using the code at the end of that article, which works against various Win32 printer functions, or Microsoft's RawPrinterHelper class.
You'll need to look up the commands specific for your printer. Chances are that its not too different from the one that you see here: POS languages are beginning to standardize, but that's also like saying SQL is a standard--mutually intelligible by humans but not really interoperable without some adjustments.
If you really still want to use GDI, you can print the GDI document in the usual way to the printer (again, assuming that a GDI printer driver exists, which it probably does), and then issue a second, small, RAW document to the printer that contains the native feed and cut command. (Alternatively, some of the GDI printer drivers let you specify "always cut after printing a document" right in the Printers control panel--but good luck accessing that driver feature in a well-documented fashion programmatically!)
Hope this helps to paint a picture of GDI's relationship to POS printers.
I am seeking a method to extract into separate images the Luma (Y), Cb (blue component), Cr (red component), channels of the JPEG images:
Seattle Police Department image #1
Seattle Police Department image #2
Seattle Police Department image #3
I would like results equivalent to this example from Wikipedia.
The output must be calculated directly from the JPEG Start-of-Scan (SOS) data and other data in the JPEG, rather than 'back calculated' from the RGB images output by a decompressor. The purpose of this task is to produce images which represent the 'raw data' as closely as possible.
Are there existing tools which can accomplish this? I am considering throwing together something using Python, PyImage, etc. but I am surprised my search for open source or free tools has come up empty. I am aware there are many libraries which could help, although I am open to becoming aware of more libraries.
For this question, the correct answer would be a tool chain of free and/or open-source tools which can do the job. Tools with source are preferred. These tools can run on any platform, but Linux or Win32 would be immediately useful.
Answer inspired by codelogic
Given the libjpeg implementation, change djpeg.c and wrppm.c.
wrppm.c:
189: case JCS_RGB:
190: + case JCS_YCbCr:
191: /* emit header for raw PPM format */
djpeg.c
560: case FMT_PPM:
561: + cinfo.quantize_colors = 0;
562: + cinfo.out_color_space = JCS_YCbCr;
Obviously, this is quick hack, because I have a private copy where PPM output is always forced to YCbCr, but it works and I thank you, codelogic, for your Stone Code Logic.
As suggested your best bet would be to use libjpeg directly. Specifically, you might be able to set jpeg_decompress_struct's out_color_space member to be JCS_YCbCr instead of JCS_RGB and read the scanlines as usual. Here's some sample code (GPL).
Well the obvious one is libjpg.
When using the lp -o orientation-requested=6 in CUPS to print a postscript file, the first page is reversed 180 degrees and then the next page is back to 0 orientation. Third page has the 180 degree rotation and fourth page back to 0 and so on. I need each page in the file to be reversed 180 degrees. Any suggestions on what to try would be most appreciated.
If your PostScript file does not conform strictly to the PostScript DSC (document structuring convention), and the file is being sent to a PostScript printer, then whatever extras that CUPS may add to the pages may be getting overridden by ill-behaved per-page stuff in your document. Unfortunately there's no particularly good fix for overcoming arbitrary ill-behaved PostScript code. (The rotate-every-other-page or rotate-every-page-an-extra-180 behavior supports this via.
If it's your own application that's generating the PostScript file, you might benefit from comparing what you pipe into the spooler against what CUPS actually sends to the printer (you could capture it with netcat).