I have following postscript code
1448 2069 /moveto
(Comparator) {show newpath}
I would like to draw a rectangle around the text(Comparator) as I need to provide a hyperlink to redirect it to abbreviation page.But I am struggling to find the rest of the 2 coordinates. Would some one please advise.
Your friends are
string bool charpath
pathbbox llx lly urx ury
from the Postscript language.
so do
1448 2069 moveto
(Comparator) false charpath pathbbox newpath
will give you left-x, lower-y, right-x and upper-y on the stack. You can subtract/add some constant values to give a little space around the text and then calculate width and height instead of the right/upper values and do a rectstroke
EDIT small working sample
%!PS
/Helvetica findfont 20 scalefont setfont
20 dup moveto (Link on page1) show newpath
[ /Rect [ 20 dup moveto (Link on page1) false charpath pathbbox
2 add 4 1 roll 2 add 4 1 roll 2 sub 4 1 roll 2 sub 4 1 roll
newpath ] /Page 2 /Color [.7 0 0] /Subtype /Link /ANN pdfmark
showpage
20 dup moveto (Target on page2) show
showpage
The line 2 add 4 1 roll ... adds 2 more margin at each side. You can omit the entire line.
Related
I'm trying to create a custom pattern fill for highcharts.
It's a horizontal dashed line with alternating starting points from one row to another (the first start at 0,0 the second at 3,10 and so on).
I edited the Highcharts JSfiddle example replacing the custom pattern with the following (here you can find my "final" version) :
color: {
pattern: {
path: {
d: 'M 0 0 H 8 M 14 0 H 22 M 3 10 H 19',
strokeWidth: 0.5
},
width: 22,
height: 20
}
}
The problem is the the two rows of lines have different width.
I can't find any parameter in the documentation to fix this.
I don't know if the problem is in my pattern definition or a highcharts bug.
Any thoughts?
The path as-is moves first to 0,0 and then 14,0, and finally 3,10:
d: 'M 0 0 H 8 M 14 0 H 22 M 3 10 H 19'
You can change that to 0,1 and then 14,1, and then 3,11 and the lines are the same width:
d: 'M 0 1 H 8 M 14 1 H 22 M 3 11 H 19'
The lines starting at 0,0 are centred on the boundary meaning that half the line gets cut off, so just moving them all down by 1 ensures that the whole line is visible.
Updated Fiddle
I am looking for a simple conversion/transformation formula, such that:
In a square region sized d*d, containing a circle with diameter d (tangent to the 4 sides of the square),
all points on the circle are equidistantly transformed/unfolded/remapped into a straight line along the top or bottom edge of the square,
the center point of the circle is transformed/stretched all along the opposite edge of the square,
all points inside the circle are transformed the same way, and the resulting left and right sides can be tiled seamlessly, and
all points outside the circle are out of range of the square after the transformation, and are not visible.
In this before and after example, d=1:
Before After
------ -----
0 , 0 --> 0 , 1 (the only infinitely stretched point)
0 , -1 --> 0 , -1 (the only unchanged point)
0 , 1 --> -1 , -1 and 1 , -1
1 , 0 --> 1/2 , -1
-1 , 0 --> -1/2 , -1
√(1/2) , √(1/2) --> 3/4 , -1
√(1/2) , -√(1/2) --> 1/4 , -1
-√(1/2) , √(1/2) --> -3/4 , -1
-√(1/2) , -√(1/2) --> -1/4 , -1
1 , 1 --> out of range
1 , -1 --> out of range
-1 , 1 --> out of range
-1 , -1 --> out of range
This is related to polar/Cartesian (r,theta) to (x,y) conversion and/or arctan. The formula would be usable on graphing calculators like desmos.
For visual thinkers, here is a before & after graph of the transformation. Note that the circle before is along the bottom after, and that the transformed dots can be tiled horizontally.
I have this data:
data2 is missing the third point. So I thought, I'd define two different x columns and assign data2 to x2.
Problem: the third point of data1 goes up to 3 in the compiled graphic. If I have different and more values, points start to go anywhere, but not where they belong.
That is the code I've used:
\addplot[only marks, mark = diamond, color = orange, mark size = 3pt]
table[x=x1, y=data1]{example.dat};
\addlegendentry{data1};
\addplot[only marks, mark = square, color = gray, mark size = 3pt]
table[x=x2, y=data2]{example.dat};
\addlegendentry{data2};
\addplot[only marks, mark = o, color = blue, mark size = 3pt]
table[x=x1, y=data3]{example.dat};
\addlegendentry{data3};
And this is the graph I get:
Thanks a lot!
Btw. in the real data one data set is missing a x/y value in the middle of the data. I hope that doesn't matter compared to my example.
pgfplots is interpreting 2 tabs as a single separator. Thus, it sees the data file as:
x1 x2 data1 data2 data3
0 0 1 2 3
1 1 1 2 3
2 1 3
Solution 1. You can replace empty cells with NaN. pgfplots will interpret this correctly:
x1 x2 data1 data2 data3
0 0 1 2 3
1 1 1 2 3
2 nan 1 nan 3
Solution 2. Use another type of separator (e.g., semicolons or commas):
\begin{filecontents*}{example.csv}
x1;x2;data1;data2;data3
0;0;1;2;3
1;1;1;2;3
2;;1;;3
\end{filecontents*}
\pgfplotstableread[col sep = semicolon]{example.csv}\mydata
\begin{document}
...
Here I've included the data file in the TeX file, but it should also work with a separate data file.
When I try to encode a video the encoder crashes after finishing first GOP.
This is the configuration I'm using:
MaxCUWidth : 16 # Maximum coding unit width in pixel
MaxCUHeight : 16 # Maximum coding unit height in pixel
MaxPartitionDepth : 2 # Maximum coding unit depth
QuadtreeTULog2MaxSize : 3 # Log2 of maximum transform size for
# quadtree-based TU coding (2...5) = MaxPartitionDepth + 2 - 1
QuadtreeTULog2MinSize : 2 # Log2 of minimum transform size for
# quadtree-based TU coding (2...5)
QuadtreeTUMaxDepthInter : 1
QuadtreeTUMaxDepthIntra : 1
#======== Coding Structure =============
IntraPeriod : 8 # Period of I-Frame ( -1 = only first)
DecodingRefreshType : 1 # Random Accesss 0:none, 1:CDR, 2:IDR
GOPSize : 4 # GOP Size (number of B slice = GOPSize-1)
# Type POC QPoffset QPfactor tcOffsetDiv2 betaOffsetDiv2 temporal_id #ref_pics_active #ref_pics reference pictures predict deltaRPS #ref_idcs reference idcs
Frame1: P 4 1 0.5 0 0 0 1 1 -4 0
Frame2: B 2 2 0.5 1 0 1 1 2 -2 2 1 2 2 1 1
Frame3: B 1 3 0.5 2 0 2 1 3 -1 1 3 1 1 3 1 1 1
Frame4: B 3 3 0.5 2 0 2 1 2 -1 1 1 -2 4 0 1 1 0
This also happens with CU=16x16 with depth=1
Note: I encoded CU=64x64 with depth=4 with the same GOP configuration and every thing went fine.
This is most probably due to the fact that you have compiled the binary for a 32-bit system?
Please rebuild it for a 64-bit system and the problem will go away.
Apologies for a basic question. I have checking out the for loops here and here and for example if we analyse the first code :
for(int i = 0; i < CFDataGetLength(pixelData); i += 4) {
pixelBytes[i] // red
pixelBytes[i+1] // green
pixelBytes[i+2] // blue
pixelBytes[i+3] // alpha
}
The variable i is being incremented from 0 to the length of the array pixelData, in steps of 4.
However how does pixelBytes[i+3] access the alpha channel of the image? So for example if i=5, how does pixelBytes[5+3] equal the alpha channel instead of just accessing the 8th element of pixelBytes?
If i starts at zero and is incremented by 4 each time, how can it ever equal 5?
Presumably, the structure is stored with each channel occupying one byte, first red, then green, then blue, then alpha, then red again and so on. The for loop mimics this structure by increment i by four each time, so if the first time through pixelBytes[i+1] is the first green value, the second time through it will be four bytes later and thus the second green value.
Sometimes it helps to unrool the loop on a sheet of paper
// First pixel
RGBA
^ Index 0 = i(0) + 0
^ Index 1 = i(0) + 1
^ Index 2 = i(0) + 2
^ Index 3 = i(0) + 3
i + 4
// Second pixel
RGBA RGBA
^ Index 4 = i(4) + 0
^ Index 5 = i(4) + 1
^ Index 6 = i(4) + 2
^ Index 7 = i(4) + 3
i + 4
// Third pixel
RGBA RGBA RGBA
^ Index 8 = i(8) + 0
^ Index 9 = i(8) + 1
^ Index 10 = i(8) + 2
^ Index 11 = i(8) + 3
You have colours stored in the RGBA format. In the RGBA format, one colour is stored in 4 bytes, the first byte being the value for red (R), second is green (G), third is blue (B), and last is alpha (A).
Your own code explains this pretty well in its comments:
pixelBytes[i] // red
pixelBytes[i+1] // green
pixelBytes[i+2] // blue
pixelBytes[i+3] // alpha
It is important to note though, that if i is not a multiple of 4, you're not going to be reading the colours correctly anymore.
While the code isn't there, it is likely that pixelBytes is an array of size equal to the total number of colours times 4, which is the same thing as the number of total bytes used to represent the colours (since each colour is stored in 4 bytes)
A typical 32 bit pixel consists of four channels, alpha, red, green and blue.
My guess is that pixelbytes is a bytebuffer of these, so:
pixelbuffer[0] = r
pixelbuffer[1] = g
pixelbuffer[2] = b
pixelbuffer[3] = a
as your code says.
On each iteration, it adds four bytes (8 bit * 4 = 32 bit) to the counter, equaling the offset to the next 32bit pixel. The individual components can be accessed through a byte offset (i + <0-3>).