or Connect
AppleInsider › Forums › Software › Mac OS X › More features of Apple's Leopard leaked on Web
New Posts  All Forums:Forum Nav:

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

post #81 of 142
Quote:
Originally Posted by Mr Beardsley

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.

That's a wiseguy remark, and shows that you know nothing. I worked in publishing for far more years than he has been doing his work. I owned a commercial photo lab for 28 years that did a great deal of publishing work for majot publications, as well as broadcast stations. We also did more than a bit of web design. I've worked with Adobe since 1992 as well.

Perhaps you should learn more about people.

Quote:
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.

The problem with this is that there has rarely been a monitor that has actually BEEN 96 dpi. even when there has been, people haven't always run them at the only rez that would work out to 96 dpi. That is why he, and other people doing this work, have had problems. He can't assume anything. That's what I'm saying.

Quote:
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.

WHEN we get rez independence, things might change. But until then all of the problems remain.
post #82 of 142
Quote:
Originally Posted by Placebo

Where is the evidence that pixel pitch is going to get much denser in the future?

Veery little.
post #83 of 142
Quote:
Originally Posted by melgross

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.



Fully understood.

But changing the monitor resolution is just another SCALE. Half the resolution and you're using twice the number of underlying physical pixels (in each direction) used previously! Obviously the OS knows the monitor resolution, and once the OS knows about the physical space those pixels occupy, there's no need to ASSUME PPI (or DPI), no need to "Super Size" your fonts, and no real need to change the monitor resolution from it's maximum (although do it if it makes you feel good), ASSUMING resolution independence works 100% of the time (and I think it will).

Getting into arcane discussions about em's, print points, and "Super Sized" fonts, just complicates, what seems to me to be a simple straight forward issue. It's just a multiplier with a known dimension and known length scale.

It's just such a simple 2D geometry problem ONCE your OS knows the physical length scale.

Why are we discussing this at all? Exactly!

That was my first thought when this discussion started to focus on resolution independence, and someone wanted to negate the physical length scale, and IF a commonly understood length scale was absolute (in our frame of reference (i. e. flat space)) or not!

Fathom these questions. What is the only unit of measurement still used today that has a physical analog that needs to be periodically cleaned? And why is it a necessary physical analog? And how was this unit of measurement originally derived? Hint to the first question, go to the BIPM website. Hint to the second question, if you can't figure this one out, I give up! Hint to the third question, metric tonne.

Every eye fixed itself upon him; with parted lips and bated breath the audience hung upon his words, taking no note of time, rapt in the ghastly fascinations of the tale. NOT!
Reply
Every eye fixed itself upon him; with parted lips and bated breath the audience hung upon his words, taking no note of time, rapt in the ghastly fascinations of the tale. NOT!
Reply
post #84 of 142
Quote:
Originally Posted by melgross

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

PDF is already most of the way there. PDFs can hold a lot of detail in raster and vector form and they generally look good at any scaling level. All the reader software would need is the screen's pixel density. For LCDs, that would be just one more number to track in an OS database.
post #85 of 142
Quote:
Originally Posted by Placebo

Where is the evidence that pixel pitch is going to get much denser in the future?

There are several notebooks that run at about 150, just over twice the linear density as the original assumptions about display pixel density.
post #86 of 142
Wow, will you two take it outside? This thread is about Leopard features btw, not an argument on point vs pixels.
"I'm learning how to meditate, so far so good."
Donald Fagen and Walter Becker
Reply
"I'm learning how to meditate, so far so good."
Donald Fagen and Walter Becker
Reply
post #87 of 142
Quote:
Originally Posted by franksargent



Fully understood.

But changing the monitor resolution is just another SCALE. Half the resolution and you're using twice the number of underlying physical pixels (in each direction) used previously! Obviously the OS knows the monitor resolution, and once the OS knows about the physical space those pixels occupy, there's no need to ASSUME PPI (or DPI), no need to "Super Size" your fonts, and no real need to change the monitor resolution from it's maximum (although do it if it makes you feel good), ASSUMING resolution independence works 100% of the time (and I think it will).

