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
Related
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 a bar chart that show the count of number of models for each agency,
The problem is that I have a large difference between the values that makes the report to look not so good.
Does anyone have any ideas of a good way to resolve this problem?
Have you considered using a logarithmic scale?
With your chart Right-click the y-axis, and click Vertical Axis Properties.
In Axis Options, select Use logarithmic scale.
Leave the Log base text box as 10 (this is the scale most commonly used by logarithmic charts)
This will display a chart with a scale that goes up by a factor of 10 for each ‘unit’ up, so the distance between 1 and 10 is the same as that between 100 and 1000.
For example the shown dataset is displayed as this chart when using the logarithmic scale
This method is a simple and recognised way to clearly show values of widely different scales.
Update
If want an indicative bar for the vales that are 1 then you could use the expression
=iif(Fields!val.Value = 1, Fields!val.Value * 1.1, Fields!val.Value)
To make all values that are 1 equal to 1.1 so showing a tiny bar appearing a the bottom of the chart, as seen here
Unfortunately I don't know of a way to change that first 1 to a zero (formatting-wise). This is partly because you are now using a logarithmic scale and zero and negative values don't really exist. This is due to a fundamental property of logarithms in mathematics, that
LOG10(10)= 1
LOG10(1) = 0
LOG10(.1)=-1
Therefore, when you perform a log10 of zero, it just doesn't exist.
I use the following CSS rule to set background color of div:
div {
background-color: rgba(96, 96, 96, .1);
}
In Google Chrome v.42 in 'Computed' tab of Developer Tools I see this result rgba(96, 96, 96, 0.0980392);. I think, it looks like some web-kit optimization...
In FireFox v.36 computed background color equals to rgba(96, 96, 96, 0.1)
I've made a simple http://jsfiddle.net/sergfry/c7Lzf5v2/ that shows it in action.
So, can I prevent opacity changing in Google Chrome?
Thanks!
As stated by Quentin, this is an IEEE floating point issue.
0.1 doesn't actually exist in decimal floating point technically simply due to the way that binary works.
0.1 is one-tenth, or 1/10. To show it in binary, divide binary 1 by binary 1010, using binary long division:
As you can see, 0.1 in binary is 0.0001100110011....0011 and it will keep repeating 0011 on the end to infinity.
Browsers will pick and choose the closest available point to 0.1 and use that as the opacity instead. Some will go over and some will go under.
FireFox i would guess it just showing the human readable version but in reality, its really using a computer usable floating point.
As an example:
body {
color: rgba(0,0,0,0.1); // actually 0.0980392
opacity: 0.1; // actually 0.100000001490116
}
Two completely different values for exactly the same floating point.
This floating point issue can actually be replicated elsewhere within browsers using other languages such as Javascript. Javascript numbers are always 64 bit floating point (which i believe CSS is as well). This is more commonly known as Double-precision floating point. PHP also uses double-precision floating points.
64 bit floating point numbers are as you could guess, stored in 64 bits, where the number (the fraction) is stored in bits 0 to 51, the exponent in bits 52 to 62, and the sign in bit 63.
This causes problems down the line as it means integers are only counted as accurate up to 15 decimal points and can really only calculate up to 17 decimal points.
This means that numbers can round up very easily or may just not be stored correctly.
var x = 999999999999999; // x = 999999999999999
var y = 9999999999999999; // y = 10000000000000000
The arithmetic for floating points can also be out of alignment by quite a lot in places as well. As I've shown above; 0.1 in decimal isn't actual 0.1 but 0.000110011... and so on. This means some basic maths can be completely wrong.
var x = 0.2 + 0.1; // x = 0.30000000000000004
You end up having to confuse the system to get the number you actually want. This can be done by * the number by 10 and then dividing it to get your actual wanted result.
var x = (0.2 * 10 + 0.1 * 10) / 10; // x = 0.3
Precision within computers floating point is very difficult and is even more difficult when there are multiple different implementations (or browsers) trying to do their best for speed and displaying the information they're given correctly.
There are quite a few different pieces of information regarding floating points and what the CSS processor (or JS as I expect may calculations will be the same) may be trying to achieve.
Exploring Binary - Why 0.1 does not exist
Javascript Numbers
Wikipedia - IEEE floating point
Wikipedia - Double-precision floating point
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.
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.