I have the following text:
$3.00 x 2 = $6.00
When I apply direction: rtl; to the body of the page, this text displays as
x 2 = $6.00 $3.00
Can anyone explain why it's displaying this way?
A full answer to your question would have to explain how the Unicode Bidirectional Algorithm works, and it's immensely complicated.
From my limited understanding, the algorithm has detected that "x 2 = $6.00" and "$3.00" are two separate "runs" of text that should be displayed in left-to-right order. As the whole block is right-to-left, you see the two runs in RTL order.
It's not clear if your question is trying to solve a problem, or if you're just curious. However, if you need to display your equation fully LTR, but in the middle of some other RTL text you can use Unicode control characters.
e.g. The text in this RTL block will display the text between the two markers as a continuous run of LTR text.
<body dir="RTL">
$3.00 x 2 = $6.00
</body>
Simpler in most cases (if you can) is to isolate the LTR text with HTML elements, e.g:
<body dir="RTL">
<span dir="LTR">$3.00 x 2 = $6.00</span>
</body>
As I can't read Arabic or Hebrew I can't tell you how your example text should appear when embedded into RTL script. However, you do have control over the rendering.
Related
Within an Ace editor, it is easy to find the number of lines in the edited document with the following:
myEditor.session.getLength();
But languages like JSON or XML can be "folded." That is, children properties or elements can be collapsed so only one single line is displayed for the parent.
Is there a way to get the number of lines actually displayed? Something like the following:
myEditor.session.getVisibleLength();
Note: the ultimate goal is to have an editor that adapts its height on the page to the content it displays (if lines are collapsed, then it should shrink, and if collapsed lines are expanded again, it should increase its height.)
UPDATE: After a user's response, I use the following. This is not the answer to the specific question I asked above, but rather the perfect answer to what I was trying to achieve overall:
const myEditor = ace.edit(elem, {minLines: 5, maxLines: 50});
To automatically change the height of the editor use maxLines option, but don't set it to a very large value as performance depends on the number of displayed lines.
I am trying to right justify a bar code I am printing using ZPL from a .Net program. Here is my current code:
^FO10,50^FB500,1,0,R,0^AO,40,40^BY3^BCN,100,Y,N,N^FD1234567^FS^XZ
The Field Block seems to be ignored when working with a bar code, but for text it justifies it correctly. Any ideas?
Newer Zebra firmware supports a third parameter on ^FO and ^FT. If you want to right justify something, specify the right edge as the x parameter, and include a 1 as the third parameter.
^XA
^BY3
^FO85,30^GB500,450,3^FS
^FO100,50^BCN,30,Y,N,N
^FD>;12345678^FS
^FO100,120N^BCN,30,Y,N,N
^FD>;123456^FS
^FO100,190^BCN,30,Y,N,N
^FD>;1234^FS
^FO570,260,1^BCN,30,Y,N,N
^FD>;12345678^FS
^FO570,330,1^BCN,30,Y,N,N
^FD>;123456^FS
^FO570,400,1^BY3^BCN,30,Y,N,N
^FD>;1234^FS
^XZ
We had the same issue at our company. The barcode doesn't respond to the Field Block. Based on your example since you are using ZPL commands directly to generate your barcode (as opposed to an image of a barcode), you could do something similar to how we did. We know roughly how wide the barcode is going to be based on the data we write to it. So we created a method to determine the x-axis location of the barcode based on our also known label widths.
For example: We use the s4M printers and estimate the full label width to be about 780 dots wide. So in order to left/center/right justify, we take the rough barcode (estimated) width and calculate accordingly (left is set to xaxis = 0, center is set to xaxis = ((780 - barcodeWidth) / 2), and right justified would be xaxis = (780 - barcodeWidth). It isn't a perfect solution but is very close at least for our needs. You could certainly be more precise in your algorithm by looking at more barcode setting information like the data square size, columns, rows, etc... depending on your needs.
If you were to come up with a solution of generating an image of a barcode (which is what we are also trying to come up with now) then you should be able to easily get the width of the barcode image using build in .net graphics functionality.
I'm looking for any java library which would help in transforming a piece of text into it's appropriate RTL representation.
For e.g. the hebrew/arabic text when read from a file would be in the LTR representation, however after the transformation it ought to be shown in it's RTL format.
The requirement comes up since in the case of html's we can specify the dir as rtl or ltr. However when we want to have a text variant or a sms variant of the text, the stylesheets don't come into play at all.
There are two issues that come into play with RTL content. The first is the right alignment of the display. There's nothing you can do about that unless you have control of the output routines that are being called.
The second issue, which is arguably more important, is the base directionality of the text. This you can control to a certain extent by adding bidirectional formatting characters to your content.
For example, given a string in s, you could set the base direction to RTL, with something like this:
String[] lines = s.split("\n");
StringBuilder sb = new StringBuilder();
for (int i = 0; i < lines.length; i++) {
sb.append("\u202B"); // right-to-left embedding
sb.append(lines[i]);
sb.append("\u202C\n"); // pop directional formatting
}
s = sb.toString();
What this is doing is splitting the text into multiple lines, then adding a right-to-left embedding character at the start of each line, and a pop directional formatting character at the end of each line.
The reason it is done line by line is because the embedding override only lasts for the length of the paragraph.
Example code on Ideone.com
Markup example for comparison
I am developing a Windows Mobile App that requires printing into a Zebra printer. Problem is, I do not have the printer with me here in my country since the client did not provide any.
My approach was to design a label first in ZebraDesigner2, then print out the label into a text file. Printing the label to a text file instead of a printer sends out the ZPL Code to produce the label I was trying to print. Hence, I can generate ZPL codes faster by designing a label first then seeing the ZPL code. Kinda like having a drag and drop GUI with a background XML.
Say that I have this simple label that contains this text:
Hello World!
If I print this in ZebraDesigner2 it would be written to my text file as:
CT~~CD,~CC^~CT~
^XA~TA000~JSN^LT0^MNW^MTT^PON^PMN^LH0,0^JMA^PR5,5~SD15^JUS^LRN^CI0^XZ
^XA
^MMT
^PW609
^LL0406
^LS0
^FT1,29^A0N,28,28^FH\^FDHello World!^FS
^PQ1,0,1,Y^XZ
My main question is, which one do I include in my C# Code if im going to send this code to the printer via my Windows Mobile C# app? Do I include the part with ^XA until ^XZ? I believe that CT~~CD,~CC^~CT~ should not be included in my code If im not mistaken.
Late answer, but since this is getting viewed...
The CT line and first set of XA..XZ sequence sets up the modes, label length, printable area, etc.
If you remove those, it will take those settings from the label/printer settings, which is usually what you want. The printers can sense the length and width of the label.
Leaving them in can cause big problems, because if you define the printable area in your label, and then the next label type submitted does not, it will use the settings you have defined -- which can cause blank areas in the label, eg. cutoff USPS Label barcodes that are printed after your Zebra Designer custom labels.
Found this out the hard way - leave those out, and you should leave out of the remaining XA..XZ sequence the MMT, PW609, LL0406, and LS0 as well - your Hello World will not be affected.
If you really want to limit the area printed to, set up margins inside the printable area, etc, refer to the manual.
you have to look at the programmers guide before you remove anything of the code. The CT~ command for example changes the control prefix.
Search the internet or zebra.com site for "ZPL Programming guide".
So, leave the text file as is and then include that into your windows mobile application.
PS: zebra offers SDKs for label/receipt printers: http://www.zebra.com/gb/en/products-services/software/adapt-software.html
PS2: without a test printer you may get bad final results.
I'm using iTextSharp to fill in some stamper AcroFields.
stamper.AcroFields.SetField("Title", "Lipsum");
I created the pdf in illustrator and the form fields with Adobe Acrobat X Pro. The problem is that although the text fields are the width of the page, in the saved pdf the text wraps at about 1 third of the width.
Another question would be if it's possible the have the textfield autoSize in height, or a way to handle the overflow of the text.
1) I'd like to see that PDF. I suspect the fields aren't as wide as you think they are.
2) You can set a field's font size to zero to enable "auto sizing", which works both within Reader and iText. However, it sizes to the actual field size, not what you think it might be.
I'm guessing you drew a spiffy form field background in Illustrator, then put a field over it in Acrobat Pro, but didn't size the field width to match the spiffy illustrator background. Could be wrong, but that's my hunch.
That's the flattened PDF. Can I see the original with the form field still intact? Sorry I wasn't more specific. None the less, I can learn a little from reading this PDF:
Looking at the bounding boxes for the flattened field XObject and it's internal clipping rectangle, it looks like it should be using most of the page:
The page is ~600 points wide by ~850 tall.
The flattened field XObject is ~560 points wide by ~100 tall.
I wonder if there's some non-standard carriage return characters in your text that iText picks up on by Acrobat does not...
Anyway, I'd like to see the unflattened PDF. Filled in is good, but not flattened.
Okay, looked at the template. I don't see anything that would cause the line breaking you're seeing... which makes me think my second guess was right: new line characters.
Looking at the text layout code might give me a hint. Each of your lines of text goes like this (for example):
1 0 0 1 2 88.24 Tm 0 g (Die Semmerrolle der l{e4}nge nach zu einer grossen Roulade)Tj
n n n n n n Tm: text matrix
g: gray (0 g: black)
(...)Tj: show text
That's consistent with the code path when you set a text field value in the trunk of iText (and the most recent release[s]). That code (ColumnText) is quite good at breaking text properly, and used all over the place. The bounding box is correct (as shown in a couple places of the flattened PDF).
Check your input.