When trying to save any barcode symbology as an EMF file with the .SaveAsEmf() method, I have to choose a very large font size to make the number read properly. Otherwise, the number is unreadably small. However, when increasing the font size, there is a lot of whitespace at the bottom of the barcode image file. It does not matter what font is used: all fonts have this behavior. Setting the font size to 192pt seems unreasonable, but it’s what works. I know it’s also a function of the resolution. If the resolution is set to 300, for example, the font size would need to be 48.
Another note: resolution is a little odd when dealing with EMF files because it’s a vector format, which is supposed to be independent of resolution. How does setting a resolution matter for SaveAsEmf()?
The files in the attached ZIP were generated with the following code: I am using UPC-A to more easily show the issue.
BarCodeBuilder b = new BarCodeBuilder(“850006000029”);
b.SymbologyType = Symbology.UPCA;
b.CodeTextFont = new Font(“OCR B Std”, 16.0f);
b.CodeTextSpace = 0.5f; // This appears to have no effect
b.GraphicsUnit = GraphicsUnit.Millimeter;
b.xDimension = 0.66f;
b.BarHeight = 45.70f;
b.Resolution = new Resolution(1200.0f, 1200.0f, ResolutionMode.Customized);
b.SaveAsEmf(“sample16pt.emf”);
b.CodeTextFont = new Font(“OCR B Std”, 192.0f);
b.SaveAsEmf(“sample192pt.emf”);
Any help looking into this issue would be greatly appreciated.
Hi,
Many thanks for contacting Aspose support. We are currently reviewing the concerns you shared and will write back to you soon with more updates.
If there is anything else we could do to help during the interim, please be sure to let us know.
Thanks for the reply and I look forward to hearing back.
For further information I neglected to include (I have another thread which had a followup reply), these samples are with the .NET 7.1.0 version from the NuGet repository. I do have a valid license, and threw together the sample code/images quickly. If you need further samples without the evaluation mark, I can generate. However, no difference in the samples.
Hi Tony,
Thanks Imran. The font file is the one I sent to you via e-mail a short time ago for the other thread (UPC-A Barcode Last Digit Cut-Off…). Same font file for this related but separate issue. Please let me know if you received it.
By “minimum possible”, do you mean the resolution? The xDimension and BarHeight are not changeable: there are other combinations of those that greatly affect the UPC-A generation. So if you mean setting the Resolution to something smaller, like 100 DPI, then I get it and will test it out.
One note: the EMF format isn’t a bitmap/raster format but a vector one. I’ll look at the Bitmap class, but I suspect it would generate a bitmap file as an EMF, which is not what I am looking for.
Hi Tony,
Hi Tony,
abadger:Setting the font size to 192pt seems unreasonable, but it’s what works.
Thanks for checking back. The sample file ZIP has an example of when a normal font size is used, like 16pt. “sample16pt.emf” The whitespace does not appear then, but the HRI string is incredible small.
As a summary:
1200 DPI with 16pt font. No whitespace, but the font size is way too small.
1200 DPI with 192pt font. Lots of whitespace, and the font size is correct.
Also, in my initial post I made the comment that defining a DPI for vectors is odd because vectors are independent of resolution. I think the EMF format does contain some resolution information in the metadata to help a program opening up the EMF file to display it. But the actual vector information contained in the EMF file is independent of the DPI. No matter what resolution I use, the overall size of the files never changes (about 8KB). But the apparent size when opening them up does. Hope that helps out a bit in figuring this out.
imran.rafique:Please note, when you are setting the resolution up to 1200 DPI, it is increasing the actual barcode size in respect of height and width (we're not talking about the barcode image file size) and the code text string size remains up to 16 PT. It looks small because the actual barcode size is larger.
Hi Tony,
Thanks for the update, Imran. Am I correct in assuming that BARCODENET-34229 is also considered closed? That was for the investigation of the problem, and appears that was turned into the 2 issue IDs BARCODENET-34242 and BARCODENET-34243.
Just making sure nothing is missed for the next release. Thanks!
Hi Tony,
The issues you have found earlier (filed as BARCODENET-34243;BARCODENET-34242) have been fixed in Aspose.BarCode for .NET 7.2.0.
This message was posted using Notification2Forum from Downloads module by Aspose Notifier.
The issues you have found earlier (filed as BARCODENET-34229) have been fixed in Aspose.BarCode for .NET 7.3.0.
This message was posted using Notification2Forum from Downloads module by Aspose Notifier.