Consider the following bidirectional text in MS Word 2010, where the caret was positioned with a mouse click right at the left of the Hebrew letter dalet.
If I then press Delete, the caret moves to its new position :
As far as I can understand the caret should not move in this case. Any explanation ?
The caret "moves" from being just after (but visually before) the dalet to just before the end of the line. These are in different visual positions but the same logical position.
I also compared the behaviour in Firefox 4 (which I happened to have handy) and Firefox 15 (Nightly). Firefox 4 has a bug where pressing right arrow cycles though the Hebrew characters, however it doesn't move the caret when you press delete in your situation. Firefox 15 does not have the right arrow bug, but it exhibits the same delete "bug".
Related
Context:
I'm working on a device which inserted between an electronic typewriter's controller and its keyboard turns it into a serial printer/terminal.
I want it to support some of the control sequences from ECMA-48 / ISO-6429 / ANSI X3.64. (also known as ANSI escape code)
I'm having some uncertainty if I'm understanding correctly the standard, so I would like to ask to know how it should be.
It's related to the commands SLH - SET LINE HOME and SLL - SET LINE LIMIT.
For example I could have the situation that I have 1/12 inch wide characters, I want a left margin of 1 inch, and 80 columns of text.
Then I would set page home to 13 and page limit to 92.
(since character positions are counted from 1, home is the first position, limit is the last)
So far ok.
But when I already have set the home, than how should the functions:
CHA - CURSOR CHARACTER ABSOLUTE
CUP - CURSOR POSITION
HPA - CHARACTER POSITION ABSOLUTE
CPR - ACTIVE POSITION REPORT
and others related to the cursor position work?
Should they use coordinates relative to to the actual edge, or to the home position.
So in my above example if I wanted to move to column 2 of the text print area (home being 13), I should use coordinate 2 or 14?
(similarly for vertical position and page home & limit)
My understanding is that these control sequences still use the absolute coordinates.
so in my example I would have to use coordinate 14.
Is this correct?
And if it is correct, this raises some additional problems:
I would have to know where the margins are to know which horizontal and vertical offset to use when moving the cursor to absolute positions.
If a program sets the margins first, then no problem, but I a program connects to the device and does not change the margins then it does not know the offset.
(There is a way, it could send a carriage return to move to the home position and then request the ACTIVE POSITION REPORT to discover the left margin position, but it does not look like a nice solution)
What should my device do if it is requested to move to a position outside the defined home and limit?
The standard says that beyond these limits no implicit movement should happen, but this is explicit movement.
If it receives a command to move to position 1 when the home is 13 what should it do? Move to 1? Move to 13? ignore?
When it is at position 15, home is at 13 and receives command to move cursor left by 4 positions should it move by 4 to 11? move by 2 to 13? ignore?
Another problem I see is that there is a command to set page home, and page limit, but not total page height.
It is only possible to select predefined formats by PFS - PAGE FORMAT SELECTION.
But I don't see a way to select any other height.
If I want to use continuous paper with 12 inch long pages (72 lines of text at 1/6 inch line height) connected together into a long tape then I see no way to define that height so that my device can correctly keep track of its positions on the following pages. Is there a way to do it?
Looks like I had to find the answers by myself.
question 0:
Yes, it appears, that the coordinates should still be absolute.
he standard says about character positions in a line and line positions in a page and these are specified in the beginning of the document and nowhere at all is said about it being relative. Looks like the only role of line home and limit is the place where CR (and some others) returns to, and limit of where implicit movement (like advancing forward after printing a character) can go, similar for page home and page limit.
question 1:
There is no easy way for a program to recognise where the home and limit positions are. As I mentioned, requesting ACTIVE POSITION REPORT can help if this is implemented. (my devece does not support it yet).
Anyway, many programs don't recognise the concept of line home, and assume that normal character positions start from 1.
My solution to this is that after power on, the line home IS exactly at position 1, and if you want something else, you have to specify it.
This way a program can safely make this assumption.
(However after the PFS - PAGE FORMAT SELECTION command I do set the line home to 1 inch as this is what the standard proposes)
question 2:
As above, the home and limit are only a margin for implicit movements. So the cursor movement commands will move outside these limits with no problem. Only the actual page size will limit them.
question 3:
(but I didn't give it a number when asked)
DTA - DIMENSION TEXT AREA is the command for this purpose. It specifies the size of the text area limited by the actual page size, not by the home and limit positions.
I have a BB app (written with j2me and lwuit). There are a lot of text fields (com.sun.lwuit.TextArea objects) in the app. When running it, if I type characters in the text fields, the cursor advances after each character, except for space. When I press space (no matter how many times), the cursor does not move. If I press space many times and then press another key (letter or whatever), the spaces are there... they appear correctly and the cursor advances after the last character. I hope I explained it clearly.
Anyone can tell what is wrong here? There is nothing special about the TextArea objects... I just create them then set a hint and a max size, that's it.
Thanks a lot,
Silviu
When using Delphi, any version, I sometimes happen to hit the insert key and turn on overwrite mode. This is often a great nuisance and the only indication you have entered overwrite mode is the small text at the bottom of the editor.
When using other programs (first to come to mind is Notepad++) when you are in insert mode the text cursor is | and when you are in overwrite mode the cursor changes to _
Is there an option somewhere or a way to have Delphi use a different text cursor when in overwrite mode?
In my opinion, the 'normal' behaviour is that the caret is a thin vertical line in insert mode, and a thick (1 character wide) block in overwrite mode.
Apparently, the IDE doesn't support this. But it does support 'BRIEF cursor shapes'. They probably mean 'Brief caret shapes', but we still understand what they mean, right? ;)
Using this option, the insert caret is a thin horizontal line (uncommon!), and the overwrite caret is the normal thick block that we are all used to (common).
What was the original historical use of the vertical tab character (\v in the C language, ASCII 11)?
Did it ever have a key on a keyboard? How did someone generate it?
Is there any language or system still in use today where the vertical tab character does something interesting and useful?
Vertical tab was used to speed up printer vertical movement. Some printers used special tab belts with various tab spots. This helped align content on forms. VT to header space, fill in header, VT to body area, fill in lines, VT to form footer. Generally it was coded in the program as a character constant. From the keyboard, it would be CTRL-K.
I don't believe anyone would have a reason to use it any more. Most forms are generated in a printer control language like postscript.
#Talvi Wilson noted it used in python '\v'.
print("hello\vworld")
Output:
hello
world
The above output appears to result in the default vertical size being one line. I have tested with perl "\013" and the same output occurs. This could be used to do line feed without a carriage return on devices with convert linefeed to carriage-return + linefeed.
Microsoft Word uses VT as a line separator in order to distinguish it from the normal new line function, which is used as a paragraph separator.
In the medical industry, VT is used as the start of frame character in the MLLP/LLP/HLLP protocols that are used to frame HL-7 data, which has been a standard for medical exchange since the late 80s and is still in wide use.
It was used during the typewriter era to move down a page to the next vertical stop, typically spaced 6 lines apart (much the same way horizontal tabs move along a line by 8 characters).
In modern day settings, the vt is of very little, if any, significance.
The ASCII vertical tab (\x0B)is still used in some databases and file formats as a new line WITHIN a field. For example:
In the .mer file format to allow new lines within a data field,
FileMaker databases can use vertical tabs as a linefeed (see https://support.microsoft.com/en-gb/kb/59096).
I have found that the VT char is used in pptx text boxes at the end of each line shown in the box in oder to adjust the text to the size of the box.
It seems to be automatically generated by powerpoint (not introduced by the user) in order to move the text to the next line and fix the complete text block to the text box. In the example below, in the position of §:
"This is a text §
inside a text box"
A vertical tab was the opposite of a line feed i.e. it went upwards by one line. It had nothing to do with tab positions. If you want to prove this, try it on an RS232 terminal.
similar to R0byn's experience, i was experimenting with a Powerpoint slide presentation and dumped out the main body of text on the slide, finding that all the places where one would typically find carriage return (ASCII 13/0x0d/^M) or line feed/new line (ASCII 10/0x0a/^J) characters, it uses vertical tab (ASCII 11/0x0b/^K) instead, presumably for the exact reason that dan04 described above for Word: to serve as a "newline" while staying within the same paragraph. good question though as i totally thought this character would be as useless as a teletype terminal today.
I believe it's still being used, not sure exactly. There might be even a key combination of it.
As English is written Left to Right, Arabic Right to Left, there are languages in world that are also written top to bottom. In that case a vertical tab might be useful same as the horizontal tab is used for English text.
I tried searching, but couldn't find anything useful yet.
I'm using ITextRange from a RichEdit control. I want to determine if a user's cursor is touching a word.
The problem is that calling iTextRange.expand(tomWord) will include tailing spaces:
Brackets indicate the range:
Before:
weas[]el .
After:
[weasel ].
My original plan was to expand the range, and check if it contained the cursor. But the user's cursor could be two spaces after "weasel", and the range will still expand to contain it. So what else can I do?
I can recall facing a similar problem: that is, how to select a word without selecting any trailing space. I think that code like this C++
textRange->StartOf(tomWord,tomMove,NULL);
textRange->MoveEnd(tomWord,1,NULL);
should give you the right selection, so that you can then test if the caret is in the selection.