Consider the below ZPL code.
^XA
^BY2,2,80
^FO50,50^BCR^FD3079+Plate-SS-14 # 44^FS
^XZ
Using the online viewer at http://labelary.com/viewer.html shows you vertically rotated bar code with label beneath and everything appears to be fine.
However, when I print the label the bar code is not scan-able because the lines of the bar code are too thick (see below images). Removing the rotate flag from ^BCR and making it ^BC fixes the issue and the lines are perfectly normal and scan-able. I have tried numerous different methods to rotate the code with no success and can't wrap my head around as to why the lines become thicker when rotating a bar code.
Does anyone have any insight as to why this happens?
Broken Rotated Barcode Image
Working (not rotated) Barcode Image
In my case, the solution was the printing speed being too fast. Another potential solution would be to turn down the darkness or temperature of the printer itself if it's an option in the settings.
Simply opening my respective zebra printer's printing preferences showed me a Print Speed setting which was set to 12.7 cm/s. Reducing it down to 10.1 cm/s fixed the problem.
Adjust the Darkness of the printing and/or the speed of the printing. that should solve your problem.
I think it is a problem with your use of the PNG file that the site generates. The PNG file generated includes enough whitespace in the front (top) quiet zone of the symbol to scan, but if you use the Windows system viewer to print the barcode and print in full size, it slices off the top-most bars.
Try embedding the PNG file into a document, setting the photo size to less than full page, or use the PDF file.
Related
I have a ZEBRA ZT411 label printer. I had a 203dpi printhead and changed it to 300dpi. I installed the ZT411 300dpi ZPL driver. The printer is now incorrectly calibrating the label. It doesn't push it to the edge so I can tear it off, but it's still tucked inside. It only prints on the bottom of the label. In size 40mm. The size of the label is larger. I've tried everything. Where is the mistake of how this could be changed?
I don't think that's an issue with the label because in that case, you would only have a smaller printout, but no calibration issues.
If you change the printhead with a different resolution, you also need to replace the pulley and the belt because the amount of paper the printer will push when you print a 203 dpi label and a 300 dpi label, is different.
Check here, page 2: you'll see the printhead part number (P1058930-013) which is the one you've used and the conversion kit (P1058930-022) which include the printhead, but also the mentioned pulley and belt, and that's the one you need.
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...
We are running cobalt with openGL enabled, and the graphics appear to display correctly under 1920x1080 resolution.
But once in a while, some icons in the "Settings" menu may have unexpected vertical lines on top (as shown in the picture).
We are guessing the icons are created from TTF font file, but we are not sure how it is rendering onto the screen.
We want to dump the icons to file at the following points to check what went wrong.
When the icon is actually converted to image.
When the icon experience further modification. (eg, color change, bolding, etc)
When the icons are rendered onto screen canvas.
Would really appreciate if someone can help to point out where in source code these events may be happening.
I guess the first question is: are you running the stable branch or the experimental branch of Cobalt?
Beyond that, yes, the icons are created from a TTF font file that is downloaded remotely. The icon itself is simply a character that is converted into a glyph, like the text above it, albeit at a much larger size.
I believe that the logic that you're looking for is within RenderText() in cobalt/renderer/rasterizer/skia/render_tree_node_visitor.cc. SkCanvas::drawTextBlob() is passed the glyph and color information that it uses to render the icon.
The specific glyph that is being used looks correct, but the location where the render_tree::GlyphBuffer representing it is created is TextShaper::CreateGlyphBuffer() in cobalt/renderer/rasterizer/skia/text_shaper.cc.
If I have the axis label $x_\textrm{ABC}$, the ABC is way too big. I tried $x_\textrm{\scriptsize ABC}$ and $x_\textrm{\tiny ABC}$, but that prevents the LaTeX code from being interpretted (I end up seeing the raw code instead of the formatted math). How does one shrink the subscript text size when the subscript is a name that needs to be spelled in text mode?
I posted this to usenet yesterday, but no response so far.
I also tried to modify the text in Acrobat Pro, but I can't actually highlight the individual series of characters (it's the y-axis label).
Finally, I tried to modify it in inkscape, but same problem.
A respondent at the usenet link provided the answer: To use \mathrm instead of \textrm. It looks way better.
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.