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
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
I've been reading several articles about SVG that make a clear distinction between using and not using units (this last case even has a name of its own), e.g.
<!-- the viewport will be 800px by 600px -->
<svg width="800" height="600">
<!-- SVG content drawn onto the SVG canvas -->
</svg>
In SVG, values can be set with or without a unit identifier. A
unitless value is said to be specified in user space using user units.
If a value is specified in user units, then the value is assumed to be
equivalent to the same number of “px” units. This means that the
viewport in the above example will be rendered as a 800px by 600px
viewport.
You can also specify values using units. The supported length unit
identifiers in SVG are: em, ex, px, pt, pc, cm, mm, in, and
percentages.
source
Is there any actual difference between omiting the unit and setting it to px?
Can I just set e.g. mm everywhere to avoid ambiguity, or I'll eventually be getting different results?
<svg width="800mm" height="600mm">
Disclaimer: what follows is pure guessing (I only learnt the basics of SVG last week) but I'm sharing it because I believe it could help others with my same doubts and I hope it doesn't contain serious errors.
The SVG canvas is basically a mental concept—a infinite plane where you use Cartesian coordinates to place stuff and move around. It isn't too different from stroking shapes in a sheet of graph paper where you've drawn a cross to identify an arbitrary point as coordinate origin, except that notebooks are not infinite. In the same way that tou draw a 3-square radius circle in the sheet and you don't care that those squares represent 12 mm, you draw shapes in your SVG canvas using unitless dimensions because it doesn't really matter what exact physical size they represent. The SVG spec uses the term "user units" to express this idea.
Using actual units only makes sense in two situations:
When our virtual user units need to interact with real world, e.g., the canvas is to be printed in a computer monitor.
When we want an element in our graph to be defined in such a way that it doesn't scale, neither up nor down, e.g. a stroke around a letter that needs to look identical no matter how we resize the logo it belongs to.
It's in this situation, more specifically #1, when the px equivalence comes in handy. When we need to render the graph or make calculations what involve actual units, unitless dimensions are interpreted as pixels. We can think of it as a default because we can render the canvas any size and, in any case, pixels are no longer physical pixels in these days of high-res displays and builtin zoom.
And, for all this, it's probably better to just omit units in your SVG code. Adding them in a general basis only makes code unnecessarily verbose.
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.
Does anyone have any general tips for reducing the size of a graph generated by graphviz (size as in area, not as in file size).
I have a fairly large graph (700 nodes). I set a smaller font size for each node, but it seems to only reduce the font size and not the actual node size. Are there any attributes to reduce the overall amount of blank space in the graph also? Thanks!
In my experience using graphviz to render graphs of that size (~ 700 nodes), minimal trial-and-error adjustment to this combination of attribute settings--some structural, some purely aesthetic--for all three objects (graph, nodes, and edges) should do what you want:
reduce the minimum separation between nodes, via 'nodesep'; e.g., nodes[nodesep=0.75]; this will make your graph being "too compact." (nodesep and ranksep probably affect how dot draws a graph more than any other adjustable parameter)
reduce the minimum distance between nodes of different ranks, e.g, nodes[ranksep=0.75]; 'ranksep' sets the minimum distance between nodes of different ranks--this will affect your graph layout significantly if your graph is comprised of many ranks
increase the edge weights, eg, edge[weight=1.2]; this will make the edges shorter, in turn making the entire graph more compact
remove node borders and node fill, e.g., nodes[color=none; shape=plaintext], especially for oval-shaped nodes, a substantial fraction of the total node space is 'unused' (ie, not used to display the node label); each node's footprint is now reduced to just its text
explicitly set the font size for the nodes (the node borders are enlarged so that they surround the node text, which means that the font size and amount of text for a given node has a significant effect on its size); [fontsize=11] should be large enough to be legible yet also reduce the 'cluttered' appearance (the default size is 14)
use different colors for nodes and edges--this will make your graph easier to read; e.g., set the node 'text' fontcolor to blue and the edge fontcolor to "grey" to help the eye distinguish the two sets of graph structures. This will make a bigger difference than you might think.
explicitly set total graph size, eg, graph[size="7.75,10.25"] (ensures that your graph fits on an 8.5 x 11 page and that it occupies the entire space)