More features of Apple's Leopard leaked on Web - Page 2

This is one reason why I decided to wait, rather than rushing out and buying a Quad.

Apple is aware of this, but they had bigger fish to fry, hopefully, now they will have done something about it, as so many have complained.

It also makes their equipment look underpowered (again!).

Yes. This has been discussed before. Apple can do this on their own. If even the only thing that used it at first was the finder, there would be a big enough group of happy people (such as myself) that Apple, and others, would see the competitive advantage to it. But it could take a year when apps got upgraded before we would see a significent number of them using it. Small apps would go first.

Well then, what they are saying is simply incorrect. This should be obvjous too. My Sony 24" monitor is normally run at 1920 x 1200. If I halve the rez to 960 x 600, are you going to tell me that the pixels are the same size? And if someone else has a 19" that they run at 1920 x 1200, are you going to say that those pixels are the same as well?

Unless they are talking about some fixed size screen.

Otherwise the fonts clearly won't be the same size. What they will have is the same APPEARENCE. The same number of pixels will keep the font detail the same, even though the fonts themselves will vary in size.

I don't know what they are thinking, because without reading the rest of the article, something else they said might clear that up. But, as it stands, it's wrong.

You have it exactly backwards.

You just changed what you said before.

That's a poor way to do a web page. The font size should be able to change for different monitor sizes. The designer can always lock the images to the text to keep it where it should be. But on larger screens, the type simply gets too small to read comfortably. That's why browsers, such as Safari allow the user to spec the size fonts will appear.

Anything else is very poor design. The elements should be allowed to move as type size varies. too many pages don't do that. You change the font size, and the type overlays itself onto other screen elements. Very bad.

Whoever wrote that article is thinking like a paper designer. Magazine pages are fixed. The designer knows exactly what is available to them. Not true on the computer. Designers MUST learn that their precious designs have to exist within that space.

Too many don't. Hence that article.

You just crapped on your own argument.

For the web FreeState is right that a pixel is resolution independent. You can read from Dave Hyatt where he explains that css pixels do not equal device pixels. Kind of confusing but that's the W3C for you.

http://webkit.opendarwin.org/blog/

(read the part about CSS units part way down)

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.

But, a CSS pixel is not what had been discussed here before. He is correct when he says that web designers don't understand the difference between a CSS pixel and a "real" device pixel. But the idea of calling the CSS point of measure a pixel, was bound to cause confusion.

Both em and ex are differently related, because em is not a point value at all. It is a relative measurement, which traditionally is equal to the width of the capital "M".

Hmm not that big of a leak. Hope there is still more to be seen.

I would suspect that Hyatt knows a little bit more about units and CSS than most people, and it is you who is misunderstanding what he means.

It is correct that he starts by saying that no units are absolute, but the part where he calls pt absolute is just because that's what they are called - absolute or not.

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.

I was going to reply to FreeState but Melgross pretty much nailed it; you shouldn't use pixels for fonts because of accesibility issues and pt and cm are absolute. What isn't? Ems and percentages. Also description words. Telling a font to be "large" or "x-large" isn't absolute because its up to the browser and host OS to determine what those words mean. If you said 2.54cm or something, THAT is absolute.

It goes back to two design philosphies really; and its based on either giving visitors options and allowing them to choose within limits (using relative font sizing, for example) or that as designer you know best (pixels for all). The former worries more of accessiblity, of readability across not only screens but media.

You can make pixel perfect blah, but I'm gonna have a min. font size that will blow it apart. And don't think you can get away from it by making tiny fonts into graphics!

Regardless of what Mr. Hyatt is saying or even thinking, its wrong. What he may be describing might not be, but how he goes about describing it is. Measured units (think a ruler) ARE absolute. He just can't call them otherwise.

Here, I'm a respected and popular member of my field OK? See that glass of water in your hands, its not a liquid, its a solid. You can drink it you say? It must be a liquid? No, no, its a solid. I said so. A standards bodies backs me up. Solid. Drink your solid water.

Same deal. Right Melgross?

Oh and resolution indepenance would be great because I like thinks larger then normal on the screen. And all those other features are snazzy too. Hehe.

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.

WRONG ANSWER!

Pixels have WIDTH and HEIGHT, once the OS has this information, GAME OVER!

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.

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.

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!

Um, duh? And?

WRONG ANSWER!

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.

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)

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.

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.

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!

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.


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.

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.

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.

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.

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!

I just read that as "gay parade". Twice.

Have a nice day!

Haha, I did too

That's right. It's why one can't do that for electronic publications.

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.

That's true as well. But sub-pixels are a specialized way of using PORTIONS of a pixel. They are not true pixels thenselves.

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.

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.