I know already pdfkit and wiked_pdf. pdfkit does not generate as I expect pdf from a remote web page.
Therefore I'd like to run wkhtmltopdf command in from within a ruby script as I do in the terminal.
In the script I've:
%x[wkhtmltopdf "http://www.radiozamaneh.com/67671" "./kaka.pdf"]
But the command is not executed. How should I do this?
Thanks in advance
It works the way you described:
%x[wkhtmltopdf "http://www.radiozamaneh.com/67671" "./kaka.pdf"]
Loading page (1/2)
QFont::setPixelSize: Pixel size <= 0 (0) ] 38%
QFont::setPixelSize: Pixel size <= 0 (0)=============> ] 88%
QFont::setPixelSize: Pixel size <= 0 (0)==============> ] 89%
QFont::setPixelSize: Pixel size <= 0 (0)==============> ] 89%
QFont::setPixelSize: Pixel size <= 0 (0)===============> ] 90%
QFont::setPixelSize: Pixel size <= 0 (0)===============> ] 90%
Printing pages (2/2)
QFont::setPixelSize: Pixel size <= 0 (0)
Done
=> ""
So, obvious questions:
Do you have this program installed in your box?
The user that is running rails have the binary on its $PATH variable?
Related
I am trying to resize the following GIF
Original Dimensions are: 1270 x 1270 and a total of 149 Pages
I am resizing to the following Dimensions:
250 x 250 (Successful)
500 x 500 (Successful)
750 x 750 (Unsuccessful)
It fails for the last case and after some digging I found that the limits are set in libvips. I am not able to conclude how the dimensions are violating the constraints.
Constraints Being:
if( (guint64) frame_rect.width * frame_rect.height > INT_MAX / 4 ||
frame_rect.width > 65535 ||
frame_rect.height > 65535 ) {
vips_error( class->nickname, "%s", _( "frame too large" ) );
return( -1 );
}
Currently I have the latest govips(v2.11.0) and vips(8.13.3) versions installed.
I tried different sizes and it is working till 740 x 740. I tried to change the Export Params but am unable to figure the math behind why the frame is too large.
I am trying to display a color gradient using the Spartan 6 board. Since Spartan 6 board which I am currently using supports only 8 bits for the VGA, I am not able to display RGB colors without hard borders. I have already displayed an RGB color with hard borders by coding like this
if x>0 and x<50 then
rgb <= RED;
elsif x>= 50 and x<100 then
rgb <= GREEN;
elsif x>= 100 and x<150 then
rgb <= BLUE;
elsif x>= 150 and x<200 then
rgb <= WHITE;
elsif x>= 250 and x<300 then
rgb <= RED;
elsif x>=350 and x<400 then
rgb <= GREEN;
elsif x>= 400 and x<450 then
rgb <= BLUE;
elsif x>= 450 and x<500 then
rgb <= WHITE;
end if;
But now I have to display a color gradient without hard borders. I am currently working with a screen resolution of 640x480. I am thinking of using LUT for giving all possible combinations by giving index. I need some advice on how this can be done in VHDL or Is there any other way to implement this without explicitly coding all combinations with conditions?
How to achieve a moving color gradient pattern with these color gradients?
Can someone help me with this? Thank you!
Is it a 8 bits per component (24 bit RGB) or 8 bit per color (8-bit RGB) ? In the second case you'll have a hard time displaying gradients. Not impossible, but much harder.
Let's assume you have a 24 bit case. With a step of 50 it will require some mid-to-heavy logic, or a big selection vector. But it will get much simpler if you set it to, say, 64.
Look:
R(7 downto 2) <= X(5 downto 0) when X(11 downto 6) = "000000" else
31-X(5 downto 0) when X(11 downto 6) = "000001" else
"000000"
will give you a black-to-red-to-black gradient 128 pixels wide on the left side of the screen.
You can combine it with 2 other colors to get the desired effect.
I expect this to have more to do with color spaces and their attributes. I was attempting to convert a YUYV to a grayscale image. I used the following function call:
cv::cvtColor(imgOrig, imgGray, cv::COLOR_YUV2GRAY_420);
With this function, I lost some of the height of the image. I could obviously use the resize method to make the original image large enough such that the conversion wouldn't cut out any actual data, but wanted to find out the more appropriate way to go about it.
Looking at the opencv source, below is an excerpt from the cvtColor method:
case COLOR_YUV2GRAY_420:
{
if (dcn <= 0) dcn = 1;
CV_Assert( dcn == 1 );
CV_Assert( sz.width % 2 == 0 && sz.height % 3 == 0 && depth == CV_8U );
Size dstSz(sz.width, sz.height * 2 / 3);
_dst.create(dstSz, CV_MAKETYPE(depth, dcn));
dst = _dst.getMat();
#ifdef HAVE_IPP
#if IPP_VERSION_X100 >= 201700
if (CV_INSTRUMENT_FUN_IPP(ippiCopy_8u_C1R_L, src.data, (IppSizeL)src.step, dst.data, (IppSizeL)dst.step,
ippiSizeL(dstSz.width, dstSz.height)) >= 0)
break;
#endif
#endif
src(Range(0, dstSz.height), Range::all()).copyTo(dst);
}
break;
You see that on the 8th line, the size of the destination image is made to be two-thirds the size of the source image.
Why is this so? What is the appropriate way to do a color space conversion?
Plainly, it is how YUV420 works. From wikipedia, YUV uses 6 bytes to store 4 pixels. Those 4 pixels share U, V values while having their own Y values. The picture and the formula presented in the conversion from YUV420 to RGB888 section explains it better. They also explain very well why the check
CV_Assert( sz.width % 2 == 0 && sz.height % 3 == 0 && depth == CV_8U );
and why the RGB's is only 2/3 of the YUV's.
I would like to Import a RAW10 file into Matlab. The infos are directly attachted to the jpeg file provided by the raspberry pi camera.
4 Pixels are saved as 5 bytes.
The first four bytes contain the bit 9-2 of a pixel.
The last byte contains the missing LSB.
sizeRAW = 6404096;
sizeHeader =32768;
I = ones(1944,2592);
fin=fopen('0.jpeg','r');
off1 = dir('0.jpeg');
offset = off1.bytes - sizeRAW + sizeHeader;
fseek(fin, offset,'bof');
pixel = ones(1944,2592);
I=fread(fin,1944,'ubit10','l');
for col=1:2592
I(:,col)=fread(fin,1944,'ubit8','l');
col = col+4;
end
fclose(fin);
This is as far as I came yet, but it's not right.
I have the following code:
red = [1 255 0; 0 0 0; 0 0 0];
green = [0 0 0; 0 0 0; 0 0 0];
blue = [0 0 0; 0 0 0; 0 0 0];
figure,imshow(cat(3,red,green,blue))
According to my "intuitive" understanding the color of the first pixel of the image should have the following rgb components: (1,0,0), while the second pixel should have the following components: (255,0,0) (when I say the "first" and "second" I mean the text order: from left to right, from top to bottom).
In other words the first pixel should be almost absolutely black while the second one should be red. However, the both pixels look perfectly red. What am I missing here?
I'm no expert, but I think it's because you're passing doubles to imshow. You could try
imshow(uint8(cat(3, red, green, blue)))