I am using wkhtmltopdf 0.12 with wicked_pdf or pdfkit and the header takes almost 100% of the page height.
It creates these problems :
Pages are almost empty
There are many more pages than it should
Solved this by adding
<!DOCTYPE html>
at the top of the header HTML file.
Somewhat capricious, I know...
Related
I am using wicked_pdf in my sinatra application. When i try to add a header or footer it is not shown in the pdf. Only the body element is working. Why the header and footer are not applied?
Here the very simple code example:
get '/api/v1/admin/fcb/pdf/schedules/:id' do
headers['Content-Type'] = 'application/pdf'
WickedPdf.new.pdf_from_string("<!DOCTYPE html><p>body<p>", header: {content: "<!DOCTYPE html><h1>header</h1>"})
end
This results in this PDF:
Versions:
wicked_pdf 2.1.0
wkhtmltopdf 0.12.6
Running on Debian based docker image ruby:2.6-slim
I could not figure it out, why it did not work as expected. So I ended up in taking care of the header and footer my self. I calculated the body length in my code and added footer and header when needed.
I noticed that when you have a rather large table (few thousand rows), the IE8 search function (Ctrl+F) becomes extremely slow when you use the doctype and set X-UA-Compatible to IE=8:
<!doctype html>
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=8">
...
Currently we have no way to decrease the size of the tables. Also, removing or changing the doctype or X-UA-Compatible messes up the layout of the page, so that's no quick solution either.
Does anyhave have any other ideas how to make the IE8 search function quicker?
To show the difference I created two test files that you can try (in IE8):
http://playground.steven.comprise.com/ie8/fast.php
http://playground.steven.comprise.com/ie8/slow.php
fast.php is the one without doctype or X-UA-Compatible. In this file the search is fast!
slow.php uses both the doctype and the X-UA-Compatible, so we want search in this file to become equally fast as in fast.php
Ideas?
You can implement your own search dialog (shown when ctrl+f is pressed). But I think it won't be faster than in IE8 compatibility mode. The reason the search in IE>8 is faster is that it uses newer DOM & JavaScript engine.
In some html documents I'm using webfonts for only a couple of words. Performance-wise loading a complete font-file seems wasteful. This is where the unicode-range parameter of the #font-face declaration comes in:
http://www.w3.org/TR/css3-fonts/#unicode-range-desc
With it I supposedly can define what characters of the font-file to load, thus improving performance greatly.
But I just can't get it to work. And the odd thing is that it diplays all the characters in firefox, and it fails to load the font in safari just if I include the unicode-range parameter in my declaration.
Any help would be appreciated, below is the html I was testing it with:
<!doctype html>
<html lang="en">
<head>
<style text="text/css">
#font-face {
font-family: 'dream';
src: url(Fonts/Digital-dream/DIGITALDREAM.ttf) format("truetype");
unicode-range: U+FF21;
}
*{
font-family:dream;
font-weight:normal;
}
</style>
</head>
<body>
<p>ASDWEWQDSCF</p>
</body>
</html>
You are misunderstanding the purpose of that value. From that page:
This descriptor defines the range of Unicode characters supported by a given font
So this isn't the glyphs (or characters) to download, this is actually telling the browser what characters are in the font so that the browser can determine if its even worth downloading the font in the first place. If the text being styled isn't in the given unicode-range then the font won't be downloaded.
Example XIII on the page you reference shows a great example. Imagine 3 #font-face rules that share the same font-family attribute. The first rule, however, points to a giant 4.5MB TTF file that has every possible glyph needed. The second rule lists a much smaller 1.2MB TTF but says to only use it only if all of the characters fit into the Japanese glyph range. The third rule lists a very small 190KB file that can be download if the text being styling is only roman.
Sometimes you want two body backgrounds. One for the header and one for the footer.
I accidentally discovered that it is possible to style the actual <html> tag.
HTML:
<html xmlns="http://www.w3.org/1999/xhtml">
CSS:
html {background:#000}
Is it OK to style this, or will it cause any problem?
Although it's debatable as to whether it's valid [see here]:
For HTML documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element. ...
Many large sites still use it with seemingly consistent results.
Yes, it's OK to style the html tag.
It is very common practice. Used all the time on many websites including this one.
Hello
I built a website for a graphic design company (www.brgdonline.com) and used the tag. The webpage will not show up at all in Chrome, Firefox, or IE. However, if I remove the doctype completely, it shows up fine. I have validated the website using w3's validator and got no errors. I can see the source code just fine even when it doesn't render.
Thanks so much in advance.
RMS
The div with id #whole has height:100% and overflow:hidden. The height is set to 100% of body which has no height defined and therefore becomes 0. Remove height:100% and overflow:hidden from #whole and I think it will render again.
alternatively give body and html a height:100% so they fill the whole viewport height.