I have a PostScript file with image and text. I want to print it to a laser printer so that the images print in a halftone round pattern.
I am trying to print it from the command line. I would prefer a PDF output first and then I'll print to the laser printer.
I have an HP Laserjet P2015 printer installed in Windows 10.
gswin64c.exe -dQUIET -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=output.pdf test.ps -c "<< /HalftoneType 1 /Frequency 37 /Angle 45 /SpotFunction {180 mul cos exch 180 mul cos add 2 div} >> sethalftone"
The PDF file is generated. However, the images does not appear to be in Round Halftone format. I see no change in the image.
This is the original Image
I want the printout to look like this: Required output
For some reason the output is the same as the original.
pdfwrite doesn't create monochrome output, so no, the output won't be halftoned. The whole point of the pdfwrite device is to maintain the output as close in quality as possible to the input.
There is no way to get monochrome output from pdfwrite unless the monochrome is in the input.
If you instead use a monochrome output device (e.g., tiffg3 or tiffg4) you should see a difference, unless the input file (which you haven't supplied) also sets a screen, in which case the last one encountered will take effect. That is, if the PostScript input file specifies a halftone screen, that's the one that will get used.
What you are asking for is what I might generally describe as a hard problem, probably much harder than you expect.
Your best bet is to send the PostScript directly to the printer, since it supports PostScript.
Problem 1; your PostScript file may already contain a halftone in it which overrides the one you want to use. You can usually prevent that by redefining the sethalftone and setscreen operators:
/sethalftone {pop} bind def
/setscreen {pop pop pop} bind def
You do that after you'[ve defined your own halftone, obviously. Or you can just edit the PostScript file and remove the halftone definition, its usually not that hard to find.
Problem 2 is that printer manufacturers sometimes 'tweak' the interpreter to always use their preferred halftone and prevent you overriding it in PostScript. The only way to find out if that's happening is to try a quick test; print a simple image with the default screen, then set a really coarse screen, say 10 lpi and print the same image. If there's no difference then you know that's not a viable option. If there is, then you can just set the screen you want.
Now, if the printer won't let you change the halftone then the only solution is to render the PostScript to an image using Ghostscript (which will let you change the halftone) and then send the resulting image to the printer. You will need to use a 1 bpp device, something like tiffg3 or tiffg4 should work fine.
The problem here is that you need to ensure that the image fits on the media of the printer, because if it doesn't then the likelihood is that the printer will slightly scale down the image so that it does fit, thereby squashing the halftone cells.
Even more subtly, the printable area of the media in the printer may not be the same as the size of the media. Paper handling can mean that there are some areas of the paper that can't be printed on, and the variability in the feeding of the paper can mean that the printer will refuse to print right to the edges anyway. Because if it did, and there was, say, a 1 mm deviation in the paper handling, then 1 mm of the edge would 'fall off' and there would be a 1 mm white gap at the other edge...
Related
I have a postscript image, which I wanted to scale down to 84x84 pixels.
I tried the following line ( and different ones, but this one is the furthest I got ):
gs -sOutputFile=somefile.bmp -sDEVICE=bmpgray -q -g84x84 -dDEVICEWIDTH=84 -dDEVICEHEIGHT=84 -dPDFFitPage frames/frame_00000055.ps
This did not achieve what I wanted (all it does is showing a white image).
You have several problems with that command line. There is no command line switch -dDEVICEHEIGHT or -dDEVICEWIDTH, the relevant switches are -dDEVICEHEIGHTPOINTS and -dDEVICEWIDTHPOINTS. You should never attempt to set the media size in two different ways anwyay, it will only lead to problems of some kind. You've specified -dPDFFitPage, but you appear to have supplied a PostScript program as the input.
Unsurprisingly, the PDFFitPage parameter does not scale PostScript.
When you are having problems of any kind, its best not to mute the application using -q (for quiet), in case its trying to tell you something.
Try using -dFitPage instead of -dPDFFitPage. If that still doesn't work, then I'll need to see your PostScript program.
84x84 pixels is tiny, its entirely conceivable that the result of downscaling a PostScript program could result in no pixel centers being touched, in which case the output will indeed be blank.
I use simple GDI DrawText to output blocks of text to a printer.
The font used in the sample is Segoe UI. But you can use Arial or others too. It doesn't matter.
The algorithm for large text blocks is simple. DrawText is called with DT_CALCRECT with a kind of binary search for the length to get the largest possible text to print. Than DrawText is called without DT_CALCRECT to print the block.
Simple one line text column text is written with one call to DrawText with the given coordinates of the rectangle.
The result is real strange and can be seen in this sample PDF.
Just look on the first line after the header. You can see the text "Test, Test" and you can see the strange kerning here perfectly. The kerning os sometimes so bad, that you can't even read the words.
How to get around this? Is it a problem with the used printer? Is it a problem with DrawText?
The distance between some chars in a word seem to be random in some case. Some spacing are wide other to narrow. The letter combination looks strange unreadable and ugly.
I tried different fonts and printers but the problem just varies but it is always present.
I know about ExTextOut and the capabilities to define the distance/kerning between all chars, but frankly I don't want to care about this. I just want that DrawText behaves on the printer like on the screen. The stuff works on the screen perfectly.
Added 2018-08-23 08:49 GMT+2*
To the code (it is a complex printing engine).
1.Fonts to print are created simply with CFont::CreatePointFont, so the LOGFONT structure is cleared to zero and no additional flags are used except point and face.
2.The mapping mode is MM_ANISOTROPIC. To scale what is seen on the screen and what is to be printed I just use the size of a komparable object (textblock) on the printer and the same size on the screen. The real values for the sample printout to the Microsoft PDF Printer are as follows, the real way I calculate them is not of interest:
m_pDC->SetMapMode(MM_ANISOTROPIC);
m_pDC->SetViewportExt(2363,100);
m_pDC->SetWindowExt(355,13);
This has the effect that the height of a line in LPs is 13, the average character width in LPs is 6...
This may sound like stupid question, but for me it's important.
I don't have much experience with using Photoshop, because Inkscape is perfect for my needs (web). Now I would need to create something and print it. I know that color mode for printing should be CMYK.
Because I am more familiar with Inkscape(that does not support CMYK), can I create PDF in that program and then import it into Photoshop and change color mode to CMYK. Is that valid? It shows that color mode is changed, but is that all? Because this is not for me and I just want to know if person that I wouk this for will not have any problems when it comes to printing. How can I make sure that conversion to CMYK was good?
One more question. In Inkscape I can not crop image, but I can mask or clip it. Basically, image still exist, but you see only portion of it. When it comes to printing will printer print full image or just that portion of it or I will need to crop image?
For most part, when you print an RGB file on your printer, the printer will convert it to CMYK. It's ability to do so "well" will depend on how accurate you need it to be & what color profile it is printing from (sRGB generally turns out better than say AdobeRGB).
The main reason for you to convert a file is so that you can make any fine tune adjustments to the image after the change. So you're not leaving it to the printer to decide and possibly mess up.
I'm not familiar with InkScape so don't know how it'll export said artwork. When you open it in Photoshop however, you will be able to see if it tacked it on there. Then you can crop if need be.
Hope that helps.
I'm trying to print a postscript file to a Dymo LabelWriter (tried a LabelWriter 450 and LabelWriter 330-Turbo), i'm getting it trough ok, but the margin seems to be way to high, 1/3 of the label isn't printable (see pic, the black square is supposed to cover the entire label over the width).
The label is 89mm on 39mm (so 252pt x 123pt)
I'm using a boundig box of 8 8 252 123 and the page orientation is set to portrait.
I even tested it with an eps-file generated from Gimp, it leaves the same area blank.
anyone has an idea why it isn't printing correctly?
EDIT:
The file can be viewed here : http://pastebin.com/c7YC5ftb
The command I use to print it on a Dymo LabelWriter is:
C:\ps\gswin32c.exe -sDEVICE=mswinpr2 -dNoCancel -dNOPAUSE -dSAFER -sOutputFile="%%printer%%DYMO LabelWriter 450" -q "C:\ps\dymo.ps" -c quit
Not without seeing the PostScript file, no. I don't see from the Dymo web site that the printer accepts PostScript input, so how are you sending the PostScript file to it ?
Added in response to edits in the question.
Well its not absolutely clear to me what you expect this to look like.
Your original comment refers to a black square, but the PostScript doesn't contain a black square, it draws a rectangle with an aspect ratio of 20:1. You have set the media up to be wider than it is long (252,123) but you then use the Orientation to rotate the content by 270 degrees. Its true this is portrait, but upside down. If you want portrait why not just set the media to be portrait ?
Simply put the origin is the corner directly above your thumb in the photograph, and I think the long and short sides of the print are reversed with respect to the actual label.
Note that the BoundingBox comment is a comment and is ignored by the PostScript interpreter so changing it has no effect.
Perhaps if you could explain what you are trying to achieve ?
Problem is solved, the printer wasn't set to accept this type of labels
If you ever have this problem go the advanced settings of your printer driver and set the label.
I need to print an image that is being returned to me through a web service (the data is returned as RAW) and I cannot for the life of me figure out how to print a graphic to a label with EPL.
The EPL manual defines the Graphic Write instruction as:
GWp1, p2, p3, p4, DATA
All of the parameters are returned to me, so I don't have to worry about calculating the height, width, etc., but my problem is that I don't know how to format the DATA.
The manual says DATA should be
Raw binary data without graphic file formatting. Data must be in bytes.
I've tried passing a binary string and a hex string, but nothing seems to work. There is no example on how to use this command in the EPL manual and after hours of searching online I have not been able to find a single example of how to use the command (i.e. example EPL commands that I can copy & paste to send to the printer).
Does anyone have an idea of how to use this command? Could you provide me with an example? (by example I don't mean a framework, code, etc., what I mean is just the plain EPL commands).
I can confirm that the data is in raw, uncompressed binary. It is also inverted-- that is, the 0 bits print as black, at least on my UPS-firmware LP-2844. I have no idea why all the examples from Zebra show the data as encoded into a hex representation.
It's worth noting that most print servers (HP Jetdirect, Lantronix LPS1-T, and almost certainly the Zebra built-in and external print servers) will form a binary connection to the printer if you spit data at them on port 9100 (using netcat for example):
nc printer_hostname_or_ip_address 9100 < test_file.txt
You get no feedback from the printer, except for the label having printed or not.
It takes my LP-2844 (UPS Firmware) printer about 5-6 seconds to print a label containing a 816 wide x 1218 tall downloaded bitmap onto a 4" wide x 6" tall label. It seems to be all imaging time: sending three labels at once is not any faster, and the network connection (through a Lantronix LPS1-T) is held open until the final label prints. That image is at the native resolution of the printer (203 dots/inch), and there is no dithering or resizing going on (I don't think EPL2 even knows how to dither or resize).
It might be possible to speed up the imaging time by optimizing the label into many smaller bitmaps (and horizontal and vertical line segments, and perhaps filled-in rectangular blocks). This wouldn't be a very hard optimization because the image is a single-bit black and white bitmap, and the code would be fairly simple. I don't know if it would really speed it up, though.
A more modern Zebra GX420 running ZPL with a built-in ethernet port ($500 online) can print the same label (with essentially the same graphic download encoding) in 1-2 seconds.
By the way, since I haven't yet actually answered the question, the raw EPL code for this is:
(a blank line)
N
q816
Q1218,20
GW10,10,102,1218,(124236 bytes of inverted bitmap data)
P
all the newlines are 0x0a (unix-style).
Maybe this will help, it has examples (and corrects an error in the manual). Also, it may be easier to use the GM command instead and just delete the image each time (see here for a stackexhange related question).
That being said, I've never gotten my Eltrons to successfully print an image (but my jobs don't require it).
Good luck!!
EDIT: Here's another link with example Perl code. They're aiming for Chinese characters but show how to print the Great Wave image (which oddly is Japanese).
I found that it is not possible to send a graphic to a Zebra printer with EPL using ASCII characters. The data must actually be sent as RAW data. So, for example, you can't send a graphic to the printer using Zebra Setup Utilities, or through any other means that cannot write RAW data from a file directly through the printer.
The only way around this I've found is to create the label as an image and send that image to the printer via a print command within your application.