11644 2006-11-18 05:58:20 -0800 Absolute lengths assume 96.0 DPI 2013-04-11 02:37:13 -0700 1 1 1 Unclassified WebKit CSS 420+ Mac OS X 10.4 NEW P3 Normal --- 1 nickshanks webkit-unassigned andrejohn.mas mail+community+webkit mrmazda robburns1 webkit-bugs oldest_to_newest 45422 0 nickshanks 2006-11-18 05:58:20 -0800 CSS lengths specified using units of cm/mm/in/pc/pt should be accurate across all output devices. This patch gets the DPI of the user's main screen and uses that to calculate to how many CSS pixels that length corrisponds. Patch assumptions: • 1:1 ratio of CSS pixels to device pixels • CoreGrahics' ‘main device’ is the only device that matters 45412 1 11564 nickshanks 2006-11-18 06:00:16 -0800 Created attachment 11564 First draft 45408 2 11565 nickshanks 2006-11-18 06:03:49 -0800 Created attachment 11565 visual test page (requires human with ruler) The first fve lines should all be the same length, which may but most liekely will not be the same as the bottom line. If you have an old VGA display that doesn't know how big it is, the lines will all be of equal length. 45364 3 hyatt 2006-11-18 16:10:18 -0800 Web designerss assume 96dpi. We have no choice but to use that as the default for absolute units. The first Safari beta actually tried to use real DPI and the results were pretty disastrous. Not only did we mess up the rendering of a lot of Web sites, but a lot of prominent Web developers also blogged about our mistake and appealed to us to fix the problem (which we then did in beta #2). I could see the value in having a WebKit pref to control this, since I could see how a WebKit app might want absolute units to behave in a more desirable way, but the default should remain 96. 45349 4 hyatt 2006-11-18 16:11:23 -0800 FWIW, using 96 dpi is actually compliant with the CSS spec, since there's a fuzzy "at arm's length" rule. 44984 5 nickshanks 2006-11-19 14:46:13 -0800 "Web designers assume 96dpi." - This is what i want to change, but I can only go one step at a time, and haven't looked at the Mozilla code for four years, so I am starting here. I think your last point is a case of the specification pandering to implementations, but I would welcome a DPI preference in Safari too (not just other WK apps). Personally I'd rather have a pedantically correct browser than to have one that is dumbed down because of inept web developers and/or designers. An additional preference that would compliment this is to have the web DPI setting user-settable as it is in Internet Explorer ("Language/Fonts" preference screen - that browser has a nifty adjustable ruler to play with!). It would be of benefit to web developers if they could adjust the assumed DPI on the fly to check their site works at non-96.0 values, and that they were frequently made aware of the facility and encouraged to check. Screens at the moment are about 96 dpi anyway (mine are 86 and 99) so an accurate rendering wouldn't be that different. (Try setting IE to 30 or 200 dpi and go surfing, starting with the test page attached to this bug; few sites I frequent show DPI-related rendering errors) I was aware of and loosely following the discussions surrounding Safari's early DPI issues, though I seem to recall you had fixed the browser at 72.0 with a default font size of 12 (px/pt), and you resolved it by changing the DPI to 96 so 12pt would equal 16px - and that it did not do any checking of the actual screen dimensions as this patch attempts to do, but of course I could be wrong there. What use are the absolute units mm/cm/in/pc/pt if they are not independent from px ? They might as well not exist. (I think pc and cm are rather redundant anyway :-) 44339 6 nickshanks 2006-11-25 15:03:10 -0800 *** Bug 9541 has been marked as a duplicate of this bug. *** 44340 7 hyatt 2006-11-25 16:15:39 -0800 "What use are the absolute units mm/cm/in/pc/pt if they are not independent from px ? They might as well not exist. (I think pc and cm are rather redundant anyway :-)" That's correct. They are essentially useless. 20861 8 robburns1 2007-02-28 15:01:19 -0800 I have to say that I don't have an easy solution to this problem, but I think there appears to be a lot of confusion on this on both sides. The CSS specification was quite ahead of its time in terms of resolution (and general device) indepdendence. The OS world is just now catcfhing up with this. With resolution indpendence successfully implemented, it is the px measurement that becomes obsolute (not the absolute measures). Then a physical inch should equal a screen inch (at least it should at the default magnification of most displays). However, it's hard to imagine what role there is in this resolution indpendent world for a pixel unit. By defining a pxel as 1/96th of an inch, the pixel becomes an abolute unit (like the other absolute units always in the same ratio). If an author does actually need a px unit (and I can't think of any reason off of the top of my head), then it's no longer available. Perhaps a new unit could be added ("pixel") that would still be available for that reason. Take the iPhone display (160 dpi) or a larger and higher resolution display (for example a future Cincema Display at say 192dpi). There, since size is not at a premium) the default magnification of the screen should be such that an inch on the screen should equal a physical inch (therefore, likewise for all the other absolute units). A px on that display is now 1/96 of an inch (2 device pixels). A display inch is equal to a physical inch (or it should be at the default magnification). The iPhone display is a different story because there's reason due to minmal screen real estate to change default magnification from 1:1 (virtual:physical measurement). So it's not the absolute measures that are usesless. It's the current px measure that is becoming another absolute measure (1/96 of an inch). The other issue is one of the default magnification of a display. Here I think it should be 1:1 unless screen real estate is ilimited (as in the iPhone) or the audience distant is great (as in TV or Projection media) However, the default magnification is not something WebKit needs to worry about. If there's a need for a genuine pixel measure (a unit relative to resolution), then implementations (and the CSs recommendation) could add something like "pixel". Again, I can't imagine what use an actual resolution relative unit would serve. Web designers have always been using it as an absolute measure (whether as 1/72 of an inch when the Mac graphical inteface arose or 1/96 of an inch when the Windows graphical interface came of age). Those are absolute (though changing) measures 20854 9 robburns1 2007-02-28 15:17:29 -0800 One thing I should add. WebKit should make sure that a CSS inch equals any other inch. In other words an inch in WebKit should equal an inch in any other application running in the same environment. In this way the magnification (default or otherwise) of a display is uniform. 1 css inch should be the same length as an inch on a ruler in another application. Obviously, the OS has to provide a mechanism to ensure (and the OSs are). However, WebKit should not change a CSS inch to some other length independent of the environment inch. 20838 10 hyatt 2007-02-28 16:40:53 -0800 The CSS px is a relative unit and is allowed to scale at high DPI. 20762 11 robburns1 2007-02-28 18:48:51 -0800 In reply to #10: Yes I know that a px is a relative unit and is allowed to scale at high resolutions according to the CSS recomendation. However, according to the expectations of Web designers and user-agent implementers it is not. As you said in comment #3: "Web designerss assume 96dpi." This makes a relative unit (one that is suppoed to be relative to the pixel resolution of a device) no longer a relative unit. It is now precisely 96 dots per inch: it is locked in a constant ratio with all the other absolute units. If a px is always 1/96 of an inch regardless of device resolution, then it's an absolute and not a relative measure. That makes it an absolute unit as well. Any unit locked in a constant ratio with the absolute units is an absolute unit. Obviously even the absolute units are relative to the magnification level. Em and Ex remain relative units. A device pixel likewise remains a relative unit. A CSS pixel become just another absolute unit (which are all functionally equivalent culturally different representations of the same absolute lenghts). I don't see a problem with changing px to an abolute unit. Savvy content creators know to avoid px because it's not really all that useful as a device pixel. As this conventionally interpreted CSS pixel, it's just another absolute unit. The same as using pts and multiplying by 1-1/3. But I just want to make it clear (because from the discussion it doesn't seem clear) that this doesn't obsolete the absolute measure. It eliminates the px measure as defined in the recommendation (which the arms lenght and high resolution passages make fuzzy already). Absolute measures: pt, pc, in, cm, mm, px Relative meausers: ex em Even the absolute measures are relative to display magnification (or the positioning and zoom of a projector). Most modern displays change the magnification level to less than 1x so that a phsyical ruler placed over the software ruler (in say TextEdit) do not equal. It is not WYSIWYG in the size sense that the term is (or was sometimes) used. 84307 12 andrejohn.mas 2008-06-24 14:13:05 -0700 It is now 2008 and MacOS X 10.5 has resolution independence, but from my tests I still see that specifying 6cm in a style sheet does not result in 6cm on screen. A quick test with Opera 9.5, Firefox 3 and Safari 3 shows that a table specified to have width of 8cm is rendered to be 6.9cm, so at least they are consistent with each other. I tested on a 15" MacBook Pro (Core Duo) at native resolution. I assume they are all following the 96dpi assumption. I don't know the actual dpi of my screen, so I can't check. I see the section in the specifications where it is indicated the resolution assumption for a pixel (CSS2 section 4.3.2), but for cm all I see is section 4.3.2 of CSS2 where it says: "Absolute length units are only useful when the physical properties of the output medium are known." CSS1 says the same thing in section 6.1. For this reason I ask myself if the not rendering a cm as a real world cm is indeed an issue of misinterpretation? Are there any plans to address this issue? 84395 13 nickshanks 2008-06-25 07:07:59 -0700 You can find out your screen's DPI by downloading and compiling this: http://web.nickshanks.com/downloads/software/sourcecode/DPIFinder.tar.bz2 It outputs information to the console so it's easiest to run it in Xcode and look at the debug console there. The app will launch and not do anything, kinda crap but it's just a quick hack. I will clean it up if there's demand. Make sure you run the app with your LCD panel set to native resolution, it reports the displayed pixels per inch (and in millimetres) so you can get different results if you run at lower resolutions. 84411 14 hyatt 2008-06-25 09:18:30 -0700 (In reply to comment #12) > Are there any plans to address this issue? > No. We cannot address this issue without breaking Web sites. 84426 15 robburns1 2008-06-25 11:58:55 -0700 Resolution independence isn't really here yet anyway, so the difference is size is not something that is directly fixed by resolution independence nor involved with anything you're seeing today. But I do think this could be fixed once resolution independence does arrive. Consider this: A 96dpi screen right now treats 1 CSS inch as 1 physical inch. Or in the WebView, 1 physical inch is 96 units (CSS pixels) However, in NSView coordinates that 1 inch is 72 units wide 72 or points. On a 96dpi screen then (without resolution independence), 1 inch is 0.75" measured with a physical ruler. In other words the base zoom of the screen is 75%. So the NSView one inch wide cannot both be 72 units and 96 units at the same time. The way to think about this is the following: * WebView has an internal zoom factor set so that it is 133% larger than the OS zoom factor. * With resolution independence the OS will scale the display according to the users needs (ideally with user defaults permitting adjustments) * on modern displays (e.g., 111 dpi) the OS scales the output to about 65% of actual size * WebKit scales its inner-application output to 133% * together that's about 85.45% of actual size (so the comment #12 example 8cm becomes 6.8 cm when measured with a physical ruler on the display) So in order to fit in with upcoming resolution independence on Mac OS X (and presumably other OSs I"m less familiar with), a WebView simply needs to add a method to set and get its base zoom factor. By default it should be 1.33x so as to not break web sites (as Dave points out). However, other applications may want to set it to 1. When setting the factor to another value an affine transformation is set on the WebView to scale it accordingly. Internally this could only scale when the value is set to something other than 1.33x so as to not cause any performance hit for mainstream web use (the magic of OOP and opaque methods). Eventually, though when resolution independence becomes more widespread and users start widely varying the base zoom of their displays, it may not at all seem unusual for WebKit to display using a zoom of 1x instead of 1.33x. However, it doesn't seem like a good idea to leave something as central as WebView as incompatible with the resolution independence of the rest of the OS. Are there any problems caused by this solution that I have missed? 84450 16 robburns1 2008-06-25 22:32:52 -0700 I wonder if putting this in terms of Mac OS X resolution independence would make more sense. A summary such as: "WebView uses 1.33 points per unit rather than 1.0 points per unit standard for an NSView" In other words a CSS inch = 96 NSView units = 1.33 * 72 points = 1*33 * 1 inch or 0.75 CSS inch = 72 NSView units = 72 points = 1 inch It's important to underscore here that both CSS and NSView were both long ago designed for resolution independence (for example both use floats for dimensions rather than integers like other resolution dependent APIs). The issue then is that currently WebView does not make a CSS inch equal to an NSView inch which makes it inconsistent with other applications and even other views running in the same application on the same system. BTW, daring fireball has a table of display resolutions for some recent (as of last year anyway) Apple models: http://daringfireball.net/2007/06/high_res_macbook_pro#fnr1-2007-06-07 84456 17 nickshanks 2008-06-26 01:39:46 -0700 The long and the short of it is that some apps that use WebKit, whether locally running in a WebView or online via a browser (such as a canvas-based, platform-independent CAD app), will need to have 1cm in CSS == 1cm on the output screen/printer/plotter. Anything that is the wrong scale will be laughably unacceptable in a professional environment. Variable DPI *has* to be supported for HTML-based applications, and Safari will set it to 96.0 for browsing the public internet, which is fine. My only concern is that when implemented, this ability will not be exposed in the browser as a user feature (like it is in Mac IE). That would be disappointing. 84457 18 hyatt 2008-06-26 01:42:29 -0700 Yeah sure, I think it's fine to make a pref out of the 96 number. 84458 19 hyatt 2008-06-26 01:47:40 -0700 This is not really going to be high priority for us at Apple though, since we have yet to receive a single request from any WebKit-based app to add such a feature. I think this fall squarely in the realm of theoretical purity, but have no real objection to making the 96dpi number into a WebKit preference. 84472 20 robburns1 2008-06-26 07:07:01 -0700 As a WebView developer I would like to see this bug addressed. I'm surprised Apple itself doesn't also want its supporting teams to support resolution independence and all of the work Apple has put into that. I'd just really like to see someone central to the WebKit team take the time to understand this bug. It is not about the 96dpi issue. CSS sets 96dpi as the recommended screen and print resolution. Fine. That has nothing to do with resolution independence (which is why I recommended renaming this summary). The issue is that WebViews do not fit in with other NSViews because an NSView unit is supposed to be a point — especially in a resolution independent environment — and WebView treats the unit as less than a point (0.75% of a point). That means using two NSView classes (or their subclasses) side by side in an application where units matter will lead to the WebView being larger than the non-WebView NSView. So in the future no one should necessarily care about whether pixels are 96dpi or 80dpi or whatever. What matters is the scale of the WebView compared to the other NSViews. Perhaps I should file a separate bug on that, but the gist of the discussion is about resolution independence and the 96dpi for pixels has got little to do with resolution independence (if anything setting a pixel to 1/96th of an inch improves resolution independence by turning a pixel into a resolution independent unit as strange as that sounds). 84475 21 nickshanks 2008-06-26 07:45:18 -0700 Then I recommend filing a seperate bug. It seems like you are changing the original purpose of this bug. I intended it to be about asking for 1cm and getting 1cm on the output medium, not what you seem to want, which is asking for 1cm and getting the same result as other on-screen NSViews would produce if asked for the same. You're not bothered if it's 1cm or some other scaled value, I gather? I envisage something like this: [webView scaleForInternet] -> sets WebKit to 96 DPI [webView scaleForDesktop] -> sets WebKit to 72 DPI (this is what you want, Robert) [webView scaleForMainDisplay] -> sets WebKit to DPI of main display [webView scaleToCustomValue:133.33] -> for 17" MBPs [webView scaleToCustomValue:160.0] -> for iPhones 84500 22 hyatt 2008-06-26 11:34:17 -0700 (In reply to comment #21) > Then I recommend filing a seperate bug. It seems like you are changing the > original purpose of this bug. Agreed. Rob, you are talking about something different from this bug. 84502 23 hyatt 2008-06-26 11:40:21 -0700 I also think you're making assumptions about how resolution independence is going to work in WebKit on OS X. Our own thinking about it was that the CSS pixel would scale. In other words as the view scale changes, so does the CSS pixel scale. The ratio of 96dpi would still be preserved (thus absolute units would scale as well). Given that information, maybe you can clarify what you want. 84508 24 robburns1 2008-06-26 12:30:07 -0700 Much of this bug discusses resolution independence. I apologize if I'm misinterpreting this, but the resolution independence team at Apple says that applications using an NSView should treat the units of the NSView as points. So 72 points equals one inch (again keep in mind that with resolution independence this has got nothing to do with DPI at this point which is handled at a different level separate from WebKit in a resolution independent world or a resolution independent redefined world). (In reply to comment #23) > I also think you're making assumptions about how resolution independence is > going to work in WebKit on OS X. Our own thinking about it was that the CSS > pixel would scale. In other words as the view scale changes, so does the CSS > pixel scale. The ratio of 96dpi would still be preserved (thus absolute units > would scale as well). Given that information, maybe you can clarify what you > want. Yes, I understand that the units will scale as well. However, the treatment of WebView units as 75% of a point instead of as 1 point means that the scale of WebViews is different than all other NSViews (and all other views) on the system. So when you draw a ruler using CSS units it will be a different size than the ruler drawn in an NSView using NSView units. It creates an inconsistency between apps that is jarring to users and unnecessary. Having said that I do understand that the scale of text and such in webpages is such that web authors are already compensating for this difference so that authors might use smaller fonts in web pages than in other pages because they get scaled up by systems already (due to IE most likely). (In reply to comment #21) > Then I recommend filing a seperate bug. It seems like you are changing the > original purpose of this bug. I intended it to be about asking for 1cm and > getting 1cm on the output medium, not what you seem to want, which is asking > for 1cm and getting the same result as other on-screen NSViews would produce if > asked for the same. You're not bothered if it's 1cm or some other scaled value, > I gather? I'm a bit uneasy with bringing up this example, but it seems apt here. What about the case of projection media in a large conference halls or television media in someone's home theater. Here even more than computer displays users prefer to have things scaled at other than 100%. Isn't it better that one inch in InDesign is equal to one inch in Safari (or another WebKit application)? Why should the WebKit application always maintain a 100% scale no matter how the user changes her preferences. > > I envisage something like this: > > [webView scaleForInternet] -> sets WebKit to 96 DPI > [webView scaleForDesktop] -> sets WebKit to 72 DPI (this is what you want, > Robert) > [webView scaleForMainDisplay] -> sets WebKit to DPI of main display > [webView scaleToCustomValue:133.33] -> for 17" MBPs > [webView scaleToCustomValue:160.0] -> for iPhones > Just to clarify what I want has got nothing to do with DPI at all. I'm pushing for better understanding of resolution independence and for more consistent implementation of resolution independence. Resolution independence implies that pixels dependent units are not used at all. By defining a pixel as 1/96 of an inch (which CSS 2 does) even a pixel is now a resolution independent unit (because it is not a pixel at all anymore but a unit that is always in the same ration with an inch). I think one has to consider what a truly resolution independent device will look like from a developer and web authoring point of view and think backwards to where we are now (which is what I think the resolution independence team at apple is doing). In that world every view is measured in points as floats (or inches or mm or cm, etc). Only low-level developers and those using OpenGL need to ever concern themselves with pixels and device resolution. Once were at that point, it doesn't concern any of us (as webkit developers or as web site developers) what the resolution of a display is because we're now firmly in the resolution independent world (everything is in terms of absolute units even pixels are absolutely 1/96 of an inch). Ideally similar applications should display their content at the same scale (whatever the OS default is or whatever the user selects). The scale no longer changes as the bit resolution of the screen increases. If a user likes a 133dpi 17" display at 70% of full scale, then when the user switches to a 500dpi 17" display they will likely continue to want the scale at 70% of full (though the users preferences may be effected in subtle ways by the drastically increased resolution; they're more likely concerned about the obvious screen real estate than the subtlety of the resolution). Obviously apps such as Google Earth will not be at 70% of full scale (where one mile equals 0.7 miles :-). But for like applications, that deal with NSRulers for example, should all be consistently scaled (or it disorients users). The issue Nick raises on the scale on the screen is then up to the user. If they want their display at 100% scale, then they will set it at 100% scale. In that circumstance a physical ruler held up to an NSRuler will match. The same physical ruler held up to an NSRuler accompanying a WebView will not match (since a WebView currently does not follow the resolution independence team's guidelines on resolution independence). However, the WebView difference aside, it is really up to the user how they want the display scaled (once we're fully resolution independent). It should not be up to the WebView to maintain 1 inch equals to 1 inch as the user scales the rest of the display in a vastly different scale (like to 50% or 25%, 300% or so on). So fixing the bug I thought this was about is completely at odds with fixing the bug Nick says this is about. What I want to see is better adherence to resolution independence. What the other approach does is disregard the users preferences for on screen scale and maintains WebViews at 100% even as the scale of everything around it shrinks or grows drastically. That would be the wrong approach in my opinion. How to get authors to stop authoring to IE inappropriate scaling precedence is a completely separate problem, though a solution to that too improves resolution and device independence because it makes it easier to create output that works with the same stylesheet declarations whether on high resolution printer or high-resolution display. 84535 25 andrejohn.mas 2008-06-26 19:05:29 -0700 > I'm a bit uneasy with bringing up this example, but it seems apt here. What > about the case of projection media in a large conference halls or television > media in someone's home theater. Here even more than computer displays users > prefer to have things scaled at other than 100%. Isn't it better that one inch > in InDesign is equal to one inch in Safari (or another WebKit application)? Why > should the WebKit application always maintain a 100% scale no matter how the > user changes her preferences. Well I would take the approach that the 1cm specified = 1cm displayed would be correct on a standard display. By a standard display I mean anything like a computer monitor or a sheet of paper. A projector would be a 'scaled display', therefore it would be accepted that what is displayed is a scaled version of what is specified. The other question is how many DPI is a projector, since it largely depends on the distance of the projector from the wall and I generally there is no clear feedback on the actual display size. Though how we deal with a 'scaled display' in Webkit is certainly an interesting problem and this would probably be handled slightly differently to a regular display. The other thing is trying to make things feel natural for the user, while not trying to be too smart with the approach. Two attributes I would be tempted to see are: - boolean maintainScale : whether or not to follow screen scale - double zoom : the zoom ratio 84557 26 nickshanks 2008-06-27 00:50:13 -0700 To be clear, I wasn't advocating enforcement of physical size after scaling the page, according to the user's browser or GUI preferences, only that the CSS px-per-inch ratio be variable, before any re-scaling is applied. 84564 27 robburns1 2008-06-27 08:32:53 -0700 (In reply to comment #26) > To be clear, I wasn't advocating enforcement of physical size after scaling the > page, according to the user's browser or GUI preferences, only that the CSS > px-per-inch ratio be variable, before any re-scaling is applied. > OK. that's a much narrower issue then. To me this actually undermines resolution independence since it puts focus on pixel resolution instead of focussing on absolute units. Ideally the pixel would have never been added to CSS because it undermines resolution independence. Savvy authors have known to avoid it whenever possible. When CSS 2.0 made a pixel into 1/96 of an inch it made pixels into an absolute unit (since regardless of resolution — whether 72dpi or 1200dpi — the pixel is always 1/96 of an inch). Making the pixel size variable places focus on pixels again when we should really just let them slip into obscurity (or be used to specify a small unit like 1/96 of an inch rather than having to type: "0.01041... in"). The second issue of widely varying resolutions for displays will already be fixed by resolution independence in Mac OS X and presumably other OSs when it is finally implemented so there's no need to do that at the WebKit level. The other issue then (the one I thought this bug was about) is that the size of an inch in a WebView is different than the size of an inch in an NSView. An NSRuler must be scaled differently when the client view is an WebView than when it is a ancestor class NSView. This is due to the history of IE defining a pixel to be 1/96 of an inch by default in a resolution dependent environment where one pixel also equals one point). Authors have become accustomed to this and have scaled their text and images down compared to other content because they know that web browsers will scale them back up again. One thought that occurred to me is that browsers could cheat down this scaling like 11% every 5 years until 133% became 100% (in 2025 or so). 84745 28 nickshanks 2008-06-30 00:12:05 -0700 The ideal solution would be for IE8 to stop supporting px units. :-) 317418 29 mrmazda 2010-12-05 15:45:00 -0800 Is there a webkit equivalent to mozmm? Currently, I have a lot of special demo pages that, because of the 96 assumption, lie to a current Webkit (or current Opera or IE, but not Gecko) user, such as http://fm.no-ip.com/Auth/dpi-screen-window.html and http://fm.no-ip.com/Auth/Font/fonts-ptdemo.html and http://fm.no-ip.com/Auth/Font/fonts-comps-droid.html 414472 30 mail+community+webkit 2011-06-02 14:52:21 -0700 As this issue isn't really resolved and likely never will be in a good manner, i'd like to chime in late with a link containing my opinion on how we got here and the porblems faced with current solutions, as well as a simple way forward that i hope webkit will think carefully about. It reflects some comments made here too. http://static.zealous-studios.co.uk/projects/web_tests/PPI%20tests.html 873646 31 nickshanks 2013-04-11 02:37:13 -0700 Another update on the issue, from A List Apart: http://alistapart.com/column/responsive-typography-is-a-physical-discipline Especially pertinent is footnote number 2 and the EDID/DisplayID discussion in the comments: "I would much rather change the specification so that px always refers to device pixels, in always refers to actual, physical inches, cm always refers to actual physical centimeters, and so on." 11564 2006-11-18 06:00:16 -0800 2010-06-10 15:44:47 -0700 First draft dpi.diff text/plain 9627 nickshanks SW5kZXg6IFdlYkNvcmUvV2ViQ29yZS54Y29kZXByb2ovcHJvamVjdC5wYnhwcm9qCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KLS0tIFdlYkNvcmUvV2ViQ29yZS54Y29kZXByb2ovcHJvamVjdC5wYnhwcm9qCShyZXZpc2lv biAxNzgyNSkKKysrIFdlYkNvcmUvV2ViQ29yZS54Y29kZXByb2ovcHJvamVjdC5wYnhwcm9qCSh3 b3JraW5nIGNvcHkpCkBAIC0yNzIzLDYgKzI3MjMsOCBAQAogCQlFMTQ4NDJGRjBBNjc0QTMxMDA3 RTREMzkgLyogVGV4dENvZGVjSUNVLmNwcCBpbiBTb3VyY2VzICovID0ge2lzYSA9IFBCWEJ1aWxk RmlsZTsgZmlsZVJlZiA9IEUxNDg0MkZFMEE2NzRBMzEwMDdFNEQzOSAvKiBUZXh0Q29kZWNJQ1Uu Y3BwICovOyB9OwogCQlFMTQ4NDMyRjBBNjc0RkMyMDA3RTREMzkgLyogVGV4dENvZGVjTWFjLmgg aW4gSGVhZGVycyAqLyA9IHtpc2EgPSBQQlhCdWlsZEZpbGU7IGZpbGVSZWYgPSBFMTQ4NDMyRTBB Njc0RkMyMDA3RTREMzkgLyogVGV4dENvZGVjTWFjLmggKi87IH07CiAJCUUxNDg0M0Q2MEE2NzU0 QTYwMDdFNEQzOSAvKiBUZXh0Q29kZWNNYWMuY3BwIGluIFNvdXJjZXMgKi8gPSB7aXNhID0gUEJY QnVpbGRGaWxlOyBmaWxlUmVmID0gRTE0ODQzOTEwQTY3NTJCRjAwN0U0RDM5IC8qIFRleHRDb2Rl Y01hYy5jcHAgKi87IH07CisJCUUxN0VGMThCMEIwRjI4NEQwMDgzNkNBNiAvKiBQcmltaXRpdmVW YWx1ZS5oIGluIEhlYWRlcnMgKi8gPSB7aXNhID0gUEJYQnVpbGRGaWxlOyBmaWxlUmVmID0gRTE3 RUYxODkwQjBGMjg0RDAwODM2Q0E2IC8qIFByaW1pdGl2ZVZhbHVlLmggKi87IH07CisJCUUxN0VG MThDMEIwRjI4NEQwMDgzNkNBNiAvKiBQcmltaXRpdmVWYWx1ZS5jcHAgaW4gU291cmNlcyAqLyA9 IHtpc2EgPSBQQlhCdWlsZEZpbGU7IGZpbGVSZWYgPSBFMTdFRjE4QTBCMEYyODREMDA4MzZDQTYg LyogUHJpbWl0aXZlVmFsdWUuY3BwICovOyB9OwogCQlFMUVCQkJENDBBQUM5Qjg3MDAxRkU4RTIg LyogQ1NTQ2hhcnNldFJ1bGUuY3BwIGluIFNvdXJjZXMgKi8gPSB7aXNhID0gUEJYQnVpbGRGaWxl OyBmaWxlUmVmID0gRTFFQkJCRDMwQUFDOUI4NzAwMUZFOEUyIC8qIENTU0NoYXJzZXRSdWxlLmNw cCAqLzsgfTsKIAkJRTFGMDQyNDYwOTgzOTM4OTAwNjY5NEVBIC8qIHhtbGh0dHByZXF1ZXN0LmNw cCBpbiBTb3VyY2VzICovID0ge2lzYSA9IFBCWEJ1aWxkRmlsZTsgZmlsZVJlZiA9IEUxRjA0MjQ0 MDk4MzkzODkwMDY2OTRFQSAvKiB4bWxodHRwcmVxdWVzdC5jcHAgKi87IH07CiAJCUUxRjA0MjQ3 MDk4MzkzODkwMDY2OTRFQSAvKiB4bWxodHRwcmVxdWVzdC5oIGluIEhlYWRlcnMgKi8gPSB7aXNh ID0gUEJYQnVpbGRGaWxlOyBmaWxlUmVmID0gRTFGMDQyNDUwOTgzOTM4OTAwNjY5NEVBIC8qIHht bGh0dHByZXF1ZXN0LmggKi87IH07CkBAIC01NzQyLDYgKzU3NDQsOCBAQAogCQlFMTQ4NDJGRTBB Njc0QTMxMDA3RTREMzkgLyogVGV4dENvZGVjSUNVLmNwcCAqLyA9IHtpc2EgPSBQQlhGaWxlUmVm ZXJlbmNlOyBmaWxlRW5jb2RpbmcgPSA0OyBsYXN0S25vd25GaWxlVHlwZSA9IHNvdXJjZWNvZGUu Y3BwLmNwcDsgcGF0aCA9IFRleHRDb2RlY0lDVS5jcHA7IHNvdXJjZVRyZWUgPSAiPGdyb3VwPiI7 IH07CiAJCUUxNDg0MzJFMEE2NzRGQzIwMDdFNEQzOSAvKiBUZXh0Q29kZWNNYWMuaCAqLyA9IHtp c2EgPSBQQlhGaWxlUmVmZXJlbmNlOyBmaWxlRW5jb2RpbmcgPSA0OyBsYXN0S25vd25GaWxlVHlw ZSA9IHNvdXJjZWNvZGUuYy5oOyBsaW5lRW5kaW5nID0gMDsgbmFtZSA9IFRleHRDb2RlY01hYy5o OyBwYXRoID0gbWFjL1RleHRDb2RlY01hYy5oOyBzb3VyY2VUcmVlID0gIjxncm91cD4iOyB9Owog CQlFMTQ4NDM5MTBBNjc1MkJGMDA3RTREMzkgLyogVGV4dENvZGVjTWFjLmNwcCAqLyA9IHtpc2Eg PSBQQlhGaWxlUmVmZXJlbmNlOyBmaWxlRW5jb2RpbmcgPSA0OyBsYXN0S25vd25GaWxlVHlwZSA9 IHNvdXJjZWNvZGUuY3BwLmNwcDsgbGluZUVuZGluZyA9IDA7IG5hbWUgPSBUZXh0Q29kZWNNYWMu Y3BwOyBwYXRoID0gbWFjL1RleHRDb2RlY01hYy5jcHA7IHNvdXJjZVRyZWUgPSAiPGdyb3VwPiI7 IH07CisJCUUxN0VGMTg5MEIwRjI4NEQwMDgzNkNBNiAvKiBQcmltaXRpdmVWYWx1ZS5oICovID0g e2lzYSA9IFBCWEZpbGVSZWZlcmVuY2U7IGZpbGVFbmNvZGluZyA9IDMwOyBsYXN0S25vd25GaWxl VHlwZSA9IHNvdXJjZWNvZGUuYy5oOyBwYXRoID0gUHJpbWl0aXZlVmFsdWUuaDsgc291cmNlVHJl ZSA9ICI8Z3JvdXA+IjsgfTsKKwkJRTE3RUYxOEEwQjBGMjg0RDAwODM2Q0E2IC8qIFByaW1pdGl2 ZVZhbHVlLmNwcCAqLyA9IHtpc2EgPSBQQlhGaWxlUmVmZXJlbmNlOyBmaWxlRW5jb2RpbmcgPSAz MDsgbGFzdEtub3duRmlsZVR5cGUgPSBzb3VyY2Vjb2RlLmNwcC5jcHA7IHBhdGggPSBQcmltaXRp dmVWYWx1ZS5jcHA7IHNvdXJjZVRyZWUgPSAiPGdyb3VwPiI7IH07CiAJCUUxRUJCQkQzMEFBQzlC ODcwMDFGRThFMiAvKiBDU1NDaGFyc2V0UnVsZS5jcHAgKi8gPSB7aXNhID0gUEJYRmlsZVJlZmVy ZW5jZTsgZmlsZUVuY29kaW5nID0gNDsgbGFzdEtub3duRmlsZVR5cGUgPSBzb3VyY2Vjb2RlLmNw cC5jcHA7IHBhdGggPSBDU1NDaGFyc2V0UnVsZS5jcHA7IHNvdXJjZVRyZWUgPSAiPGdyb3VwPiI7 IH07CiAJCUUxRjA0MjQ0MDk4MzkzODkwMDY2OTRFQSAvKiB4bWxodHRwcmVxdWVzdC5jcHAgKi8g PSB7aXNhID0gUEJYRmlsZVJlZmVyZW5jZTsgZmlsZUVuY29kaW5nID0gNDsgbGFzdEtub3duRmls ZVR5cGUgPSBzb3VyY2Vjb2RlLmNwcC5jcHA7IHBhdGggPSB4bWxodHRwcmVxdWVzdC5jcHA7IHNv dXJjZVRyZWUgPSAiPGdyb3VwPiI7IH07CiAJCUUxRjA0MjQ1MDk4MzkzODkwMDY2OTRFQSAvKiB4 bWxodHRwcmVxdWVzdC5oICovID0ge2lzYSA9IFBCWEZpbGVSZWZlcmVuY2U7IGZpbGVFbmNvZGlu ZyA9IDQ7IGxhc3RLbm93bkZpbGVUeXBlID0gc291cmNlY29kZS5jLmg7IHBhdGggPSB4bWxodHRw cmVxdWVzdC5oOyBzb3VyY2VUcmVlID0gIjxncm91cD4iOyB9OwpAQCAtODMzNCw2ICs4MzM4LDgg QEAKIAkJCQlCMjc1MzUzNTBCMDUzODE0MDAyQ0U2NEYgLyogUGF0aENHLmNwcCAqLywKIAkJCQlC Mjc1MzUzNjBCMDUzODE0MDAyQ0U2NEYgLyogUERGRG9jdW1lbnRJbWFnZS5jcHAgKi8sCiAJCQkJ QjI3NTM1MzcwQjA1MzgxNDAwMkNFNjRGIC8qIFBERkRvY3VtZW50SW1hZ2UuaCAqLywKKwkJCQlF MTdFRjE4QTBCMEYyODREMDA4MzZDQTYgLyogUHJpbWl0aXZlVmFsdWUuY3BwICovLAorCQkJCUUx N0VGMTg5MEIwRjI4NEQwMDgzNkNBNiAvKiBQcmltaXRpdmVWYWx1ZS5oICovLAogCQkJKTsKIAkJ CXBhdGggPSBjZzsKIAkJCXNvdXJjZVRyZWUgPSAiPGdyb3VwPiI7CkBAIC0xMDU5MCw2ICsxMDU5 Niw3IEBACiAJCQkJOTNCNkEwRTYwQjBCQ0E1QzAwRjUwMjdBIC8qIENvbnRleHRNZW51LmggaW4g SGVhZGVycyAqLywKIAkJCQkwNjVBRDRGNTBCMEMyRURBMDA1QTJCMUQgLyogQ29udGV4dE1lbnVD bGllbnQuaCBpbiBIZWFkZXJzICovLAogCQkJCTA2NUFENEY3MEIwQzJFREEwMDVBMkIxRCAvKiBD b250ZXh0TWVudUNvbnRyb2xsZXIuaCBpbiBIZWFkZXJzICovLAorCQkJCUUxN0VGMThCMEIwRjI4 NEQwMDgzNkNBNiAvKiBQcmltaXRpdmVWYWx1ZS5oIGluIEhlYWRlcnMgKi8sCiAJCQkpOwogCQkJ cnVuT25seUZvckRlcGxveW1lbnRQb3N0cHJvY2Vzc2luZyA9IDA7CiAJCX07CkBAIC0xMTg1OSw2 ICsxMTg2Niw3IEBACiAJCQkJOTNCNkEwRTgwQjBCQ0E2NzAwRjUwMjdBIC8qIENvbnRleHRNZW51 LmNwcCBpbiBTb3VyY2VzICovLAogCQkJCTkzQjZBMEVBMEIwQkNBODQwMEY1MDI3QSAvKiBDb250 ZXh0TWVudU1hYy5tbSBpbiBTb3VyY2VzICovLAogCQkJCTA2NUFENEY2MEIwQzJFREEwMDVBMkIx RCAvKiBDb250ZXh0TWVudUNvbnRyb2xsZXIuY3BwIGluIFNvdXJjZXMgKi8sCisJCQkJRTE3RUYx OEMwQjBGMjg0RDAwODM2Q0E2IC8qIFByaW1pdGl2ZVZhbHVlLmNwcCBpbiBTb3VyY2VzICovLAog CQkJKTsKIAkJCXJ1bk9ubHlGb3JEZXBsb3ltZW50UG9zdHByb2Nlc3NpbmcgPSAwOwogCQl9OwpJ bmRleDogV2ViQ29yZS9jc3MvQ1NTUHJpbWl0aXZlVmFsdWUuY3BwCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdl YkNvcmUvY3NzL0NTU1ByaW1pdGl2ZVZhbHVlLmNwcAkocmV2aXNpb24gMTc4MjUpCisrKyBXZWJD b3JlL2Nzcy9DU1NQcmltaXRpdmVWYWx1ZS5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTI5LDYgKzI5 LDcgQEAKICNpbmNsdWRlICJFeGNlcHRpb25Db2RlLmgiCiAjaW5jbHVkZSAiUGFpci5oIgogI2lu Y2x1ZGUgIlJlbmRlclN0eWxlLmgiCisjaW5jbHVkZSAiUHJpbWl0aXZlVmFsdWUuaCIKIAogI2lu Y2x1ZGUgPGN0eXBlLmg+CiAKQEAgLTI4Nyw3ICsyODgsMTIgQEAgZG91YmxlIENTU1ByaW1pdGl2 ZVZhbHVlOjpjb21wdXRlTGVuZ3RoRgogICAgIC8vIFdlIGFsd2F5cyBhc3N1bWUgOTYgQ1NTIHBp eGVscyBpbiBhIENTUyBpbmNoLiBUaGlzIGlzIHRoZSBjb2xkIGhhcmQgdHJ1dGggb2YgdGhlIFdl Yi4KICAgICAvLyBBdCBoaWdoIERQSSwgd2UgbWF5IHNjYWxlIGEgQ1NTIHBpeGVsLCBidXQgdGhl IHJhdGlvIG9mIHRoZSBDU1MgcGl4ZWwgdG8gdGhlIHNvLWNhbGxlZAogICAgIC8vICJhYnNvbHV0 ZSIgQ1NTIGxlbmd0aCB1bml0cyBsaWtlIGluY2ggYW5kIHB0IGlzIGFsd2F5cyBmaXhlZCBhbmQg bmV2ZXIgY2hhbmdlcy4KLSAgICBkb3VibGUgY3NzUGl4ZWxzUGVySW5jaCA9IDk2LjsKKyAgICAK KyAgICAvLyBGb3Igc2NyZWVucyB0aGF0IHJlcG9ydCB0aGVpciB0cnVlIGRwaSwgd2Ugbm93IHVz ZSB0aGF0LiBJZiBpdCByZXBvcnRzIDcyLjAgKCd1bmtub3duJyksCisgICAgLy8gd2UgdXNlIDk2 LjAgZm9yIHRoZSByZWFzb25zIGdpdmVuIGFib3ZlLgorICAgIAorICAgIGRvdWJsZSBkaXNwbGF5 UGl4ZWxzUGVySW5jaCA9IENHTWFpbkRpc3BsYXlEUEkoKTsKKyAgICBkb3VibGUgY3NzUGl4ZWxz UGVySW5jaCA9IChkaXNwbGF5UGl4ZWxzUGVySW5jaCA9PSA3Mi4wKT8gOTYuMCA6IGRpc3BsYXlQ aXhlbHNQZXJJbmNoOwogCiAgICAgZG91YmxlIGZhY3RvciA9IDEuOwogICAgIHN3aXRjaCh0eXBl KSB7CkluZGV4OiBXZWJDb3JlL3BsYXRmb3JtL2dyYXBoaWNzL2NnL1ByaW1pdGl2ZVZhbHVlLmNw cAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBXZWJDb3JlL3BsYXRmb3JtL2dyYXBoaWNzL2NnL1ByaW1pdGl2ZVZh bHVlLmNwcAkocmV2aXNpb24gMCkKKysrIFdlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3MvY2cvUHJp bWl0aXZlVmFsdWUuY3BwCShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDQ4IEBACisvKgorICogQ29w eXJpZ2h0IDIwMDYgTmljaG9sYXMgU2hhbmtzLiBBbGwgcmlnaHRzIHJlc2VydmVkLgorICoKKyAq IFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGgg b3Igd2l0aG91dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQg dGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisgKiBhcmUgbWV0OgorICoKKyAqIDEuICBSZWRpc3Ry aWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAor ICogICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcg ZGlzY2xhaW1lci4gCisgKiAyLiAgUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3Qg cmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgICBub3RpY2UsIHRoaXMgbGlzdCBv ZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlCisgKiAgICAg ZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRp c3RyaWJ1dGlvbi4gCisgKiAzLiAgTmVpdGhlciB0aGUgbmFtZSBvZiBBcHBsZSBDb21wdXRlciwg SW5jLiAoIkFwcGxlIikgbm9yIHRoZSBuYW1lcyBvZgorICogICAgIGl0cyBjb250cmlidXRvcnMg bWF5IGJlIHVzZWQgdG8gZW5kb3JzZSBvciBwcm9tb3RlIHByb2R1Y3RzIGRlcml2ZWQKKyAqICAg ICBmcm9tIHRoaXMgc29mdHdhcmUgd2l0aG91dCBzcGVjaWZpYyBwcmlvciB3cml0dGVuIHBlcm1p c3Npb24uIAorICoKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgQVBQTEUgQU5EIElU UyBDT05UUklCVVRPUlMgIkFTIElTIiBBTkQgQU5ZCisgKiBFWFBSRVNTIE9SIElNUExJRUQgV0FS UkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRSBJTVBMSUVECisgKiBX QVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFS IFBVUlBPU0UgQVJFCisgKiBESVNDTEFJTUVELiBJTiBOTyBFVkVOVCBTSEFMTCBBUFBMRSBPUiBJ VFMgQ09OVFJJQlVUT1JTIEJFIExJQUJMRSBGT1IgQU5ZCisgKiBESVJFQ1QsIElORElSRUNULCBJ TkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwgREFNQUdFUwor ICogKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElU VVRFIEdPT0RTIE9SIFNFUlZJQ0VTOworICogTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7 IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikgSE9XRVZFUiBDQVVTRUQgQU5ECisgKiBPTiBBTlkg VEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUIExJQUJJTElU WSwgT1IgVE9SVAorICogKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lO RyBJTiBBTlkgV0FZIE9VVCBPRiBUSEUgVVNFIE9GCisgKiBUSElTIFNPRlRXQVJFLCBFVkVOIElG IEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLgorICovCisKKyNpbmNs dWRlICJQcmltaXRpdmVWYWx1ZS5oIgorCisjaWYgUExBVEZPUk0oQ0cpCisKKyNpbmNsdWRlIDxB cHBsaWNhdGlvblNlcnZpY2VzL0FwcGxpY2F0aW9uU2VydmljZXMuaD4KKworZG91YmxlIENHTWFp bkRpc3BsYXlEUEkodm9pZCkKK3sKKyAgICBzdGF0aWMgZG91YmxlIG1haW5EaXNwbGF5RFBJID0g MC4wOworICAgIGlmKG1haW5EaXNwbGF5RFBJID09IDAuMCkKKyAgICB7CisgICAgICAgIENHRGly ZWN0RGlzcGxheUlEIGRpc3BsYXkgPSBDR01haW5EaXNwbGF5SUQoKTsKKyAgICAgICAgQ0dTaXpl IHNpemUgPSBDR0Rpc3BsYXlTY3JlZW5TaXplKGRpc3BsYXkpOworICAgICAgICBzaXplX3Qgd2lk dGggPSBDR0Rpc3BsYXlQaXhlbHNXaWRlKGRpc3BsYXkpOworICAgICAgICBtYWluRGlzcGxheURQ SSA9IDI1LjQqd2lkdGgvc2l6ZS53aWR0aDsKKyAgICB9CisgICAgcmV0dXJuIG1haW5EaXNwbGF5 RFBJOworfQorCisjZW5kaWYgLy8gUExBVEZPUk0oQ0cpCkluZGV4OiBXZWJDb3JlL3BsYXRmb3Jt L2dyYXBoaWNzL2NnL1ByaW1pdGl2ZVZhbHVlLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gV2ViQ29yZS9wbGF0 Zm9ybS9ncmFwaGljcy9jZy9QcmltaXRpdmVWYWx1ZS5oCShyZXZpc2lvbiAwKQorKysgV2ViQ29y ZS9wbGF0Zm9ybS9ncmFwaGljcy9jZy9QcmltaXRpdmVWYWx1ZS5oCShyZXZpc2lvbiAwKQpAQCAt MCwwICsxLDQ1IEBACisvKgorICogQ29weXJpZ2h0IDIwMDYgTmljaG9sYXMgU2hhbmtzLiBBbGwg cmlnaHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNl IGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorICogbW9kaWZpY2F0aW9uLCBhcmUg cGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisgKiBhcmUg bWV0OgorICoKKyAqIDEuICBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRh aW4gdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRp dGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4gCisgKiAyLiAgUmVkaXN0cmlidXRp b25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAq ICAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRp c2NsYWltZXIgaW4gdGhlCisgKiAgICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJp YWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4gCisgKiAzLiAgTmVpdGhlciB0aGUg bmFtZSBvZiBBcHBsZSBDb21wdXRlciwgSW5jLiAoIkFwcGxlIikgbm9yIHRoZSBuYW1lcyBvZgor ICogICAgIGl0cyBjb250cmlidXRvcnMgbWF5IGJlIHVzZWQgdG8gZW5kb3JzZSBvciBwcm9tb3Rl IHByb2R1Y3RzIGRlcml2ZWQKKyAqICAgICBmcm9tIHRoaXMgc29mdHdhcmUgd2l0aG91dCBzcGVj aWZpYyBwcmlvciB3cml0dGVuIHBlcm1pc3Npb24uIAorICoKKyAqIFRISVMgU09GVFdBUkUgSVMg UFJPVklERUQgQlkgQVBQTEUgQU5EIElUUyBDT05UUklCVVRPUlMgIkFTIElTIiBBTkQgQU5ZCisg KiBFWFBSRVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlU RUQgVE8sIFRIRSBJTVBMSUVECisgKiBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQg RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQVJFCisgKiBESVNDTEFJTUVELiBJTiBO TyBFVkVOVCBTSEFMTCBBUFBMRSBPUiBJVFMgQ09OVFJJQlVUT1JTIEJFIExJQUJMRSBGT1IgQU5Z CisgKiBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9S IENPTlNFUVVFTlRJQUwgREFNQUdFUworICogKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRP LCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTIE9SIFNFUlZJQ0VTOworICogTE9TUyBP RiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikgSE9XRVZF UiBDQVVTRUQgQU5ECisgKiBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBD T05UUkFDVCwgU1RSSUNUIExJQUJJTElUWSwgT1IgVE9SVAorICogKElOQ0xVRElORyBORUdMSUdF TkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZIE9VVCBPRiBUSEUgVVNFIE9GCisg KiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNV Q0ggREFNQUdFLgorICovCisKKyNpbmNsdWRlICJjb25maWcuaCIKKworI2lmIFBMQVRGT1JNKENH KQorCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIgeworI2VuZGlmCisKK2RvdWJsZSBD R01haW5EaXNwbGF5RFBJKHZvaWQpOworCisjaWZkZWYgX19jcGx1c3BsdXMKK30KKyNlbmRpZgor CisjZWxzZQorI2RlZmluZSBDR01haW5EaXNwbGF5RFBJKCkgKDcyLjApCisjZW5kaWYK 11565 2006-11-18 06:03:49 -0800 2006-11-18 06:03:49 -0800 visual test page (requires human with ruler) abslen.html text/html 425 nickshanks PHRpdGxlPkNTUyBBYnNvbHV0ZSBMZW5ndGhzIERlbW9uc3RyYXRpb248L3RpdGxlPgo8c3R5bGUg dHlwZT0idGV4dC9jc3MiPmRpdntoZWlnaHQ6MWVtO2JhY2tncm91bmQ6cmVkfTwvc3R5bGU+Cjxw PjI1NCBtaWxsaW1ldHJlczo8L3A+CjxkaXYgc3R5bGU9IndpZHRoOjI1NG1tIj48L2Rpdj4KPHA+ MjUuNCBjZW50aW1ldHJlczo8L3A+CjxkaXYgc3R5bGU9IndpZHRoOjI1LjRjbSI+PC9kaXY+Cjxw PjEwIGluY2hlczo8L3A+CjxkaXYgc3R5bGU9IndpZHRoOjEwaW4iPjwvZGl2Pgo8cD42MCBwaWNh ZTo8L3A+CjxkaXYgc3R5bGU9IndpZHRoOjYwcGMiPjwvZGl2Pgo8cD43MjAgcG9pbnRzOjwvcD4K PGRpdiBzdHlsZT0id2lkdGg6NzIwcHQiPjwvZGl2Pgo8cD45NjAgcGl4ZWxzOjwvcD4KPGRpdiBz dHlsZT0id2lkdGg6OTYwcHgiPjwvZGl2Pgo=