Getting into arcane discussions about em's, print points, and "Super Sized" fonts, just complicates, what seems to me to be a simple straight forward issue. It's just a multiplier with a known dimension and known length scale.

It's just such a simple 2D geometry problem ONCE your OS knows the physical length scale.

Why are we discussing this at all? Exactly!

That was my first thought when this discussion started to focus on resolution independence, and someone wanted to negate the physical length scale, and IF a commonly understood length scale was absolute (in our frame of reference (i. e. flat space)) or not!

Fathom these questions. What is the only unit of measurement still used today that has a physical analog that needs to be periodically cleaned? And why is it a necessary physical analog? And how was this unit of measurement originally derived? Hint to the first question, go to the BIPM website. Hint to the second question, if you can't figure this one out, I give up! Hint to the third question, metric tonne.


Unfortunately, we seem to be discussing this because of flawed reasoning.

The OS knows nothing about the size of those pixels. Nothing at all. It doesn't know the size of the monitor. Apple used to assume, a long time ago, when their own monitors had a sensing line going to the monitor, that that monitor was a given size. But, that hasn't been true for quite some time. It stopped being true way back when multi-sync monitors were invented by NEC.

I know quite a few people who don't run their monitor at its nominal rez.

No assumptions are possible.

Even if rez independence comes about, the settings will have to be done manually.

you ate wrong about the physical analog. Those are obsolete. Have been for a while. Length is now spec'd as the length of atoms, or a multiple of Plank time as the distance light travels,the number of virbrations of certain atoms in a spec'd length of time, etc. All very absolute. At least for as long as the human race is concerned.

All metric measurements are related to each other. They are fixed.
post #88 of 142
Quote:
Originally Posted by JeffDM

PDF is already most of the way there. PDFs can hold a lot of detail in raster and vector form and they generally look good at any scaling level. All the reader software would need is the screen's pixel density. For LCDs, that would be just one more number to track in an OS database.

Yes, but the actual size of any feature of a PDF only holds true at the correct viewing size for that document. If the page is 8.5 x 11, then it must be viewed at that size. That's the entire, and only problem, we're having here.
post #89 of 142
Quote:
Originally Posted by JeffDM

There are several notebooks that run at about 150, just over twice the linear density as the original assumptions about display pixel density.

But it's also been written by numerous experts in the field that 150 is about as high as is required, as we can't even see finer screen details. even now, with 110, or so, it can be difficult to see all the detail without moving very close to the screen and squinting.

The smaller the pixels, the more numerous will be the dead ones, or the ones that are always turned on. That raises the cost of the panels as well.

There might always be a market for very high rez panels, but that market will be very small, and the panels will always cost over much for virtually everyone except for military, and scientific use. Not our concern at all.
post #90 of 142
How about Mac OS X detects your display resolution, and then asks you for the viewable size of the display, and recommends a UI scale?
post #91 of 142
Quote:
Originally Posted by Placebo

How about Mac OS X detects your display resolution, and then asks you for the viewable size of the display, and recommends a UI scale?

That would be great. Likely, the only way it could be done.

The only other way is one in which the manufacturers would all agree on standards. Each size monitor would have only certain resolutions. The problem would be that laptops have higher rez's than desktop models, and who believes that companies will agree to this anyway?

With 17, 18, 19, 20, 21, 22, 23, AND 24 inch models, it's going to be impossible. Then there are standard 4:3 displays, and 16:10 displays. go to Tv monitors, and one has 16:9.

Try to make sense out of all this.
post #92 of 142
It's not very good user experience for the computer to ask the user what size the monitor is, though.

How about if Apple maintains a list of display models and their sizes? The model can probably be found out automatically.

