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.
Related
While using Delphi Seattle 10 and Steema TeeChart Pro VCL FMX 2016.18, I am looking to Highlight a Selection of a Line Graph (multiple series) in the way that Zooming allows / makes a square around a highlighted selection of a Line Graph to indicate which part of it to zoom into (as long as the onmousedown action is in progress).
The purpose of this would be to allow the selection to remain highlighted while the mouse is no longer being clicked, to potentially "Delete" the highlighted Data points. All I need this for is to obtain the (X0 Y0 X1 Y1) values to possibly obtain the CalcPosPoint(X) and remove all the points inside. The data is currently obtained through a Record Struct (Memory Mapped) file, and it will there for be used to set/check for a property "deleted" to indicate on the next redraw of the graph which rows to completely ignore and which to continue printing.
I hope to be able to do this (select from 1 chart), and have it simultaneously draw on multiple graphs. I have tried to look for an example of this feature through the use of TSelectorTool (FMXTee). One of the pages I found referring to such a tool is Interactive data point selection as well as Multiple selections with Selector Tool
And my second question has to do with TeeCharts directly. Where would I find fmx240.bpl as TeeChart_Pro_Firemonkey_Demo.exe requires this file in order to run? I did manage to copy vcl240.bpl from "Embarcadero\Studio\18.0\bin" and put it into "Embarcadero\Studio\17.0\bin"
[Edited]
I have managed to capture / create a sample code (MVCE) from which I can now select a portion and create a square around a particular sample of graph lines.
The control graph right now is the bottom graph (Chart5). If anyone is interested in seeing the code, I have put up a pastebin sample.
PasteBin Sample Code
And a TeeCharts.tar.gz is accessible to anyone who wishes to see a sample of the code, as well as the data sample.
filetolink.com Source Files
I no longer feel the need for mathematical equation to differentiate the top graphs from the bottom (because the bottom axes are automatic where as the top are defined). I intend to only use the space which is adherent to the visible space, and do not intend to extend in either direction (left or right). That means at this point the size of the graph does not matter, because once I over populate the charts above, the position in the bottom graph would become irrelevant, and therefor I do not intend to use the bottom chart.
The next step is to save the positions of the boxes so that they can reappear when the graph is shift from left (past data) to the right (live data). And then uses the buttons above to make the appropriate action to the graphs.
I would like to know what way would be the most sufficient way to record the positions of the rectangles, so when the chart is shifted (via the ScrollBar1), the rectangles are moving with the direction of the scrollbar. But I'm sure I can achieve that.
I think I have found a solution. The red squares are only prevalent for the visual aspect, they can be drawn on, I don't need to do anything special with each chart, as I already know what the X0..Y1 parameters are, they are known from the initial chart. The problem h/e has to do with the initial chart. As long as the screens are all full, I can zoom in correctly w/ alignment with on all the charts (ZoomRect/Rectf(X0..Y1))
But what kind of equation would it take to adjust the charts that are not in the same zoom / max / min when the Chart5.Axes.Bottom.Automatic = True?
From there I just simply have to disable the immediate zoom feature, and allow buttons to become functional, to decide what the next course of action would be.
I am writing a vba macro that checks that word documents are formatted correctly to meet certain specifications. One of the things I have to check for are the left margins of each line - different paragraphs are supposed to have different first indents and hanging indents depending on the context. This should be as simple as checking the style, but unfortunately it is not - some of the documents use styles to change the indents, but others use manual spaces and tabs to position the text correctly. So I need some way to check the actual physical position of the first physical character in each Document.Paragraphs. I have no problem getting a range with the first visible character in the paragraph, but I'm not sure about getting the distance from the margin (or from the left side of the page - doesn't make a difference because the margins are consistent).
I found the Window.GetPoint method, but I'm nervous to use it, because that is based on the actual physical location on the screen. This macro is going to be used on different computers, with different versions of word, and I'm not sure about how it is affected by other view settings (like print layout, zoom, etc.) Is there a consistent way to use this method to determine the distance from the margin?
The other method would be (because all of the documents are in Courier New 12) to look at the firstindent property of the style, and the count manually all of the spaces and tabs (but that would need to take into account tabstops). This I'm also not sure how to do.
I would think that there should be a much simpler way of doing this, but I can't find it, so if anyone has any suggestions I would really appreciate any help.
It was there after all! Range.Information(wdHorizontalPositionRelativeToPage)
I have a richedit containing lines using different fonts, styles, languages etc.
I am drawing in a gutter. I would like to start my drawing at the same y pixel position as the corresponding line.
Send the control an em_PosFromChar message. It returns the client coordinates of the character at the given index, although the documentation doesn't say what the coordinates represent (upper left corner, baseline center, or what). You're looking for the character's baseline.
Use em_LineIndex to get a character index for a given line number, if you don't already know the index of a character you're interested in.
So i have a custom UISlider. It's vertical (i did it with the +270° technic). I have 3 images, respectively for the minimum value, maximum value and for the thumb. Everything seems good but i have problems with the extrema values, as you can observe on the screen capture (even though it's a little dark).
The slider on the left is perfect ! Both end of the sliders show the images perfectly and the cursor (thumb) is perfectly cutting the slider in 2.
The other two sliders on the right shows a similar issue. We can see that, when in extrema value, the cursor is not well located (there shouldn't be any part of the image below or above the middle of the cursor !) Oo
More to that, let's look at the right slider (with minimum value). We can see that image has been cut on the bottom ! Indeed it should be close. It's the same thing for the maximum value, the image looks like it's been cut.
I looked at the bounds of the slider view by touching it at both ends and looking at its coordinates. The slider was defined with a height of 300 but i can perform touches at coordinate 307, or -6 !!! I don't really understand why..
For more information, coordinates form 300 to 310 represents the maximum value i defined and negative coordinates (from 0 to -10) represents the minimum value.
-> So We can notice there's a difference of 10 at both ends.
Please help ! :s
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.