- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Fri, 15 Jan 2010 09:29:19 -0800
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: "robert@ocallahan.org" <robert@ocallahan.org>, www-style <www-style@w3.org>
- Message-Id: <63052F27-D494-4260-92B9-7D0AD4492CFA@gmail.com>
On Jan 14, 2010, at 4:26 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: > On Thu, Jan 14, 2010 at 12:38 PM, Brad Kemper <brad.kemper@gmail.com> wrote: >> As an evil idiot author, I feel much of the value of high resolution >> monitors would be wasted if I cannot e.g. draw a border that is one device >> pixel in width while still maintaining the proportion between that 1px >> measure and other measures. > > If you know that your output device is high-enough resolution to have > something like mapping 1 CSS px to 2x2 device pixels, you can always > draw a border with .5px width. Gah. And if I really want 2 device pixels I have to use 1px. Making it incompatible with existing Web pages where the author actually really wanted the one device pixel he thought he was specifying. > Alternately, if that use-case is > really determined to be important as we move into the future of higher > definition screens, the hairline unit people keep mentioning can be > employed (defined as "the minimum number of device pixels necessary to > draw a line that is visible to the human eye at standard viewing > distances"). Would you call that "true-px"? For high rez printing, I think it would be useless (close to invisible). For screens, I suspect most (or at least a huge portion of) Web authors would expect 1px to be 1 device pixel. And with this, many may go into all their style sheets and HTML files, and wherever something is measured in pixels, they'd add the same measurement as true-px. And not be too happy about it. Because despite what we decree from our ivory towers, they expect a pixel to be a pixel and not to be told that the pixel they authored wasn't REALLY the pixel they wanted, because we know best what they REALLY meant (I'm not saying I feel that way, but rather that I anticipate this sort of reaction). And because they really want their 1024px-wide layout to fit on a 1024 pixel-wide monitor, even if it has 140 dpi (138 is half way to (96 x 2), so anything in that range would be rounded to two device pixels per px, right?). I understand the reasoning of the current definition of px, and after thinking about it I think it may help to simply deal with those "2 device pixels = 1px" situations as **zoom**. Thus, "(1px:1 pixel ratio) = zoom:1" and "(1px : 2 pixel ratio) = zoom:2". Then when we provide that guidance about "0.0213 degrees" pixel sizes, we can say that whenever one device pixel would be bigger or smaller than 1px (after rounding to nearest integer), then a 'zoom' should be used to indicate this difference, and the user should have clear controls for changing the zoom level. Then, if the author really wants the one to one relationship for their page, they can set something like this: body { zoom:1; } That authored zoom level should then be reflected in any UA menu that showed the zoom level, and the user could override it if they want. > >>> Also, I think we have use cases for true dimensions. We might as well >>> ensure that 1px is 1/96 of an inch when printed, so that CSS absolute length >>> units take their expected values when printing. >> >> Right. Just as a device pixel is unambiguous on a monitor, but an inch is >> not, the situation is reversed in print. If I print to a PDF file, I can >> tell it to make something exactly one inch, but 1px has to be approximated >> (because device pixels are not too useful of a measure in high resolution >> printing; they vary too much between output devices). > > Yeah, I agree, and I think most of the working group did too. > Printing in ordinary situations (on normal paper, frex) should follow > physical units exactly. Good. I mentioned it mostly to lead into the part about scaling. > Scaling should of course scale the physical > units, ..and the px units too, since for print they would be exactly equal to 1/96in, making them de facto physical units in print. But, ah, I guess you are already agreeing with that too, below. > and exceptional circumstances such as printing on poster-size > paper should also potentially be treated as zooming (up to the program > doing the printing - if it designs with the *intention* of being > printed that large, it of course probably makes sense to respect > physical units exactly). > > >>> Exceptional circumstances like printing massive billboards would be ... >>> excepted. >> >> I disagree (ah, order is restored to the universe). If I create a PDF or >> Postscript file in which the design is 20 inches wide, then there is nothing >> exceptional about that. If I hand that file to a billboard company and tell >> them to print it at a ratio of one inch to one foot (or even if I do it >> myself by setting "1200%" in the print dialog box), then that is outside the >> purview of CSS. The scaling is more or less equivalent to zoom. >> If I, on the other hand, design my layout to be 20 feet wide, then there >> still need be no exception, as long as the output device can handle >> rasterizing that many dots, and the print driver doesn't freak out. >> If I am designing a (different) billboard with a DIV that is 240in wide, and >> then set a border on it that is 1px wide (1/96in), then I will quickly >> discover what an idiot I am (and probably already did, long ago), because >> the border will not be visible from a car driving by. But if I design >> something that later is to be scaled by 24x, then I can make my DIV 10in >> wide with a 1px border, and get very predictable results when that >> pre-scaled (pre-zoomed) border is 1/96in. > > Pretty sure I agree with you here. If the application intends to > design at that scale from the start, then physical units should be > real, and px should keep their standard ratio of 96 to the inch. If > the application is designing something at normal scale which is then > scaled up to billboard size, then all of this is still true, but the > printing-as-a-billboard is a zoom, which scales up all units equally. > > ~TJ
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Friday, 15 January 2010 17:30:02 UTC