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.
Related
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.
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...
I would like to reduce my barcode's size but still be the same ratio like picture below.
From
Original Size
To be
Reduced Size
Here is my ZPL code.
^XA
^FO50,20
^BY2,2,20
^BCN,,N,N,N,D
^FDZWW011601512345^FS
^XZ
Please help me how do I deal with it?
Thank you.
This website is great for testing against: http://labelary.com/viewer.html.
Assuming you don't want the position to move it should just be changing
^BY2,2,20
to
^BY1,1,10
The API Reference guide can be found https://www.zebra.com/content/dam/zebra/manuals/en-us/software/zpl-zbi2-pm-en.pdf
Don't forget to take into consideration the print density, i.e. at 152 DPI you probably want something like
^FO150,20
^BY1,1,10
But at 600 DPI
^FO550,80
^BY4,1,40
EAN-13 Text Modifications
If you are using the the inbuilt EAN-13 text function i.e. ^BEN,40,Y,N you can't modify the text. It is to a standard. You can however add your own text e.g.
^XA
^FO100,20
^BEN,40,N,N
^FD011601512345^FS
^CF0,48
^FO90,80^FD011601512345^FS
^XZ
^BEN,40,N,N The first N tells the printer to not generate the number underneath.
^CF0,48 Is the select font function of the printer, its first parameter is a default printer font (can be found in the Standard Printer Fonts section of the link above). The second parameter is the font height. If needed there can be a 3rd parameter which alters the font width, though isn't needed.
^FO90,80^FD011601512345^FS Sets the field origin of the string starting at the location defined by ^FO. ^FDXXXXXXXX^FS draws the string.
I print a text using ZPL but they are printed incorrectly. It has gaps in the middle. They are printed correctly to the real printer via the ZebraDesigner. But they are wrong when printing via ZPL:
^FT246,70^A0R,16,16
^FB900,2,,
^FDMaisstaerke, Austernuce, Cashewnuss,Pilz, Mais, Lattich, Pack Choi,Sojasprossen^FS
It is printed as 'Maisstaerke, Austernuce, Cashewnuss,Pilz, Mais, Lattich, Pack Choi, Sojasprossen'
(there is a big gap after 'Mais,').
http://screencast.com/t/sTiaxC3cMg
http://screencast.com/t/0QkypnsPyF89
Please help.
Thanks
I'm unable to reproduce the issue, but the field block width seems rather large; you didn't specify any label dimensions in the original post. If you use the following code--a combination from the original post and your comments:
^XA
^PW560
^LL560
^LS0
^FO246,70^GB28,300,,^FS
^FT246,70^A0R,16,16 ^FB300,2,, ^FDMaisstaerke, Austernuce, Cashewnuss,Pilz, Mais, Lattich, Pack Choi,Sojasprossen^FS
^PQ1,0,1,Y
^XZ
I can reproduce what is possibly the issue--the field block automatic word wrapping--by reducing the field block width to 300 dots.
I also drew a box around the block for visualization. You can test in on the Labelary Viewer.
Finally, if you're somehow composing the data make sure there are no special (non printable, such as tab, non-UTF-8 or accented) characters in it, and if so, you will have to pre-escape them.
I'm trying to output RTF (Rich Text Format) from a Ruby program - and I'd prefer to just emit RTF directly without using the RTF gem as I'm doing pretty simple stuff.
I would like to highlight specific characters in a DNA sequence alignment and from the docs it seems that I can either use \highlightN ... \highlight0 or \cbN ... \cb1
The problem is that I cannot get \cb to work in either Word:Mac 2008 or Mac TextEdit (\cf works fine so I know it's not a color table issue)
\highlight does work but seemingly only with two of the possible colors (black and red) and \highlight does not use the custom color table.
By creating simple docs in Word with character shading and saving as RTF I can see blocks of ridiculously verbose RTF code that presumably does what I want, but it is so impenetrable that I'm not seeing the wood for the trees.
Part of the problem may well be that Mac Word is just not implementing RTF properly. I don't have a Windows version of Word handy.
Anyone know the right way to shade blocks of text?
Thanks
--Rob
There is a note in the RTF Pocket Guide that says MS Word does not implement the \cb command. It says MS Word uses \chshdng0\chcbpatN (where "N" is the color number that you would use with \cb). The book recommends using something like the following for compatibility with programs that implement \cbN and/or \chshdng0\chcbpatN: {\chshdng0\chcbpat5\cb5 text}.
Note: The copy of the book I have was published in 2003, so it might be a bit out-of-date.
The sequence of RTF commands that seems to be most universally supported by RTF-capable applications is:
\chshdng10000\chcbpatN\chcfpatN\cbN
These commands:
set the shading to 100 percent
set the pattern foreground and background colors to the color from the color table (we're not actually specifying a shading pattern)
set the character background to the color from the color table
Word was the most difficult application to properly render background colors in:
Despite what the latest (1.9.1) RTF spec says, Word 2013 does not resolve \highlightN colors from the \colortbl. Instead, \highlightN maps to a predefined list of colors. It looks like those colors come from the 1.5 version of the RTF spec.
Regarding \cb, the 1.9.1 spec contains this helpful pointer at the end of the section on Color Table:
Note: Windows versions of Word have never supported \cbN, but it can be emulated by the control word sequence \chshdng0\chcbpatN.
This is almost a useful suggestion, except that if you read the documentation for \chshdngN:
Character shading. The N argument is a value representing the shading of the text in hundredths of a percent.
So, 0 turns out to not be a very useful value; 100 / 0.01 gives us the 10000 we used in the sequence above.
Use WordPad to create RTF documents, not Word. WordPad creates much simpler documents, i.e. approaching human-readable.
I use WordPad every time I need to display formatted text in a WinForms application, and need something that the RichTextBox control can handle being assigned to its Rtf parameter.