How do I set the thickness of a border to a hairline, i.e. the thinnest possible line?
I suspect that "1px" might do the trick, but I am not quite sure how pixels get translated to the output medium. Possibly, they do not translate directly to printer pixels.
In my case, I want to make the thinnest possible line for a cutting line. It should be only barely visible, and possibly utilize the thinnest that the printer can represent.
TLDR: On printed media, there are no pixels as such, and in that context "1px" should stand for "thinnest visible/printable width". An alternative would be giving a measurement in absolute units, like 0.1mm.
Linking pixels to dpi makes sense only when output resolution is defined (mandatory for raster output, unlikely otherwise), so 96dpi is as good a number as any other -- unless it results in 1px lines being thicker than widths in some other unit, as per the doc I linked.
That reminds me of the time when Chrome started translating physical lengths (in cm or in) to screen by assuming that screen dpi = 72 (or whatever it was), and ignoring any actual OS settings. It got even funnier when Mozilla followed suit
You're welcome! About Prince, I know, you're right, so keep doing 0.1pt for the moment. I just think the guys who develop Prince lurk here and they might hear us -- who knows, they might even decide to comply with obscure bits of the W3C specs like this someday. Hush-hush
Comply... except where it contradicts other bits of the same specs, that is! I just checked again and apparently the W3C guys decided to alter the specs and now "CSS requires that 1px must be exactly 1/96th of an inch in all printed output". How can 1px be both that and 'thinnest visible'? Answer: it can't. One can only guess developers' heads would keep more hair on them if the W3C could stick with something...
Note: This definition of the pixel unit and the physical units differs from previous versions of CSS. In particular, in previous versions of CSS the pixel unit and the physical units were not related by a fixed ratio: the physical units were always tied to their physical measurements while the pixel unit would vary to most closely match the reference pixel. (This change was made because too much existing content relies on the assumption of 96dpi, and breaking that assumption broke the content.)
The article I previously linked from my bookmarks used to be a pretty nice summary of all things unit in CSS when it came out (ca. 2010?). It still is, but unit definitions have changed meanwhile and I hadn't read it again in years. In that article, however, you can find traces of the previous definition I alluded to:
Bert Bos wrote:
The px unit is the magic unit of CSS. It is not related to the current font and usually not related to physical centimeters or inches either. The px unit is defined to be small but visible, and such that a horizontal 1px wide line can be displayed with sharp edges [...] The px is thus not defined as a constant length, but as something that depends on the type of device and its typical use.
Now the article not only mentions the current 1px = 1 96^th^ of an inch thing, but also the episode about physical units on screen I referred to, which had a different (yet equally sad) outcome:
Bert Bos wrote:
In the past, CSS required that implementations display absolute units correctly even on computer screens. But as the number of incorrect implementations outnumbered correct ones and the situation didn't seem to improve, CSS abandoned that requirement in 2011. Currently, absolute units must work correctly only on printed output and on high-resolution devices.
----------
Now, a pseudo-practical* question. Mike said 'px units are 96dpi', which is close to but not quite the same as "CSS requires that 1px must be exactly 1/96th of an inch in all printed output". If Prince PDF output is set to raster at a higher resolution, are 1px lines still rendered as 1 96^th^ of an inch wide?
* I used to avoid px units in printing and now I'll sure as hell stay clear of them, so it is all academic to me.
Pixel units can be rescaled inside SVG or by CSS transforms or @page shrink-to-fit, but outside of these special cases they are always 96dpi unless overridden by the --css-dpi option.
(The DPI used for rasterisation is an independent option, and most PDFs don't include rasterised content and are resolution-independent anyway).