Actually, judging from Wikipedia's EDID page, the maximum viewable size is indeed given. Of course, it's a question of how many screens really support that.
post #93 of 142
Quote:
Originally Posted by Chucker

It's not very good user experience for the computer to ask the user what size the monitor is, though.

How about if Apple maintains a list of display models and their sizes? The model can probably be found out automatically.

Actually, judging from Wikipedia's EDID page, the maximum viewable size is indeed given. Of course, it's a question of how many screens really support that.

That's nice, but I don't know of any package that really supports that. I don't think most (or any?) cards do either.
post #94 of 142
I'm buying a standard density display, but I'm probably gonna scale the UI down anyways.
post #95 of 142
Quote:
Originally Posted by melgross

Unfortunately, we seem to be discussing this because of flawed reasoning.

The OS knows nothing about the size of those pixels. Nothing at all. It doesn't know the size of the monitor. Apple used to assume, a long time ago, when their own monitors had a sensing line going to the monitor, that that monitor was a given size. But, that hasn't been true for quite some time. It stopped being true way back when multi-sync monitors were invented by NEC.

I know quite a few people who don't run their monitor at its nominal rez.

No assumptions are possible.

Even if rez independence comes about, the settings will have to be done manually.

you ate wrong about the physical analog. Those are obsolete. Have been for a while. Length is now spec'd as the length of atoms, or a multiple of Plank time as the distance light travels,the number of virbrations of certain atoms in a spec'd length of time, etc. All very absolute. At least for as long as the human race is concerned.

All metric measurements are related to each other. They are fixed.



I am quite sure that the linear equation is correct. I am quite sure that my empirical measurements (of my Planar PL2010M) LCD are correct (within my measurement error estimate of 0.3%) and agree with the manfacturer's data (for 3V:4H and 4V:5H aspect ratios). It works no matter what resolution you set your display at, you always end up with 2 PPI values (H and V) and 2 lengths (H and V) that define it's effective pixel density and the viewable display area, respectively. For example, on my LCD, it's 404 mm H and 303 mm V, and has a native pixel density of 99.6 PPI (or 1600H bt 1200V), from using this data alone I can calculate all possible PPI's for all resolutions, with just simple linear math (now if the physical size of your display area changes (like in the good old CRT days) this also has to be incorporated into the effective PPI calculation, but it didn't for my LCD). Theory + empirical data = calabrated model, model vaildaion requires at least one additional empirical data set, but this squation is so simple that I don't see how it's possible that it's wrong.

How Apple (or anyone else) would impliment this is up to them. And if it works like I believe it could, why change resolution from the maximum native, since you're now doing in SW what is currently done through HW (via SW interface) for a finite fixed set of HW resolutions, and I believe you will preserve the most detail at the maximum resolution. I've already suggested either; 1) a simple manual method (which I'm sure that Apple could simplify to a simple on screen square and plastic templete, a la the manual ColorSync approach), or 2) a display database (which I'm sure Apple will do at least for their displays). In the end, and being an engineer, I don't much care how Apple does it, just give me a knob to turn! 8)

WRT my questions, please see the following link;

Kilogram

It addresses the first question, you need a little reverse engineering logic and Einstein's E=Mc^2 to realize the second, and some very basic math solves the third.

Every eye fixed itself upon him; with parted lips and bated breath the audience hung upon his words, taking no note of time, rapt in the ghastly fascinations of the tale. NOT!
Reply
Every eye fixed itself upon him; with parted lips and bated breath the audience hung upon his words, taking no note of time, rapt in the ghastly fascinations of the tale. NOT!
Reply
post #96 of 142
Quote:
Originally Posted by franksargent



