We Keep Coding

Crystal Report Barcode 128 converter

i need to print a Barcode128 in Crystal Report, with a c# windows form.
The input string is like this:
123456-abcdef-abc
I use barcode.dll to build the formatted 128barcode:
string encodedText = BarCode.BarcodeConverter128.StringToBarcode("123456-abcdef-abc");
string path = #"D:\Projects\mypath\myreport.rpt";
ReportDocument cryRpt = new ReportDocument();
cryRpt.Load(path);
cryRpt.SetParameterValue("#inputString", encodedText);
crystalReportViewer1.ReportSource = cryRpt;
crystalReportViewer1.Refresh();
in crystalReportViewer1, the textbox font is "Code 128"
it shows a barcode, but it is not readable from any barcode reader.
What's wrong?
Here is the barcode generated:
Image updated! the same issue.
Thanks in advance for any help.

Here is an image demonstrating how a Crystal Report UFL renders the barcode without any font dependencies. The UFL generates the image on the fly and directs an image object Graphic Location expression to the resulting image file.
Barcode Image Generated as Image via CUT Light UFL

You have what I call a "blur code". The software in Crystal Reports, is attempting to make your image look smoother using anti-aliasing. Another concern I have is that even if the image were sharpened, it would not scan due to the bars and spaces being the wrong width.
Here is an image zoomed in on your barcode and a clear image of your string represented in Code 128B overlain. The bars and spaces do not line up. In other words, even if the symbol in your attached image were clearer, you may even have an unreadable barcode. What I suspect is that your barcode may only be showing the right half of the entire barcode and the left half is being cut off by some bounding box that is not wide enough. Your barcode.dll may also be using Code 128C on the first 6 characters to save two characters in the width of the barcode because even if you scale the top barcode to line up character-wise, the checksum character does not seem to match.
I don't know much about Microsoft technologies, so I can't help you with that, except to say that you may want to try making the font something ridiculously huge and scaling the page to see if that fixes the anti-aliasing issue.
I'm hoping you can flip a switch in Crystal Reports that will get it to stop auto-anti-aliasing, then fix the bounding box issue.

CEF Sharp: printing resolution

I'm using CEFSharp (the C# wrapper for CEF) to print a web page to PDF, like this:
browser.PrintToPdfAsync(#"C:\out.pdf", new PdfPrintSettings
{
BackgroundsEnabled = true,
HeaderFooterEnabled = false,
Landscape = false,
MarginType = CefPdfPrintMarginType.Custom,
MarginBottom = 0,
MarginTop = 0,
MarginLeft = 0,
MarginRight = 0,
PageWidth = 210000,
PageHeight = 297000
});
However, the problem is that the resulting PDF is very blurry when compared to manually printing the same page in the "real" Chrome application.
I've made a comparison screenshot to show the difference:
(open it at full resolution to notice the difference)
Basically, as you can see, CEF seems to be compressing images and other non-vector graphics much more than the native Chrome printing function.
Ideally, I'd like to disable compression completely, or at least it bring it closer to native Chrome levels. Can it be done?
Also related: is there was a way to print at higher resolution? The PdfPrintSettings class only accepts width and height measurements in microns, but I don't see any way to set the rendering definition (DPIs)... is it possible?

I guess images are blurry because PDF gets printed as a preview:
https://bitbucket.org/chromiumembedded/cef/src/6006f77bd9e030e9b456e180798c7c13d19cae08/libcef/browser/printing/print_view_manager.cc?at=master&fileviewer=file-view-default#print_view_manager.cc-110
It was my pull-request which added PDF printing to CEF. Printing as a preview seemed good enough for me. It allowed to write less code and implement less components involved in PDF printing.
It's also possible that some other settings make images blurry. For example:
https://bitbucket.org/chromiumembedded/cef/annotate/6006f77bd9e030e9b456e180798c7c13d19cae08/libcef/browser/printing/print_view_manager.cc?at=master&fileviewer=file-view-default#print_view_manager.cc-50
It needs some debugging. In order to do that you most likely would need to build CEF from source:
https://bitbucket.org/chromiumembedded/cef/wiki/BranchesAndBuilding
DPI can not be set because Chromium itself does not have such setting in its PDF print dialog. Although you can try to set different DPI options here:
https://bitbucket.org/chromiumembedded/cef/src/6006f77bd9e030e9b456e180798c7c13d19cae08/libcef/browser/printing/print_view_manager.cc?at=master&fileviewer=file-view-default#print_view_manager.cc-53 But it's possible that those settings are just ignored by Chromium.

Ghostscript clips a pdf file

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.

What type of image filtering/processing do mobile PDF scanners use to convert a captured image into a monochrome/black and white image?

I am trying to implement my own monochrome/black and white filter in C# to scan text documents. My approach is to apply a threshold filter on the captured image. However, I often run into the problem that the varying brightness on the image causes a ''shadowing effect'' on the processed image. Refer to the link below (it is pretty blurry but it should suffice). The image to the far left is the original image. When I apply my threshold filter, I get the same result as the image in the middle; some of the text becomes unreadable because the brightness of the image varies, so some portions become really black or really white. However, with the right filter, you can obtain the processed image to the right where everything looks crystal clear.
https://www.google.dk/search?q=monochrome+image+processing&espv=2&biw=1706&bih=859&source=lnms&tbm=isch&sa=X&ved=0ahUKEwir8vXlhIzPAhUFiywKHeSBC1wQ_AUIBigB#imgrc=4UTzoIpyqTkwrM%3A
I would like to know what the process is to obtain the image to the far right. Another example can be seen in the image below. It shows a sample mobile PDF scanner in use. Scanning the image results in a very nice black and white image, where the text can be easily read and no ''shadowing'' occurs on the image. Does anyone know what this process is or what it is called? It is very often used in mobile PDF scanning applications. Thank you in advance.
EDIT: The filter is called ''Adaptive Thresholding''. You can use the BradleyLocalThresholding class to implement the filter, or you can write it yourself (which is what I did). Please refer to my response to the comment by Yves Daoust down below.

You need two ingredients.
One is "background reconstruction", i.e. retrieving the intensity of the white sheet "under the characters", for instance by morphological opening.
The other is "shading correction", i.e. compensating the unevenness of the background illumination by comparing to the reconstructed background, for instance by subtraction.
This will "flatten" the image, making it perfectly amenable to global thresholding.

A simple method is to convert the image to grayscale and then convert it to B/W using an error diffusion algorithm such as Floyd–Steinberg dithering.

PDF doesn't wrap text lines automatically & respect line position

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.