Is there any difference between user units and pixels? - html

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.

Related

Preferred value to encode 96 DPI within PNG

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

Text size in standart printable points

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.

How to expand to a normal vessel with ITK when I have a skeleton line and every radius for pixels?

I did an thinning operation on vessels, and now I'm trying to reconstruct it.
How to expand them to normal vessels in ITK when I have a skeleton line and radius values for each pixel?
DISCLAIMER: This could be slow, but since no other answer has been suggested, here you go.
Since your question does not indicate this, I'm assuming that you're talking about a 2D image, but the following approach can be extended for 3D too. This is how I'd go about it:
Create a blank image with zero filled pixel values
Create multiple instances of disk/sphere ShapedNeighborhoodIterator each having a different radius on the blank image (choose the most common radii from the vessel width histogram).
Visit each pixel in the binary skeleton image. When you come upon a white (vessel skeleton) pixel, recollect the vessel radius at that pixel.
If you already have a ShapedNeighborhoodIterator for that radius value, take the iterator to the pixel location in the blank image and fill up a disk/sphere of white pixels centered about that pixel. If you don't have a ShapedNeighborhoodIterator for that radius value, create one and do the same operation.
Once you finish iterating over the skeletonized image, you will have a reconstructed tree in the other image. Note that step 2 is optional, but will help you achieve faster computation.

What are the units for the crop attributes in the imagedata element of WordML?

I am trying to extract images from a document saved as WordML. Some of the images are cropped from a single resource using attributes on the imagedata element eg:
<v:imagedata r:id="rId8" o:title="" cropbottom="32429f" cropright="44328f"/>
What are the units for the cropbottom and cropright attributes?
I have done some web searching and according to http://msdn.microsoft.com/en-us/library/bb229565%28v=vs.85%29.aspx the units should be percentages but don't seem to be.
In the example above the resulting image should come from the top left of the original and be a third of the width and half the height.
I'll answer my own question in the hope that it is useful to someone else.
According to ImageData Class - Office 2010
CropBottom ... specifies the how much to crop the image from the bottom
up as a fraction of picture size. Default is 0. This numeric value can
also be specified in 1/65536-ths if a trailing "f" is supplied. For
example, a value of "52429f" represents 52429/65536 or 0.8.

Reducing the size (as in area) of the graph generated by graphviz

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)