I am quite sure that the linear equation is correct. I am quite sure that my empirical measurements (of my Planar PL2010M) LCD are correct (within my measurement error estimate of 0.3%) and agree with the manfacturer's data (for 3V:4H and 4V:5H aspect ratios). It works no matter what resolution you set your display at, you always end up with 2 PPI values (H and V) and 2 lengths (H and V) that define it's effective pixel density and the viewable display area, respectively. For example, on my LCD, it's 404 mm H and 303 mm V, and has a native pixel density of 99.6 PPI (or 1600H bt 1200V), from using this data alone I can calculate all possible PPI's for all resolutions, with just simple linear math (now if the physical size of your display area changes (like in the good old CRT days) this also has to be incorporated into the effective PPI calculation, but it didn't for my LCD). Theory + empirical data = calabrated model, model vaildaion requires at least one additional empirical data set, but this squation is so simple that I don't see how it's possible that it's wrong.

How Apple (or anyone else) would impliment this is up to them. And if it works like I believe it could, why change resolution from the maximum native, since you're now doing in SW what is currently done through HW (via SW interface) for a finite fixed set of HW resolutions, and I believe you will preserve the most detail at the maximum resolution. I've already suggested either; 1) a simple manual method (which I'm sure that Apple could simplify to a simple on screen square and plastic templete, a la the manual ColorSync approach), or 2) a display database (which I'm sure Apple will do at least for their displays). In the end, and being an engineer, I don't much care how Apple does it, just give me a knob to turn! 8)

WRT my questions, please see the following link;

Kilogram

It addresses the first question, you need a little reverse engineering logic and Einstein's E=Mc^2 to realize the second, and some very basic math solves the third.


I did say that it woukld have to be done manually. I've done it myself many times. But, as you noted, the ppi (people, please stop saying dpi for monitors!) is 99.6. An odd size.

You're correct about the gram, but scientific establishments that can do so have already abandoned the physical unit.
post #97 of 142
Quote:
Originally Posted by melgross

I did say that it woukld have to be done manually. I've done it myself many times. But, as you noted, the ppi (people, please stop saying dpi for monitors!) is 99.6. An odd size.

You're correct about the gram, but scientific establishments that can do so have already abandoned the physical unit.



Yes, using Einstein's E=Mc^2 and solving for M, you learn something new every day, but I think this only applies to atomic particles, and the empirical methods (particle accelerators) used to determine the energy of these particles (yes theoretical models exist that predict the mass of these partivles, but without observational data are virtually useless, and all theories come from someone observing something unexplained). But it still has the units of mass (i. e. the kilogram or amu or whatever multiplier they choose to use]. don't know how this would apply to aggregates of particles, thus you've pretty much answered the second question (i. e. destroy the very thing you're trying to measure, I don't think I'll stand next to that scale)!

Every eye fixed itself upon him; with parted lips and bated breath the audience hung upon his words, taking no note of time, rapt in the ghastly fascinations of the tale. NOT!
Reply
Every eye fixed itself upon him; with parted lips and bated breath the audience hung upon his words, taking no note of time, rapt in the ghastly fascinations of the tale. NOT!
Reply
post #98 of 142
Quote:
Originally Posted by melgross

With 17, 18, 19, 20, 21, 22, 23, AND 24 inch models, it's going to be impossible. Then there are standard 4:3 displays, and 16:10 displays. go to Tv monitors, and one has 16:9.

Try to make sense out of all this.

This is the stuff that Apple seems to excel at. Making sense of something and making it simple for us mere mortals.

I think some of you guys are so deep into the forest that you can't see the trees.
iPad2 16 GB Wifi

Who is worse? A TROLL or a person that feeds & quotes a TROLL? You're both idiots.....
Reply
iPad2 16 GB Wifi

Who is worse? A TROLL or a person that feeds & quotes a TROLL? You're both idiots.....
Reply
post #99 of 142
Quote:
Originally Posted by franksargent



