I have a scenario which I think I can convey giving PC Monitor example (not real though).
Assume I have two monitors both of different resolution and properties. One monitor draws mouse cursor on screen from top (0) to bottom (max-value) and other draws mouse from bottom (0) to top (max-value). In other words both have reverse y-axis of each other in drawing mouse cursor and I need to write a formula that will convert one monitor cursor position to another and vice versa given one monitor x and y cursor positions.
What formula is the best suited for this?
right_x = (1 - left_x / left_width) * right_width
right_y = (1 - left_y / left_height) * right_height
The left_x and left_y (as well as the resolutions for each display) would need to be known.
Related
I have legacy code which use cairo library to draw png and calling following function. I could not understand the following code. I know it is weired question that took some piece of code and ask question. But great if anyone provide.
#define IMAGE_SIZE_W 1024
#define IMAGE_SIZE_H 768
#define GRAPH_MARGIN_L 48
#define GRAPH_MARGIN_R 21
#define GRAPH_MARGIN_B 27
#define GRAPH_MARGIN_T 22
#define GRAPH_SIZE_W (IMAGE_SIZE_W-(GRAPH_MARGIN_L+GRAPH_MARGIN_R))
#define GRAPH_SIZE_H (IMAGE_SIZE_H-(GRAPH_MARGIN_B+GRAPH_MARGIN_T))
#define SCALE_TO_CANVAS(v,low,high,fws,margin,a,b) (((a+b*((v-low)/(high-low)))*fws)+margin)
#define SCALE_TO_CANVAS_Y(v,low,high) SCALE_TO_CANVAS(v,low,high,GRAPH_SIZE_H,GRAPH_MARGIN_T,1,-1)
#define SCALE_TO_CANVAS_X(v,low,high) SCALE_TO_CANVAS(v,low,high,GRAPH_SIZE_W,GRAPH_MARGIN_L,0,1)
void line_to_point(cairo_t *cr,float x, float y){
cairo_line_to(cr,x,y);
}
void move_to_point(cairo_t *cr,float x, float y){
cairo_move_to(cr,x,y);
}
We have data in x and y and ploting x and y. The caller function is
/* counter number of x and y row
for(i = 0; i< counter; i++)
{
move_to_point(cr,SCALE_TO_CANVAS_X(xvals[i-1],lowX,highX),SCALE_TO_CANVAS_Y(yvals[i-1],lowY,highY));
line_to_point(cr,SCALE_TO_CANVAS_X(x,lowX,highX),SCALE_TO_CANVAS_Y(y,lowY,highY));
}
Than after it calls write_png which is kind of straight forward function.
if you look, SCALE_TO_CANVAS done lot of calculation which I am not able to figure out.
cairo_line_to x and y have modified value and plot it.
I haven't looked too closely, but I would guess that your x data is between lowX and highX and your y data between lowY and highY. This data is scaled so that it it fits into the image surface (which means between 0x0 and 1024x768).
Also, this seems to add a margin on all sides (L/R/B/T would mean left, right, bottom, top).
If you want an explanation of the math used instead of just its meaning, just ask.
Edit:
Ok, we have data that describes points in a graph. The top-left corner of our input data is at position (lowX, lowY), the bottom right corner is at (highX, highY).
The area that we are drawing to has a size of 1024x768. Thus, we want to scale the input data so that it fits into this space. To make things a little more complicated, we want to keep an empty margin around the graph. This takes GRAPH_MARGIN_L pixels on the left, GRAPH_MARGIN_T pixels on the top, etc.
So the drawing area has its top-left corner at (GRAPH_MARGIN_L, GRAPH_MARGIN_T) and its bottom right corner at (1024-GRAPH_MARGIN_R, 768-GRAPH_MARGIN_B). So we are looking for a formula that maps (lowX, lowY) to (GRAPH_MARGIN_L, GRAPH_MARGIN_T) and (highX, highY) to (1024-GRAPH_MARGIN_R, 768-GRAPH_MARGIN_B).
In the following, let's just look at one of the two coordinates of the point, e.g. the x coordinate. For a point x, we first calculate a percentage that describes how far along the axis it is. 0% should mean "at the top/left end", 100% is "at the bottom/right end". The available space begins at lowX and goes to highX, so there are highX-lowX possible values. Thus, x-lowX (so that "top/left" really is at zero) falls somewhere into this range and (x-lowX)*100/(highX-lowX) is the percentage that we are looking for.
This percentage should now be mapped into the target area. First we multiple this by the width of the target space (and dividing by 100, so that the percentge goes away), so that we have a value that spans the possible range. Then we have to add the lowest possible value, so that instead of starting at zero and going up to the possible width (which is high-low), we have a value that is between low and high.
All together, the formula becomes smallestTargetX+(x-lowX)/(highX-lowX)*widthOfTheTargetArea, or in terms of your defines: GRAPH_MARGIN_L+(x-lowX)/(highX-lowX)*GRAPH_SIZE_W.
The additional variables a and b that are used in GRAPH_TO_CANVAS are used for "swapping directions". It seems like instead of having (0, 0) in the top-left corner and positive coordinates going to the right/bottom, your coordinate system has (0, 0) in the bottom-left corner and positive coordinates go to the right/top. To handle this, the percentages calculated above are multiplied with -1 and 1 is added to the coordinate, to make the mapping really map the points to each others that it should. These are the last two arguments for the GRAPH_TO_CANVAS macro.
I hope this helps you understand that macros.
The way I understand how emacs displays stuff is that essentially everything is text. If you have something in the fringe or linum mode active, essentially your document is pushed a little inwards and something is written in the first few columns.
I'm writing a function for putting some stuff into the head-line and this works nicely, however, I would like the start of the text to be aligned with the start of the document.
Thus I am looking for a way to get the number of columns that sit between the frame border and the start of the actual document.
Let me illustrate using a poorly produced graphic:
I want to get the number of columns (or the number of pixels) that make up the distance marker by the ruler just below the line number 10000.
The function which returns this value shall be executed in the functions which create the head-line.
There is a function called window-inside-edges that you can use to determine the offset of the text area ("window body") from the total width and height of the window in columns and lines, respectively.
It returns a list four values; the order is left - top - right - bottom, so to get the value you are interested in for the current window, just do
(car (window-inside-edges))
More information on window coordinates can be found here; this page has information about window sizes, including a nice ASCII representation of window elements.
I have this image (too large to include) (2351x997) and I'm trying to detect the horizontal lines, first I have to apply a window as
M=T(1:d,1:l);
T is my image, d is width (4 pixels) and l is the length (l=0,2*2351) of my area of interest. Then in this window I have to count black pixels (n), the mean value (m) and standard deviation (σ).
Afterwards if n/(lxd) >0.6 and σ<1,2 I assume I detect a line.
The applied window will slide through image in step of l/4
You can try follow this example,
SCW Example
I am creating a Microsoft Word document using the OpenXml library. Most of what I need is already working correctly. However, I can't for the life of me find the following bit of information.
I'm displaying an image in an anchor, which causes text to wrap around the image. I used WrapSquare but this seems to affect the last line of the previous paragraph as shown in the image below. The image is anchored to the second paragraph but causes the last line of the first paragraph to also indent around the image.
Word Screenshot http://www.softcircuits.com/Client/Word.jpg
Experimenting within Word, I can make the text wrap how I want by changing the wrapping to WrapTight. However, this requires a WrapPolygon with several coordinates. And I can't find any way to determine the polygon coordinates so that they match the size of the image, which is in pixels.
The documentation doesn't even seem to indicate what units are used for these coordinates, let alone how to calculate them from pixels. I can only assume the calculation would involve a DPI value, but I have no idea how to determine what DPI will be used when the user eventually loads the document into Word.
I would also be satisfied if someone can explain why the issues described above is happening in the first place. I can shift the image down and the previous paragraph is no longer affected. But why is this necessary? (The Distance from text setting for both Left and Top is 0".)
The WrapPolygon element has two possible child elements of LineTo and StartPoint that each take a x and y coordinate. According to 2.1.1331 Part 1 Section 20.4.2.9, lineTo (Wrapping Polygon Line End Position) and 2.1.1334 Part 1 Section 20.4.2.14, start (Wrapping Polygon Start) found in the [MS-OI29500: Microsoft Office Implementation Information for ISO/IEC-29500 Standard Compliance]:
The standard states that the x and y attributes are represented in
EMUs. Office interprets the x and y attributes in a fixed coordinate
space of 21600x21600.
As far as converting pixels to EMUs (English Metric Units), take a look at this blog post for an example.
I finally resolved this. Despite what the standard says, the WrapPolygon coordinates are not EMUs (English Metric Units). The coordinates are relative to the fixed coordinate space (21600 x 21600, as mentioned in the quote provided by amurra).
More specifically, this means 0,0 is at the top, left corner of the image, and 21600,21600 is at the bottom, right corner of the image. This is the case no matter what the size of the image is. Coordinates greater than 21600 extend outside the image.
According to this article, "The 21600 value is a legacy artifact from the drawing layer of early versions of the Microsoft Office."
I was just wondering how to animate for example clouds which return back from the left side of the screen once they are outside the right side of the screen
I´ve tried with clouds.center = CGPouintMake(clouds.center.x + cloudvelocity, clouds.center.y + cloudvelocity) but I can only make them go from left to right and in a decline line.
In other words...
I have troubles making them go in a straight line from left to right and return bac to the screen from the left side of the screen once they are outside the right side of the screen.
can anyone help me?
The main thing you'll probably want to take advantage of is modular arithmetic, which is the same as asking what the remainder would be if you divided by a certain amount. So, for example:
28 mod 6 = 4
% is the integer modulus operator, but with floating point numbers you need to call the library method fmod (which takes and returns doubles) or fmodf (which takes and returns single precision floats). E.g.
NSLog(#"%0.0f", fmodf(28.0f, 6.0f));
Would log '4'.
In your case you have positions that constantly change, but you want the results to be constrained to a certain window size. Supposing it's 1024 points across, you want location 1024+n to be the same as location n, which is the same as 2048+n, 3072+n, etc. What you want to do then is to keep only the remainder when divided by 1024. So, e.g.
clouds.center = CGPointMake(fmodf(clouds.center.x + cloudvelocity, 1024.0f),
fmodf(clouds.center.y + cloudvelocity, 768.0f))
Or whatever your view dimensions are.
The first potential issue is that negative numbers don't necessarily work the way you want them to. E.g.
fmodf(-23.0f, 1024.0f));
is -23.0f (as are the related fmodfs of -(1024.0f + 23.0f), -(2048.0f + 23.0f), etc). You can handle that by checking for values less than 0 and adding 1024.0f if you get one.
If you know that your computed value can go negative, but never more than 1024.0f negative then you can just do:
clouds.center = CGPointMake(fmodf(1024.0f + clouds.center.x + cloudvelocity, 1024.0f),
fmodf(768.0f + clouds.center.y + cloudvelocity, 768.0f))
Since obviously the addition of 1024.0f will have no effect on the result if the number is positive. If you don't mind two calls to fmodf then obviously:
clouds.center = CGPointMake(
fmodf(1024.0f + fmodf(clouds.center.x + cloudvelocity, 1024.0f), 1024.0f),
fmodf(768.0f + fmodf(clouds.center.y + cloudvelocity, 768.0f), 768.0f))
Will work for any input value.
The second potential issue is that you're wrapping the centre of the cloud only. So it'll just jump from one side of the screen back to the other — you'll never have the cloud half on one side of the screen and half on the other. Assuming the cloud is less than a screen wide, possible solutions are (i) draw each cloud twice, with the second either 1024 pixels to the left if the cloud centre is greater than the screen modpoint or 1024 pixels to the right otherwise; (ii) make a virtue of it and use a conceptual wraparound area of, say, 2048 pixels rather than 1024, putting the visible part in the middle. So the cloud will go completely off screen to the right, then jump to the left without anybody being able to see it, and re-emerge from that side.