You'rer still mapping AND scaling whatever it is your doing to a 2D PHYSICAL SPACE. IT HAS WIDTH, IT HAS HEIGHT!
Like I said, GAME OVER!
You say game over, then what is the winning position? What is with the caps? Are you having anger problems or is it a keyboard defect?
Basically I want a standard such that objects can be projected to the same physical size across different display types regardless of the device resolution, and that the images have enough detail to handle higher density displays without looking exploded, and that is a pretty key bit of importance to making sure the images still look good. Text can be scaled without issue, but if everything around the text wasn't designed properly, things not only look bad, sometimes it doesn't work.
If carbon and cocoa APIs were available on Windows, do you really think a major application developer like Adobe would develop solely with Carbon/Cocoa or continue using the Windows API's their using now?
Nobody already invested heavily in code is going to dump that investment. Especially since I don't think they would (or could) trust Apple for the Windows development.
That doesn't mean that development of a common codebase for Apple & Windows wouldn't be useful for many developers. However, I doubt it'd come down to "Cocoa for Windows" anymore - if Apple decided to do that, it'd be marketed as "Xcode compiler for Windows" (or something similar)
You would would be wrong in that. My publishing industry experience goes back to the early '70's. Absolute measurement standards are just that. They have been defined by internationally recognized groups. Neither he, nor you, can change that. If some want to bastardize standards, that is never a good thing.
Adding additional standards for newer methods of publication is a different situtation. But taking recognized terms, and attempting to fit them into a different standard, with a different definition, is bad.
Absolute units are physical standards. The cm is one of the most well known of those. It isn't a relative measurement, and it doesn't change its value. Pt is defined in terms of the inch, and also by the cm. Digital pts are 72 per inch, and physical pts are slightly smaller.
CSS standards are very different. When you understand it, come back to me.
Perhaps you misunderstood me. He called them absolute because that's what they are called by web developers, but his point is that they are not absolute with regards to CSS and webdesign.
All I was trying to say that he didn't call pt absolute, and he is talking about CSS units.
PS: I know what points, em, en and so on are. My previous career was in publishing.
To specify 2.54cm is absolute, but the end result isn't. 2.54cms have no meaning whatsoever on a screen, so you know nothing (nor should you) about how big or small the result will appear.
Not so fast...
on the original Mac display, 72 pixels equaled 1". Therefore, any cm or inch measurement acutally had a meaning. This got lost, however when multiscan displays emerged with a pixel density ranging from 72 to 120 dpi.
Now resolution independance enables us to bring back this 1:1 mapping (or continue to violate it) if we so desire. Since the content now can be scaled, it is possible to adjust for the different display resolutions. This of course requires to map the pixel of the old coordinate systems (QuickDraw, web) to more than one display pixel.
Newer coordinate systems (CoreFoundation) use floating-point coordinates and don't make any assumptions on how large they are rendered on-screen.
As noted on http://www.apple.com/macosx/leopard/xcode.html, Leopard will include DTrace, Sun's powerful and flexible facility for script-driven kernel and process tracing. This will be a BIG win for debugging and optimizing complex applications.
In addition, Apple is adding a GUI-based front end, which should make DTrace faster, more compelling (e.g., by generating graphs), and more convenient to use. This will also make it more approachable for programmers who aren't scripting aficionados.
You say game over, then what is the winning position? What is with the caps? Are you having anger problems or is it a keyboard defect?
Basically I want a standard such that objects can be projected to the same physical size across different display types regardless of the device resolution, and that the images have enough detail to handle higher density displays without looking exploded, and that is a pretty key bit of importance to making sure the images still look good. Text can be scaled without issue, but if everything around the text wasn't designed properly, things not only look bad, sometimes it doesn't work.
It's called being RUDE, ok?
My only point is the same one I think you're trying to make, I believe. A consistent methodology to display/print information across all manner of hardware devices (at the OS level), be it a 72PPI display or 4,800DPI printer, and you DON'T do that without knowledge of the HW's physical resolution. To do things without some sort of standard scale to define things does not make sense. Please, oh please "Super Size" my fonts?
I guess I'm just use to standard's organizations such as; ISO, ASTM, NIST, IEEE, ANSI, BIPM, etcetera. Which sometimes I think you SW guys find abhorent, because this doesn't allow you to "innovate."
So comments that trivialize physical measurements as being irrelevant strongly suggest that we all need to get babelfish to do the heavy lifting, something I find abhorent!
Except that he, too, gets things confused. pt and cm ARE absolute values.
He confuses that issues a couple of times. Once he says that pt is not absolute, the next time, he says that it is.
Right, the lead browswer engineer that works on this stuff daily has less understanding of browser measurements and how they work than a guy who once worked in publishing.
Quote:
Originally Posted by melgross
You would would be wrong in that. My publishing industry experience goes back to the early '70's. Absolute measurement standards are just that. They have been defined by internationally recognized groups. Neither he, nor you, can change that. If some want to bastardize standards, that is never a good thing.
Adding additional standards for newer methods of publication is a different situtation. But taking recognized terms, and attempting to fit them into a different standard, with a different definition, is bad.
Absolute units are physical standards. The cm is one of the most well known of those. It isn't a relative measurement, and it doesn't change its value. Pt is defined in terms of the inch, and also by the cm. Digital pts are 72 per inch, and physical pts are slightly smaller.
CSS standards are very different. When you understand it, come back to me.
Absolute measurements work great when the dpi stays the same. Unfortunately they don't, and Hyatt address this by stating they assume 96 dpi when making browsers. Assuming 96 dpi when it is actually 72 or 120 throws you nice cm is a cm right out the window.
Now with Resolution Independence and your dpi value, you sure could make a cm a cm. The problem is how does your system figure out the dpi of your screen? Currently all your system knows is the number of pixels in your display. It may change in the future that your system can query your display for its dpi, but as a browser maker working with current hardware, Hyatt knows that he cannot ensure a cm actually displays as a cm.
out of interest, how much of a difference is resolution independance really?
The real beauty of resolution independence will be apparent when we have large displays with 200+ ppi pixel densities. Just think of all of the pixels of the 30" Cinema Display crammed down onto a 15" display. Or a 23" display with 3840x2400 resolution.
Right now, if you had such a display, you could do one of two things with it at any given time: (1) Enjoy its full resolution while using a magnifying glass to view most of what you'd see on the display, or (2) magnify everything through software, just like what happens when you use an LCD at less than it's native resolution, so you can see everything more comfortably, but without any benefit from the display's high native resolution.
With resolution independence properly implemented on a high-res display, you could choose your own most comfortable trade off between screen real estate and readability. When you weren't going for maximum real estate, you'd be able to see very crisp text that would look much closer to printed text than typical "screen fonts", see details like "hairline" borders and dividers which would better convey the appearance of printed results, see a lot more photographic detail without having to view only small, magnified portions of an image -- imagine the full glory of all of the pixels in a five-megapixel photograph all in view at the same time, while dialogs and menus and cursors are at perfectly usable sizes at the same time.
Basically I want a standard such that objects can be projected to the same physical size across different display types regardless of the device resolution, and that the images have enough detail to handle higher density displays without looking exploded, and that is a pretty key bit of importance to making sure the images still look good.
Only thing I can think of is SVG, at least when it comes to scaling. But its "cheating" because its vector. But it will never happen, look how well PNG took off as an alternative. Haha.
Perhaps you misunderstood me. He called them absolute because that's what they are called by web developers, but his point is that they are not absolute with regards to CSS and webdesign.
So he gets every designer to believe those units are relative (if they are not absolute), ok. All units are relative on the screen. But as luck would have it, they figure out that problem down the road, they are now able to make measurements like cm and px be exact across browsers. So after they fix the bugs they become truly absolute, but now everyone uses them because they are relative (according to what he said back then).
They are absolute, just because technology is too pathetic, or infantile to get that right doesn't change it. But you telling everyone that they are relative, and technology fixes that problem (and thus blows away the whole argument) will leave people more confused then they already are. If it quacks and all that, its a duck. or a platapus, do they quack?
But really, this thread has degraded nicely. How does this affect anyone but us Web designers and developers? haha.
So, a user with a 200 DPI screen of the future will need phenomenal eyesight to read a 12 pixel font?it will only be 1.5mm. They'll have no problem reading the 12 point font type which'll be 4.23mm.
Where is the evidence that pixel pitch is going to get much denser in the future?
This came out in 2001 as the IBM T220, later as the T221, IBM discontinued it in 2005, but it is still sold as a rebranded 22" TFT LCD monitor (3,840H by 2,400V, or 9.2Mpixels, WQUXGA). That's 204PPI.
But at a $6K street price, it's just a little bit above my pay grade!
BTW, Dell had 147PPI lappies back in 2003, I believe.
PS - I do think resolutiion independence (at the OS level) is a good thing, it gives me control over what I see, irrespective of people who don't care about physical measurements! And it's just not that difficult to implement for the end user, either have a database of display devices, or GET A RULER, and spend like 30 seconds, to measure and input the measurements for the OS to use. But perhaps that is to difficult for you guys, seeing as it's a REAL measurement, and not a VIRTUAL measurement!
To specify 2.54cm is absolute, but the end result isn't. 2.54cms have no meaning whatsoever on a screen, so you know nothing (nor should you) about how big or small the result will appear.
That's right. It's why one can't do that for electronic publications.
You should get off your cancer-induction, then get back to this discussion. I didn't even mention pixels in my post; I mentioned centimeters, but even if I had, we've already established in this thread that, for better or worse, CSS pixels do not correspond to device pixels. This is especially the case on advanced graphics engines like Quartz, where device subpixels are heavily used, enabling strokes to be thinner than a regular device pixel.
That's true as well. But sub-pixels are a specialized way of using PORTIONS of a pixel. They are not true pixels thenselves.
Since the OS knows the device dpi, rendering exactly 2.54cm is within it's capability. Whether that's what actually happens, I've no idea as I've not used absolute positioning web design like that in years.
Freestate, please read some decent articles about web design, not the shit on about.com. http://alistapart.com/articles/elastic/ has a good summation of the problem of resolution independence as far as the web goes and suggests a solution. You should free yourself from using the pixel as a design crutch.
The problem is that the OS never (almost never?) knows the size of the monitor. It just goes by the number of pixels. It doesn't know the dpi (properly stated as the ppi) of the monitor. It makes certain assumptions, which are usually wrong.
That's why when you tell the program to show something at 100% size, it doesn't.
Perhaps you misunderstood me. He called them absolute because that's what they are called by web developers, but his point is that they are not absolute with regards to CSS and webdesign.
All I was trying to say that he didn't call pt absolute, and he is talking about CSS units.
PS: I know what points, em, en and so on are. My previous career was in publishing.
Then he should the correct situation. He did call pt absolute at on point (duh!) in his post.
My point is that we should NEVER have mixed standards. A frog is a frog it isn't a dog.
If some use definitions incorrectly, then we should enlighten them, not try to explain it away.
Web publishing is very difficult. I have never used those terms incorrectly. Perhaps that is because I was doing this far earlier than they have.
It's fine to use a particular font size in a web based document, and understand that relative to the other font sizes, it will be fixed. But, there is no way, at this time, to ascertain what size it will be on anyone's screen. The concept of the CSS "pixel" is that as you magnify, more info comes out. This simply means that it is not a pixel at all. It is a placeholder.
A pixel should never be defined as anything other than the smallest full color element of a screen. It is always independent of whatever image is on the screen, but the observable detail in the image is always dependent on the number of pixels representing it at any given time.
If the screens rez that is being used is one half of the maximum, then each effective pixel consists of four physical pixels. No matter what is done, that will be the smallest element of the image at that rez.
Comments
Doesn't matter!
You'rer still mapping AND scaling whatever it is your doing to a 2D PHYSICAL SPACE. IT HAS WIDTH, IT HAS HEIGHT!
Like I said, GAME OVER!
You say game over, then what is the winning position? What is with the caps? Are you having anger problems or is it a keyboard defect?
Basically I want a standard such that objects can be projected to the same physical size across different display types regardless of the device resolution, and that the images have enough detail to handle higher density displays without looking exploded, and that is a pretty key bit of importance to making sure the images still look good. Text can be scaled without issue, but if everything around the text wasn't designed properly, things not only look bad, sometimes it doesn't work.
If carbon and cocoa APIs were available on Windows, do you really think a major application developer like Adobe would develop solely with Carbon/Cocoa or continue using the Windows API's their using now?
Nobody already invested heavily in code is going to dump that investment. Especially since I don't think they would (or could) trust Apple for the Windows development.
That doesn't mean that development of a common codebase for Apple & Windows wouldn't be useful for many developers. However, I doubt it'd come down to "Cocoa for Windows" anymore - if Apple decided to do that, it'd be marketed as "Xcode compiler for Windows" (or something similar)
You would would be wrong in that. My publishing industry experience goes back to the early '70's. Absolute measurement standards are just that. They have been defined by internationally recognized groups. Neither he, nor you, can change that. If some want to bastardize standards, that is never a good thing.
Adding additional standards for newer methods of publication is a different situtation. But taking recognized terms, and attempting to fit them into a different standard, with a different definition, is bad.
Absolute units are physical standards. The cm is one of the most well known of those. It isn't a relative measurement, and it doesn't change its value. Pt is defined in terms of the inch, and also by the cm. Digital pts are 72 per inch, and physical pts are slightly smaller.
CSS standards are very different. When you understand it, come back to me.
Perhaps you misunderstood me. He called them absolute because that's what they are called by web developers, but his point is that they are not absolute with regards to CSS and webdesign.
All I was trying to say that he didn't call pt absolute, and he is talking about CSS units.
PS: I know what points, em, en and so on are. My previous career was in publishing.
To specify 2.54cm is absolute, but the end result isn't. 2.54cms have no meaning whatsoever on a screen, so you know nothing (nor should you) about how big or small the result will appear.
Not so fast...
on the original Mac display, 72 pixels equaled 1". Therefore, any cm or inch measurement acutally had a meaning. This got lost, however when multiscan displays emerged with a pixel density ranging from 72 to 120 dpi.
Now resolution independance enables us to bring back this 1:1 mapping (or continue to violate it) if we so desire. Since the content now can be scaled, it is possible to adjust for the different display resolutions. This of course requires to map the pixel of the old coordinate systems (QuickDraw, web) to more than one display pixel.
Newer coordinate systems (CoreFoundation) use floating-point coordinates and don't make any assumptions on how large they are rendered on-screen.
In addition, Apple is adding a GUI-based front end, which should make DTrace faster, more compelling (e.g., by generating graphs), and more convenient to use. This will also make it more approachable for programmers who aren't scripting aficionados.
You say game over, then what is the winning position? What is with the caps? Are you having anger problems or is it a keyboard defect?
Basically I want a standard such that objects can be projected to the same physical size across different display types regardless of the device resolution, and that the images have enough detail to handle higher density displays without looking exploded, and that is a pretty key bit of importance to making sure the images still look good. Text can be scaled without issue, but if everything around the text wasn't designed properly, things not only look bad, sometimes it doesn't work.
It's called being RUDE, ok?
My only point is the same one I think you're trying to make, I believe. A consistent methodology to display/print information across all manner of hardware devices (at the OS level), be it a 72PPI display or 4,800DPI printer, and you DON'T do that without knowledge of the HW's physical resolution. To do things without some sort of standard scale to define things does not make sense. Please, oh please "Super Size" my fonts?
I guess I'm just use to standard's organizations such as; ISO, ASTM, NIST, IEEE, ANSI, BIPM, etcetera. Which sometimes I think you SW guys find abhorent, because this doesn't allow you to "innovate."
So comments that trivialize physical measurements as being irrelevant strongly suggest that we all need to get babelfish to do the heavy lifting, something I find abhorent!
Except that he, too, gets things confused. pt and cm ARE absolute values.
He confuses that issues a couple of times. Once he says that pt is not absolute, the next time, he says that it is.
Right, the lead browswer engineer that works on this stuff daily has less understanding of browser measurements and how they work than a guy who once worked in publishing.
You would would be wrong in that. My publishing industry experience goes back to the early '70's. Absolute measurement standards are just that. They have been defined by internationally recognized groups. Neither he, nor you, can change that. If some want to bastardize standards, that is never a good thing.
Adding additional standards for newer methods of publication is a different situtation. But taking recognized terms, and attempting to fit them into a different standard, with a different definition, is bad.
Absolute units are physical standards. The cm is one of the most well known of those. It isn't a relative measurement, and it doesn't change its value. Pt is defined in terms of the inch, and also by the cm. Digital pts are 72 per inch, and physical pts are slightly smaller.
CSS standards are very different. When you understand it, come back to me.
Absolute measurements work great when the dpi stays the same. Unfortunately they don't, and Hyatt address this by stating they assume 96 dpi when making browsers. Assuming 96 dpi when it is actually 72 or 120 throws you nice cm is a cm right out the window.
Now with Resolution Independence and your dpi value, you sure could make a cm a cm. The problem is how does your system figure out the dpi of your screen? Currently all your system knows is the number of pixels in your display. It may change in the future that your system can query your display for its dpi, but as a browser maker working with current hardware, Hyatt knows that he cannot ensure a cm actually displays as a cm.
out of interest, how much of a difference is resolution independance really?
The real beauty of resolution independence will be apparent when we have large displays with 200+ ppi pixel densities. Just think of all of the pixels of the 30" Cinema Display crammed down onto a 15" display. Or a 23" display with 3840x2400 resolution.
Right now, if you had such a display, you could do one of two things with it at any given time: (1) Enjoy its full resolution while using a magnifying glass to view most of what you'd see on the display, or (2) magnify everything through software, just like what happens when you use an LCD at less than it's native resolution, so you can see everything more comfortably, but without any benefit from the display's high native resolution.
With resolution independence properly implemented on a high-res display, you could choose your own most comfortable trade off between screen real estate and readability. When you weren't going for maximum real estate, you'd be able to see very crisp text that would look much closer to printed text than typical "screen fonts", see details like "hairline" borders and dividers which would better convey the appearance of printed results, see a lot more photographic detail without having to view only small, magnified portions of an image -- imagine the full glory of all of the pixels in a five-megapixel photograph all in view at the same time, while dialogs and menus and cursors are at perfectly usable sizes at the same time.
Basically I want a standard such that objects can be projected to the same physical size across different display types regardless of the device resolution, and that the images have enough detail to handle higher density displays without looking exploded, and that is a pretty key bit of importance to making sure the images still look good.
Only thing I can think of is SVG, at least when it comes to scaling. But its "cheating" because its vector. But it will never happen, look how well PNG took off as an alternative. Haha.
Perhaps you misunderstood me. He called them absolute because that's what they are called by web developers, but his point is that they are not absolute with regards to CSS and webdesign.
So he gets every designer to believe those units are relative (if they are not absolute), ok. All units are relative on the screen. But as luck would have it, they figure out that problem down the road, they are now able to make measurements like cm and px be exact across browsers. So after they fix the bugs they become truly absolute, but now everyone uses them because they are relative (according to what he said back then).
They are absolute, just because technology is too pathetic, or infantile to get that right doesn't change it. But you telling everyone that they are relative, and technology fixes that problem (and thus blows away the whole argument) will leave people more confused then they already are. If it quacks and all that, its a duck. or a platapus, do they quack?
But really, this thread has degraded nicely. How does this affect anyone but us Web designers and developers? haha.
So, a user with a 200 DPI screen of the future will need phenomenal eyesight to read a 12 pixel font?it will only be 1.5mm. They'll have no problem reading the 12 point font type which'll be 4.23mm.
Where is the evidence that pixel pitch is going to get much denser in the future?
Where is the evidence that pixel pitch is going to get much denser in the future?
Don't know about the future, but;
Hugegantnormous
This came out in 2001 as the IBM T220, later as the T221, IBM discontinued it in 2005, but it is still sold as a rebranded 22" TFT LCD monitor (3,840H by 2,400V, or 9.2Mpixels, WQUXGA). That's 204PPI.
But at a $6K street price, it's just a little bit above my pay grade!
BTW, Dell had 147PPI lappies back in 2003, I believe.
PS - I do think resolutiion independence (at the OS level) is a good thing, it gives me control over what I see, irrespective of people who don't care about physical measurements! And it's just not that difficult to implement for the end user, either have a database of display devices, or GET A RULER, and spend like 30 seconds, to measure and input the measurements for the OS to use. But perhaps that is to difficult for you guys, seeing as it's a REAL measurement, and not a VIRTUAL measurement!
But at a $6K street price, it's just a little bit above my pay grade!
I just read that as "gay parade". Twice.
I just read that as "gay parade". Twice.
Have a nice day!
I just read that as "gay parade". Twice.
Haha, I did too
To specify 2.54cm is absolute, but the end result isn't. 2.54cms have no meaning whatsoever on a screen, so you know nothing (nor should you) about how big or small the result will appear.
That's right. It's why one can't do that for electronic publications.
WRONG ANSWER!
Pixels have WIDTH and HEIGHT, once the OS has this information, GAME OVER!
No! Not at all.
Each monitor, at any given rez, has pixels of a given size. But change the monitor, or the rez, and the pixel size changes.
Why are we discussing this at all?
There is not one person on this board who does not understand this.
You understand it as well, intuitively, but you don't seem to realize it.
You should get off your cancer-induction, then get back to this discussion. I didn't even mention pixels in my post; I mentioned centimeters, but even if I had, we've already established in this thread that, for better or worse, CSS pixels do not correspond to device pixels. This is especially the case on advanced graphics engines like Quartz, where device subpixels are heavily used, enabling strokes to be thinner than a regular device pixel.
That's true as well. But sub-pixels are a specialized way of using PORTIONS of a pixel. They are not true pixels thenselves.
Sure about that?
Since the OS knows the device dpi, rendering exactly 2.54cm is within it's capability. Whether that's what actually happens, I've no idea as I've not used absolute positioning web design like that in years.
Freestate, please read some decent articles about web design, not the shit on about.com. http://alistapart.com/articles/elastic/ has a good summation of the problem of resolution independence as far as the web goes and suggests a solution. You should free yourself from using the pixel as a design crutch.
The problem is that the OS never (almost never?) knows the size of the monitor. It just goes by the number of pixels. It doesn't know the dpi (properly stated as the ppi) of the monitor. It makes certain assumptions, which are usually wrong.
That's why when you tell the program to show something at 100% size, it doesn't.
Perhaps you misunderstood me. He called them absolute because that's what they are called by web developers, but his point is that they are not absolute with regards to CSS and webdesign.
All I was trying to say that he didn't call pt absolute, and he is talking about CSS units.
PS: I know what points, em, en and so on are. My previous career was in publishing.
Then he should the correct situation. He did call pt absolute at on point (duh!) in his post.
My point is that we should NEVER have mixed standards. A frog is a frog it isn't a dog.
If some use definitions incorrectly, then we should enlighten them, not try to explain it away.
Web publishing is very difficult. I have never used those terms incorrectly. Perhaps that is because I was doing this far earlier than they have.
It's fine to use a particular font size in a web based document, and understand that relative to the other font sizes, it will be fixed. But, there is no way, at this time, to ascertain what size it will be on anyone's screen. The concept of the CSS "pixel" is that as you magnify, more info comes out. This simply means that it is not a pixel at all. It is a placeholder.
A pixel should never be defined as anything other than the smallest full color element of a screen. It is always independent of whatever image is on the screen, but the observable detail in the image is always dependent on the number of pixels representing it at any given time.
If the screens rez that is being used is one half of the maximum, then each effective pixel consists of four physical pixels. No matter what is done, that will be the smallest element of the image at that rez.