Yes, using Einstein's E=Mc^2 and solving for M, you learn something new every day, but I think this only applies to atomic particles, and the empirical methods (particle accelerators) used to determine the energy of these particles (yes theoretical models exist that predict the mass of these partivles, but without observational data are virtually useless, and all theories come from someone observing something unexplained). But it still has the units of mass (i. e. the kilogram or amu or whatever multiplier they choose to use]. don't know how this would apply to aggregates of particles, thus you've pretty much answered the second question (i. e. destroy the very thing you're trying to measure, I don't think I'll stand next to that scale)!


Heh heh. Don't forget that mass and weight are two different things.

If we really want to be accurate, the only place where the gram weighs a gram, accurate to just so many decimal places, is where is was determined in the first place. Move it a few miles, and the gravity is different. It will seem the same, because everything else will change along with it, but it really won't be. strain gauge scales will be able to tell, but most conventional scales won't.

That's why using atomic mass is more accurate. Eliminates the gravity field.
post #100 of 142
Quote:
Originally Posted by kcmac

This is the stuff that Apple seems to excel at. Making sense of something and making it simple for us mere mortals.

I think some of you guys are so deep into the forest that you can't see the trees.

No. we're so deep into the work we do, that we're tired of the confusion.

Apple hasn't helped in the slightest.

I also assume that you got the expression mixed up on purpose.
post #101 of 142
Quote:
Originally Posted by melgross

the ppi (people, please stop saying dpi for monitors!)

Why? Isn't the distinction only relevant for unrelated fields?
post #102 of 142
Quote:
Originally Posted by JeffDM

Why? Isn't the distinction only relevant for unrelated fields?

There are distinctions.

Dpi is for print. Ppi is for displays, and spi is for scanning.
post #103 of 142
There's also lpi.
post #104 of 142
Wow, this has turned into a real pissing contest....

Proud AAPL stock owner.

 

GOA

Reply

Proud AAPL stock owner.

 

GOA

Reply
post #105 of 142
*Head explodes*
post #106 of 142
Quote:
Originally Posted by Chucker

There's also lpi.

That's true. I forgot that one.
post #107 of 142
Quote:
Originally Posted by SpamSandwich

Wow, this has turned into a real pissing contest....

No it's not. It's an interesting discussion.
post #108 of 142
Quote:
Originally Posted by SpamSandwich

Wow, this has turned into a real pissing contest....

I don't think much arguing is going on.
post #109 of 142
It's not hard to define fonts with em/ex relationships and let the browser scale accordingly.

When you write a custom print page then use your pt/cm layouts.
post #110 of 142
Quote:
Originally Posted by mdriftmeyer

It's not hard to define fonts with em/ex relationships and let the browser scale accordingly.

When you write a custom print page then use your pt/cm layouts.

Yers, that could be done. It's a better idea than some I've heard.
post #111 of 142
Chuck, Placebo, melgross a.o.: few Mac people seem to be aware of the DDC standard, which, among other things, requires the monitor to return the physical dimensions of the display area to the graphics card (this info is given in the time frame between subsequent screen refreshes). You should also distinguish display resolution from screen resolution (the maximum display resolution the screen can handle); and also, do not forgot that horizontal PPI is not necessarily equal to the vertical PPI.

In X11, some of this DDC info can be queried with "xdpyinfo". Curiously enough, X11 on my Mac returns made-up values for the screen dimensions, resulting in 75 PPI both horizontally and vertically (instead of the real PPI of 114 on my MacBook for instance). Perhaps this is done to preserve consistency with other Mac applications which assume 72 PPI.

To my knowledge, X11 has always had scaling factors that could be set by the user or automatically derived from xdpyinfo's output. The X11 font server is one service that implements resolution independence. On the application level, one example I can think of is an earlier version of the Mozilla browser, which allowed the PPI parameter to be set by the user to something else than 96.

And one last thing: resolution independence or UI scaling involves much more than just scaling graphics and letters: hinting, subpixel positioning, correct handling of rounding errors, bitmap caching. It is a non-trivial task to implement this while maintaining the high typographic/visual quality that we are used to see from Apple.
post #112 of 142
Quote:
Originally Posted by dhvu

