This question already has answers here:
How to make a HTML Page in A4 paper size page(s)?
(15 answers)
Closed 7 years ago.
I need to create an HTML page with A4 paper size.
I know that A4 paper size in pixels is: 595px x 842px (string No. 10-11). But while I put those sizes and try to print the page (I print to PDF file, due to the temporary lack of inks), I do not get my HTML fully fits the page: it is much smaller.
When I tried to add some pixels (with the coefficient, of course), I got 794px x 1122px (string No. 12-13) and the second printing attempt (saving to PDF file) gave me the result that this variant is a bit bigger, then needed.
So, what is the solution and why may 595px x 842px not be compatible with real A4 saved to PDF?
This is the example
P.S. I use Chromium for Ubuntu 13.10 and did not checked it on Windows.
I am doing this to be able to simply change the values via PHP and then convert HTML page to PDF, like described here.
HTML assumes that the screen is 96 DPI, or that 1 pixel is 1/96 of an inch.
On hardware with a very high resolution, it uses the concept of logical pixels, which are units that are close to 1/96 of an inch, and each of which consists of multiple device pixels. This is true for printers, but also for phones and other devices with high res screens.
So, if you want a rectangle the same size an an A4 (21 × 29.7 cm), you should use 794 × 1122 pixels, or in CSS, width:794px; height:1122px. But you can also use physical units, width:21cm; height:29.7cm if you don't want to worry about these logical pixels.
If you're planning on printing this, remember you should print at 300dpi, so 8.5"x11"* 300 = height: 3300px; width: 2550px.
Also, I would buffer .25" for a margin as well, so just do 8" x 10.5" before converting to pixels.
Related
I've run into an odd issue when embedding plaintext files in html here. These plaintext files range in their number of lines, and I used to determine the optimal height of the field with a simple multiplication, with a ratio of 22.
Turns out, the larger the number of lines, the less this works. I've put together this table to describe how the ratio and slope change, based on four data points (the optimal height is defined by that which doesn't generate a scrollbar):
3 66 22 N/A
9 186 20.66 20.00
23 366 15.913 12.87
33 516 15.636 15.00
You can also see the odd graph here. Currently, I use this equation to calculate the embed heights. This won't work well for all numbers of lines, however.
I don't understand why:
This isn't a linear fit, considering the font is monospaced, and
The slope changes with each datapoint
PNG files may contain chunks of optional informations. One of these optional information blocks is the physical resolution of the image (chunk-signature pHYs).[1] [2] It contains separate values for horizontal and vertical resolution as pixels per unit, and a unit specifier, that can be 0 for unit unspecified, or 1 for meter ← that's quite confusing, because resolutions are traditionally expressed in DPIs.
The Inch is defined as 25.4 mm in the metric system.
So, if I calculate this correctly, 96 DPIs means 3779.527559... dots per metre. For the pHYs chunk, this has to be rounded. I'd say 3780 is the right value, but I found also 3779 suggested on the web. Images of both kind also coexist on my machine.
The difference may not be important in most cases,
3779 * 0.054 = 95.9866
3780 * 0.054 = 96.012
but I try to avoid tricky layout problems when mixing images of both kind in processes that are DPI-aware like creating PDF files using LaTeX.
[1] Portable Network Graphics (PNG) Specification (Second Edition), section11.3.5.3 pHYs Physical pixel dimensions
[2] PNG Specification: Chunk Specifications, section 4.2.4.2. pHYs Physical pixel dimensions
The relative difference is less that 0.03% (2.65/10000), it's hardly relevant.
Anyway, I'd go with 3780. Not only it's the nearest value, but it would give the correct value if some (sloppy) conversor rounds the value down (instead of rounding to the nearest).
Also, if you google "72.009 DPI PNG" you'll see a similar (non) issue with 72 DPI (example), and it seems that most people rounded the value up (which is also the nearest) 2834.645 -> 2835
I have question about using dp in web development. Im currently reading google material design guidelines and they are talking about elevation and shadows based on dp. How can I use this in web development? Is there any way to calculate this how to create shadow based on dp with HTML CSS?
Example from the web page:
Raised button
Resting state: 2dp
Pressed state: 8dp
For desktop only, raised buttons can have an elevation of:
Resting state: 0dp
Pressed state: 2dp
As mentioned in the Google Material design documents:
A dp is equal to one physical pixel on a screen with a density of 160.
To calculate dp:
dp = (width in pixels * 160) / screen density
When writing CSS, use px wherever dp or sp is stated. Dp only needs to
be used in developing for Android.
and screen density is
Screen resolution refers to the total number pixels in a display.
screen density = screen width (or height) in pixels / screen width (or
height) in inches
So it depends on the screen width and height. There are some converters on the web to calculate for each density. But as most screens are still 72dpi (not mentioned the HDPI screens), I think that is a proper starting point.
There are no CSS units that are truly device-independent. See http://www.w3.org/TR/css3-values/#absolute-lengths. In particular, the absolute units might not match their physical measurements.
If physical units were true to their purpose, you could use something like points; points are close enough to dps:
1 in = 72 pt
1 in = 160 dp
=> 1 dp = 72 / 160 pt
If you use SCSS, you can write a function to return in pts:
#function dp($_dp) {
#return (72 / 160) * $_dp + pt;
}
And use it:
.shadow-2 {
height: dp(2);
}
For Material's shadows they only really use the concept of dp to attempt to relay how elements should be layered.
i.e.
2dp < 8dp // 2 is layered under 8
// or
2dp (resting) => 8dp (focused)
What they are referring to is z-depth (or on the z-axis). This cannot be converted straight to CSS. When they talk about elevation levels they are not referring to x & y or width & height dimension.
See design guide page on elevation.
If you are simply looking for the values for CSS shadows check here.
https://github.com/mrmlnc/material-shadows/blob/master/material-shadows.scss
That is as close to converting z-depth dp to CSS values. The CSS values do match Google's Polymer elements though so it's most likely spot on.
Good Luck!
How can I set the text size (inside TextField) in standart CSS/printable points? According to the manual:
fontSize - Only the numeric part of the value is used. Units (px, pt)
are not parsed; pixels and points are equivalent.
As far as I understand, 1 pixel may be equal to 1 point only in 72 PPI case. So, actionscript just operating pixels (not the real points). My trouble is to get the actual text size that I can print. Any advices or solutions are welcome.
SWF is measured in pixels, moreover, is scalable, so 1 pixel can be 1 point now, 2 points a bit later (scaleY=scaleX=2), and an undefined number another bit later (removed from stage without dereferencing). In short, for AS there are NO "real points" since it does not know a thing about printers, while it knows about displays.
So I'm using Supersized to scale my background images and that's all good and well. The problem is that if I want the image to look good at multiple resolutions, it should be big, e.g. 2000 px * 2000 px. But why should someone with a resolution of e.g. 800 * 600 need to download such a large image? So what I'd like to do is to have, let's say, 3 sizes of the image (1024 * n, 1680 * n and 2000 * n) and, depending on the resolution, the smallest possible of them would be sent to the user. Any thoughts on how I should implement this?
Using Javascript's window.screen.width will return you the actual pixel width of the screen, so then you can use a simple if statement to select which image you will use.
if(window.screen.width < 1000) {
image = "small.jpg";
} else {
image = "large.jpg";
}
you can use $(window).width(); (http://api.jquery.com/width/) to determine the user window width and then decide which image do you wish to use -
$('#yourImageId').attr('src', 'images/alt/imagename.jpg');
Many ways:
As others said, get the width of the screen, then based on that, manipulate the background image source of the element.
Use Less to create programmatic CSS at client-side
Use the concept of responsive-images