I'm trying to print a pdf with Ghostscript using those settings :
var switches = new List<string>
{
#"-empty",
#"-dPrinted",
#"-dNOPAUSE",
#"-dNOSAFER",
#"-dQUIET",
#"-dPDFSETTINGS=/printer",
#"-dNumCopies=1",
#"-sDEVICE=mswinpr2",
#"-dCompatibilityLevel=1.4",
#"-sOutputFile=%printer%" + printerSettings.PrinterName,
#"-f",
pdfFileName
};
but either the pdf or Ghostscript have bad margins and while it's good when I print it to file it clips when I print it on my printer.
Is there any way to add those programatically with Ghostscript ? I tried many different solutions from first pages of google but none of them work and they seem to have no effect on the printed pdf.
When I try to print it out with Adobe or IE it magicaly adds margins as soon as I choose the printer and it prints fine.
How to achive the same with Ghostscript ?
OK well the first thing is that many of the switches you are setting have no effect:
-empty isn't a Ghostscript-understood switch, and I'm slightly surprised it doesn't cause an error.
-dPDFSETTINGS only affects the pdfwrite device, which is why it is documented in the vector devices section.
-dCompatabilityLevel only affects the output of the pdfwrite device.
-dNOSAFER doesn't have any effect, as that's the default setting.
-f is used to 'close' direct PostScript insertion begun with -c, if you don't use -c you don't need -f
Now almost certainly neither Ghostscript nor your PDF has 'bad margins', the most likely explanation for your problem is that the printer you are using cannot print to the boundaries of the page, the left/right edges, and potentially the top and bottom edges are used by the paper transport mechanism, and the printer cannot print there.
In order to deal with that, you will need to reduce the size of the image, which you can 'probably' do by setting -dDEVICEWIDTHPOINTS and -dDEVICEHEIGHTPOINTS and -dFIXEDMEDIA. Its going to be up to you to work out the correct values for width and height.
Added after the comments below
There are two parts to this problem, the first is to deduce the size of the actual available area to print on, and to scale the output to that size. The second is to then reposition the output on the media so that it is all printed. If as you say the content is significantly smaller than the media then you can ignore rescaling it, but the entire solution is presented here for completeness.
Now as previously mentioned, the first part of this is achieved primarily by creating a fixed size canvas; this is done with any of the media selection switches and the addition of -dFIXEDMEDIA.
NOTE if you alter the media size, then you must, obviously, also alter the scale of the contents, or it won't fit. So you also need to set PSFitPage, EPSFitPage or PDFFitPage depending on the type of input (very recent versions of Ghostscript can use -dFitPage no matter what the input type).
As an experiment I used the file /ghostpdl/examples/text_graphic_image.pdf and sent the output to a printer on FILE:
This command line:
gswin32 -dDEVICEHEIGHTPOINTS=391 -dDEVICEWIDTHPOINTS=306 -dFIXEDMEDIA -sDEVICE=mswinpr2 -sOutputFile=%printer%KensPrinter /ghostpdl/examples/text_graphic_image.pdf
produces output where 3/4 the image is clipped away (the content lies off the newly defined fixed canvas size). If I modify that to:
gswin32 -dDEVICEHEIGHTPOINTS=391 -dDEVICEWIDTHPOINTS=306 -dFIXEDMEDIA -dPDFFitPage -sDEVICE=mswinpr2 -sOutptuFile=%printer%KensPrinter /ghostpdl/examples/text_graphic_image.pdf
then the result is a perfect reproduction of the original, at 1/4 the size (half in each direction).
So, the first thing you need to do is establish the actual printable area of the media on your printer, then you can set the width and height correctly as fixed media, and tell Ghostscript to scale the page to fit.
However, this will still leave the printed image at the bottom left of the media. Since that's in an area that can't be printed, you need to shift the printed image until its centred on the page. As I suggested, you can do this with a BeginPage procedure. This:
gswin32 -dDEVICEHEIGHTPOINTS=391 -dDEVICEWIDTHPOINTS=306 -dFIXEDMEDIA -dPDFFitPage -sDEVICE=mswinpr2 -sOutptuFile=%printer%KensPrinter -c "<</BeginPage {100 100 translate}>> setpagedevice" -f /ghostpdl/examples/text_graphic_image.pdf
produces output where the printed image is shifted up and right by 100 points each.
I believe that a little investigation will allow you to figure out where exactly your printer is able to print, and to create appropriately sized unprintable margins.
Note that, for me, the %printer% syntax does not result in a printer selection dialog. I suspect that your code (whatever language that is) is expanding the %p, resulting in a corruption of the name. Or possibly whatever you use to fork a Ghostscritp process does it. In either event you probably need to double the % signs.
You should get this working from the command line first, then work on getting it into an application.
Related
I'm learning how to code C# from scratch. Right now, I'm learning how to build a scene on the command line and update it as necessary.
Part of what i want to do is to "scroll text as it is generated".
The scene is a square command line (Size 100 by 40) and outlined by a box of "#" characters. This is the canvas on which everything is presented.
As the user interacts via simple inputs, the program will provide textual feedback, like a text-based game.
However, unlike a normal text-based game, I cannot allow for the natural flow of the command line to move the canvas. In other words, if I allow for the command line to act naturally, then the canvas would slowly travel upwards until it's no longer visible.
I need a way to read whatever is already being presented on the screen and storing it on memory. Then, I can delete a portion of the screen an paste the previously copied information shifted upwards, making space for new information.
Here is a mockup of what I want to do:
Image 1: desirable outcome
My question is: Is there a way to "read" only a specific portion of the command space and store into memory?
I know you can store whatever is being printed at the moment of printing, or I could keep track of a certain number of previously displayed information and print it again, but I would like to "copy, then paste shifted" a portion of the screen.
PS: This is what I'm trying to avoid
Image 2: Undesirable outcome
Since the top line needs to be moved too, really the only way to do this is to clear the screen and redraw everything. Instead of printing directly to the screen, save the new line to a list, clear the screen, then print that list to the screen, together with the border.
While I haven't found a way to store a portion of the command line to a variable for later use, I've succesfully "scrolled" the text, and found a workaround to "store" it.
Simply put, Console.MoveBufferArea() allows one to select a portion of the command line buffer and move it somewhere else on the buffer.
This way I can:
-Clear whatever space i need at the top by moving the cursor to, say, (1,1) and writing a box of spaces via a string.
-Console.MoveBofferArea() the portion of the buffer a few rows upwards
-Write the new text at the bottom
As a byproduct, i can also "store" a portion of the screen for late use by:
-Setting the buffer to a wider area with Console.SetBufferSize()
-Use Console.MoveBufferArea() to the buffer portion that is outside of normal view
-Do whatever i need to do on the screen
-Use Console.MoveBufferArea() to retrieve the "stored" portion back to where i need it
-Reduce the buffer area (I could also just leave it be)
I need to enter a text to existing pdf (in top or bottom of the page) in c#.
I need to make sure that I dont overwrite any visible text or image.
Is there any way I could check an area in pdf if it contains text, image, control etc? I understand it will not be 100% accurate
You're going to need a full PDF consumer at the very least, because the only way to find out where the marks are on the page is to parse (and possibly render) the PDF.
There are complications which you haven't covered (possibly they have not occurred to you); what do you consider to be the area of the PDF file ? The MediaBox ? CropBox, TrimBox, ArtBox, BleedBox ? What if the PDF file contains, for example, a rectangular fill with white which covers the page ? What about a /Separation space called /White ? is that white (it generally gets rendered that way on the output) or not ? And yes, this is a widely used ink in the T-shirt printing industry amongst others.
To me the simplest solution would seem to be to use a tool which will give you the BoundingBox of marks on the page. I know the Ghostscript bbox device can do this, I imagine there are other tools which can do so. But note (for Ghostscript at least); if there are any marks in white (whatever the colour space), these are considered as marking the page and will be counted into the bbox.
The same tool ought to be able to give the size of the various Boxes in the PDF file (you'd need the pdf_info.ps program for Ghostscript to get this, currently). You can then quickly calculate which areas are unmarked.
But 'unmarked' isn't the same things as 'white'. If you want to not count areas which are painted in 'white' then the problem becomes greater. You really need to render the content and then look at each image sample in the output to see if its white or not, recording the maxima and minima of the x and y co-ordinates to determine the 'non-white' area of the page.
This is because there are complications like transfer functions, transparency blending, colour management, and image masking, any or all of which might cause an area which is marked with a non-white colour to be rendered white (a transparency SMask for example) or an area marked with white to be rendered non-white (eg a transfer function).
Your question is unclear because you haven't defined whether any of these issues are important to you, and how you want to treat them.
In my C# application I am trying to show a PDF document in a navigatable window with options to zoom, pan, etc. I'm using Ghostscript.NET. It looks like for example Adobe Acrobat Reader is able to render just the given portion of a page, judging by the speed it is going at. I only found the means to rasterize entire page, which is not too practical, especially in high zoom levels. Is it possible to first crop out a rectangle (based on calculated corner coordinates) and then quickly rasterize it without the rest of the page?
I tried following command:
gswin64.exe -sDEVICE=pdfwrite -o C:/work/marked.pdf -dUseCropBox -c "[/CropBox [300 400 400 600] /PAGES pdfmark" -f "c:\big boat.pdf"
Which works, technically speaking, but as far as i understood, the document must be defined without its own crop box, otherwise it won't work.
In order to add a CropBox (to a page) you can use an EndPage procedure, by sending a pdfmark at the end of the page, instead of the beginning, it should overwrite any pre-existing CropBox.
Or more simply, you can simply render a portion of the media directly, which sounds like what you want to do in the first place and avoids a (potentially lengthy) processing step.
Set the media size to the area you want to be rendered. For now lets assume you want a 2 inch square, 1 inch up from the bottom of the page. So we start by making the media size 2 inches square, and fixing it so any input can't change it:
-dDEVICEWIDTHPOINTS=144 -dDEVICEHEIGHTPOINTS=144 -dFIXEDMEDIA
If you add that to the command line you use to render the PDF file you will see that you get a 2 inch square rendered. Of course right now that's the bottom left corner of the page, so now we need to shift the media position so that the portion we want lies on the page. To do that we use PostScript, specifically the PageOffet key in the page device dictionary:
<</PageOffset [-72 0]>> setpagedevice
Note that we are shifting the bottom left corner of the page, which is why we use -72, we want the corner to go down.
because we are using PostScript we need to introduce it with the -c and -f switches:
-c "<</PageOffset [-72 0]>> setpagedevice" -f
So the whole command line becomes:
./gs -dDEVICEWIDTHPOINTS=144 -dDEVICEHEIGHTPOINTS=144 -dFIXEDMEDIA -c "<</PageOffset [-72 0]>> setpagedevice" -f input.pdf
If you really want to add a CropBox and produce a PDF file then you need to add an EndPage procedure, which will add a CropBox to every page individually:
./gs -sDEVICE=pdfwrite -o ./marked.pdf -c "<</EndPage {0 eq {[/CropBox [300 400 400 600] /PAGE pdfmark pop true}{pop false}ifelse}>>setpagedevice" -f "c:\big boat.pdf
I'm trying to generate a PDF via code because not all actual PDF .NET libraries support the new Windows Runtime for Windows/Windows Phone 8.1.
The PDF is saved correctly, with only a bug of stream position count that I can fix easily, but, as you can see, the text doesn't wrap if line is too long.
I tried with PDF NewLine char (\n), but C# automatically convert it in the input string
Also, I can't understand the position of lines or objects to put into the document, because I follow this guide online that talk about a reversing axis disposition (x for height and y for width), but seems I didn't catch the right methodology (I put in my code a constant left position, at 40, and a variable top descreasing value (from 600, I'm not manage now the multipage if the value is less than 0).
This is the code of PDF generated:
http://pastebin.com/ZkZmbJdM
(Sorry if I use Pastebin, but using this editor Code function the code seems to be unformatted for special characters used for it)
Where am I doing wrong?
PDF is a graphical format trying to make you think it's a document format. But nope, it's just like drawing with GDI+ for instance. This is the reason why it can achieve the same rendered output across many platforms/programs/etc as opposed to text flow formats like doc/docx. And also, this is why it can really render anything.
So, as opposed to document formats, it is the responsibility of the program that generates the PDF to get the layout right. Think of it just as if you'd draw with GDI+.
In documents like docx or html, it's the rendering program that has to do the layout work. With such document, you just write text and the viewer will take care of laying it out.
Your PDF library certainly has the necessary code to measure the text length. Maybe even it has some code to provide some layout capabilities. You'll have to use these functions to do the layout.
anyone can please tell me the code how to print documents on dot matrix printer in C# windows application.
You can print to dot matrix "graphically", which is built-in in Windows, albeit slower.
But if you only want to print pure text with simple formattings, you need to send escape commands to your dot matrix printer, which is faster than graphical printing. Different printers has different escape commands.
Here are typical escape commands(for epson): http://www.printfil.com/manualen/c5.htm
This might help: https://web.archive.org/web/20051212193242/http://sacpcug.org:80/archives/0306/prc0603.html
What I do in VB6 then was to print to Generic / Text Only printer, you open the PRN or LPT1 as a file handle, then print escape commands on the file handle, all escape commands will be redirected to whatever printer is attached to LPT1 or PRN. You can do the same thing with C#, just open the PRN or LPT1 as a file, then print to it.
To add Generic / Text Only printer, Control Panel > Printers > Add Printer. On manufacturer, select Generic, then on printers, select Generic / Text only.
You can do the same (printing on Generic / Text Only) for Zebra printers which have their own escape commands for printing bar codes, which is faster than letting Windows print to it graphically.
When you print to an inkjet or laser printer, you generally do not use built-in fonts of the printer. You use Windows fonts. What happens is that the printer driver either builds an image of pixels (including the text) and sends it to the printer, or sends commands designed to draw lines, spline curves, and other shapes to the printer, with fonts expressed as lines and splines (outlines).
When you print to an older dot matrix printer, you can do it that way, but it’s slow. Each line of text has to be “built” from pixels, and often the lines of text do not match up with the passes of the print head (especially for fonts much larger or smaller than 12-point).
The old way of using these printers, the way they were intended, was to send the actual ASCII codes of the text to the printer. Send the number 65 (decimal), and you get a capital (upper-case) “A” for instance. The number 49 (decimal) would print the digit “1” while the number 32 would be a blank space, 33 an exclamation point (“!”), and so on. One byte = one character. The dot-matrix printer had its own built-in font, and would look the ASCII code up in its font ROM, and from there determine the exact timings of which print wires would have to strike the page exactly when to produce those letters.
By using ESCape codes, you could specify such effects as pseudo-boldfaced (basically striking the letter twice, with the second copy shifted to the right by only one dot width), double-wide (striking each column of wires twice in a row for each one time that it would normally be struck, thus doubling the width of the letter), underline (striking the bottom print wire throughout regardless of whether the letter shape calls for it at that point or not), and so on.
The printer’s own ROM handled all of these mechanical details about print wires and such. All your program had to supply is the actual ASCII codes of the text (including control codes such as the number 13 [Carriage Return aka CR] to return the print head to the left margin [or, for a bidirectional printer, prepare to print the next line in the reverse order of the previous line], usually followed by the number 10 [Line Feed aka LF] to roll the paper up one line to prepare for printing the next line).
If you wanted to print in fancy fonts that the printer didn’t have, or print graphics, you had to use an ESCape code to set the printer into “graphics mode” in which you basically sent bytes whose bits would specify to fire the individual wires of the printhead under direct program control, rather than looking up character shapes in the printer’s Font ROM. When you print normally from Windows using a printer-specific driver, this is usually what happens.
For daisy-wheel or other fixed-character printers (e.g. IBM Selectric type-ball mechanisms), the ASCII code would spin the wheel or ball to the proper position and then strike the ribbon and thus print the letter on the page, or send the right hammer up to hit the ribbon and thus the page (TeleType or old typewriter mechanism). It was not possible to do pixel graphics with these except by printing repeated periods and micro-advancing the print head and paper the width/height of a period instead of a character / row of text, respectively (which would generally wear out the period character of the daisy-wheel or ball really quickly, so many of them had metal-reinforced periods for that very reason).
How is this different from printing on inkjet or laser printer?
MSDN: Printing Overview
Preview and Print from Your Windows Forms App with the .NET Printing Namespace
Whilst it wasn't in C#, I have written Access reports that used the native fonts of an Epson printer. It was a few year ago - using Windows XP - but when the printer was selected as the default it was possible to choose the "native" fonts of the printer via the font chooser.
It was pretty neat - I could use any font I liked for the headings, which were slow to print. Then I could select the native printer font for the detail rows, which were fast. Doing it that way I had to be careful that all the "native" font detail stauff had exactly the same vertical alignment, otherwise it became slow again.