Chuck, Placebo, melgross a.o.: few Mac people seem to be aware of the DDC standard, which, among other things, requires the monitor to return the physical dimensions of the display area to the graphics card (this info is given in the time frame between subsequent screen refreshes).

I did mention that. (EDID is what you mean.)

Quote:
In X11, some of this DDC info can be queried with "xdpyinfo". Curiously enough, X11 on my Mac returns made-up values for the screen dimensions, resulting in 75 PPI both horizontally and vertically (instead of the real PPI of 114 on my MacBook for instance). Perhaps this is done to preserve consistency with other Mac applications which assume 72 PPI.

On Mac OS X, X11 runs on top of Quartz, which is why your xdpyinfo isn't actually getting real hardware data.

Quote:
And one last thing: resolution independence or UI scaling involves much more than just scaling graphics and letters: hinting, subpixel positioning, correct handling of rounding errors, bitmap caching.

All of which, AFAICT, area already implemented.
post #113 of 142
Quote:
I did mention that. (EDID is what you mean.) [... "Actually, judging from Wikipedia's EDID page, the maximum viewable size is indeed given. Of course, it's a question of how many screens really support that.]

actually, all monitors that i have come across in the last years.

Quote:
On Mac OS X, X11 runs on top of Quartz, which is why your xdpyinfo isn't actually getting real hardware data.

so why is it 75 ppi then, instead of 72?

Quote:
All of which, AFAICT, area already implemented.

sure; i just wanted to stress that resolution independence is a BIG feature of Leopard; the idea is simple, but the implementation is difficult. especially if one has to provide a comfortable upgrade path for all those existing pixel-perfect applications.
post #114 of 142
Quote:
Originally Posted by Chucker

I don't think much arguing is going on.

I guess "pissing" may not be the right word... but for me, it is a very educational pissing contest.

Proud AAPL stock owner.

 

GOA

Reply

Proud AAPL stock owner.

 

GOA

Reply
post #115 of 142
Quote:
Originally Posted by dhvu

Chuck, Placebo, melgross a.o.: few Mac people seem to be aware of the DDC standard, which, among other things, requires the monitor to return the physical dimensions of the display area to the graphics card (this info is given in the time frame between subsequent screen refreshes). You should also distinguish display resolution from screen resolution (the maximum display resolution the screen can handle); and also, do not forgot that horizontal PPI is not necessarily equal to the vertical PPI.

In X11, some of this DDC info can be queried with "xdpyinfo". Curiously enough, X11 on my Mac returns made-up values for the screen dimensions, resulting in 75 PPI both horizontally and vertically (instead of the real PPI of 114 on my MacBook for instance). Perhaps this is done to preserve consistency with other Mac applications which assume 72 PPI.

To my knowledge, X11 has always had scaling factors that could be set by the user or automatically derived from xdpyinfo's output. The X11 font server is one service that implements resolution independence. On the application level, one example I can think of is an earlier version of the Mozilla browser, which allowed the PPI parameter to be set by the user to something else than 96.

And one last thing: resolution independence or UI scaling involves much more than just scaling graphics and letters: hinting, subpixel positioning, correct handling of rounding errors, bitmap caching. It is a non-trivial task to implement this while maintaining the high typographic/visual quality that we are used to see from Apple.

As I said earlier, few devices are capable of using such information. It is a standard that is rarely implemented. When it is not, incorrect results are returned, as you found out.

Yes, you are correct about the difficulties that ensue when rez independence is attempted. this is why we have not seen it before. Too many things have to fall into place.
post #116 of 142
Quote:
Originally Posted by dhvu

actually, all monitors that i have come across in the last years.



so why is it 75 ppi then, instead of 72?

It is not being implemented. Half of the system isn't sufficient.

Quote:
sure; i just wanted to stress that resolution independence is a BIG feature of Leopard; the idea is simple, but the implementation is difficult. especially if one has to provide a comfortable upgrade path for all those existing pixel-perfect applications.

We don't yet know if it is a feature that will be implemented for the user.
post #117 of 142
Quote:
Originally Posted by melgross

Heh heh. Don't forget that mass and weight are two different things.

If we really want to be accurate, the only place where the gram weighs a gram, accurate to just so many decimal places, is where is was determined in the first place. Move it a few miles, and the gravity is different. It will seem the same, because everything else will change along with it, but it really won't be. strain gauge scales will be able to tell, but most conventional scales won't.

That's why using atomic mass is more accurate. Eliminates the gravity field.



Definitely, I kind of figured they (BIPM, NIST, others) weren't weighing the artifacts (as these Kilogram prototypes are referred to as) due to just the effects (plus a WHOLE bunch of others!) you mentioned. I did find several very insightful PDF's by BIPM/NIST and you may be surprised at how they measure the mass while avoiding these effects.

They use a beam balance, which in principle is just like the ones we all used in high school!

Of course these beam balances are precision electro-mechanical-optical devices able to achieve accuracies of up to 1 part in a trillion (10^12), which to my surprise is still about 2 orders of magnitude higher than other current methods (atomic, etcetera). But if all goes according to plan, by 2011 or so they will be able to ditch these artifacts for other methods based on physically known constants.

To use the beam balance they use the the primary (plus several copies) and do weigh-offs with newly fabricated ones (i. e. when the balance is level the copy is good to go). Supersets of 1 Kg are fairly straight forward (in fact NIST makes them as large as 28,000 Kg!). Subsets are where they get a little more clever, for instance they step down to 1000+500+200+200+100 g unknowns and 2 1000 g knowns using a 6 step permutation sequence. And a similar procedure is used to obtain even smaller sizes, until you end up with a set of weights like the set of SS weights we all used in high school!

BTW, a metric tonne is just 1000 Kg of pure water which just happens to fit into a 1 meter cube, thus the original relationship between the Kilogram and Meter, and why rho = 1 g/cc.

PS - I know this is off topic, but I just couldn't resist, it's a subject area I've dealt with for over 30 years now (geometric, kinematic, and dynamic similitude AKA Froude scaling). I hope you'll excuse the interruption!

Every eye fixed itself upon him; with parted lips and bated breath the audience hung upon his words, taking no note of time, rapt in the ghastly fascinations of the tale. NOT!
Reply
Every eye fixed itself upon him; with parted lips and bated breath the audience hung upon his words, taking no note of time, rapt in the ghastly fascinations of the tale. NOT!
Reply
post #118 of 142
Quote:
Originally Posted by franksargent


BTW, a metric tonne is just 1000 Kg of pure water which just happens to fit into a 1 meter cube, thus the original relationship between the Kilogram and Meter, and why rho = 1 g/cc.


Don't forget the temperature compensation.
post #119 of 142
There are a couple of screen shots showing more Leopard WWDC preview features on the Aero Experience forum, one of the images shows a semi complete vector UI!

Check it out!



http://www.aeroxp.org/board/index.php?showtopic=5209
post #120 of 142
Quote:
Originally Posted by deestar

There are a couple of screen shots showing more Leopard WWDC preview features on the Aero Experience forum, one of the images shows a semi complete vector UI!

Check it out!



http://www.aeroxp.org/board/index.php?showtopic=5209


Some cool shots on that site.
iPad2 16 GB Wifi

Who is worse? A TROLL or a person that feeds & quotes a TROLL? You're both idiots.....
Reply
iPad2 16 GB Wifi

Who is worse? A TROLL or a person that feeds & quotes a TROLL? You're both idiots.....
Reply
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Mac OS X
AppleInsider › Forums › Software › Mac OS X › More features of Apple's Leopard leaked on Web