As for OLEDs I am not so sure that Apple wants to put a technology that has limited lifetime (thanks to the stank blue organics) in a laptop. There are tons of alternative technologies being developed, most notably LEPs.
Not to be nitpicking, but OLED and LEP are one and the same - LEDs made of plastic forming the RGB subpixels of future flat panel displays. The technology is promising, but it still has some way to go, both technological and economical, before it can replace TFT in large (10" and above) panels.
Tiger already implements resolution independent GUI (the basis for it was built-in in Quartz since public beta). The initial release will not have user control for it but it can be changed programatically. With the developer tools there is a utility which can change the resolution (or "scaling factor") now. The benefit is that you can change the size of the interface elements but keep the detail. And you can use the native LCD resolution but select whatever scale you like.
Apple Computer may be planning to offer PowerBooks with higher density displays, and may have intended to do so with its latest PowerBook offerings, tipsters tell AppleInsider.
It's either that, or the company is speaking with a loose interpretation of the term "native resolution" in the printed user manuals that are being shipped with the first batch of its new 17-inch PowerBook models.
Page 22 of Apple's new 17-inch PowerBook G4 manual reads: "Depending on how your PowerBook was configured, it may have a wide-screen display that has a 'native' resolution of 1920 x 1200 or 1440 x 900. For either of these native resolutions, other standard resolutions, such as 1024 x 768, are supported."
Currently, the 17-inch PowerBook G4 ships with a native screen resolution of 1440 x 900 pixels, which offers about 1,296,000 total pixels. A display with a native resolution of 1920 x 1200 is of much higher density, offering sharper images with nearly double the pixel count (2,304,000), and thus double the screen density. Nowhere on Apple's website is there mention of this higher density resolution, nor are there any configure-to-order options available at the Apple Store.
Apple Care customer support representatives are also perplexed by the statement in the user manual. None of the representatives with whom AppleInsider correspondents spoke could offer an explanation of the aforementioned documentation, but they did rule out the possibility that it was a reference to the PowerBook's video mirroring or external display feature.
Screens with a resolution of 1920 x 1200 are categorized as WUXGA displays, which is short for Wide Ultra eXtended Graphics Array. PowerBooks currently ship with WXGA displays (or Wide XGA).
For quite some time, Apple's laptop users have been clamoring for higher resolution displays. These higher density/higher resolution displays offer more desktop space in same-size screen, allowing power users and designers to work more efficiently and providing an alternative to connecting an external display for additional workspace.
In the past, Apple has only offered a single screen option for its PowerBooks, leaving consumers with little choice in configuring their laptops with the higher density screens that have been available from other vendors for quite some time. For example, both Dell and Sony offer WUXGA displays on their 17-inch Inspiron 9200 and VAIO A170B25 notebooks, respectively. Dell also offers a 15.4-inch WUXGA display option on its Precision M70 notebook for an additional US$130.
Some insiders speculate that Apple's PowerBook sales volume does not justify the additional costs of offering another configuration. But as of yet, Apple has even failed to offered a configure-to-order display option through its online store, which would presumably reduce costs and allow 'power users' to pay a premium for an optional higher density display.
Page 22 from the new 17-inch PowerBook user manual.
As far as Apple's reference a 1920 x 1200 WUXGA display in the 17-inch PowerBook user manual, it could be a mistake or simply a misleading statement. But more likely, the manual references an undelivered display option that was planned with the last round of PowerBook G4 updates, but canned just prior to the product line update released earlier this month.
Typically, Apple chooses not to author its user-based product documentation far in advance of product releases, due to the potential for product specs and features to change throughout the course of product development. In its shroud of secrecy, the company also holds off publication of such documentation until the very last minute to avoid leaks to the media and public.
Meanwhile, other sources claim the new display option may be announced as a standard or configure-to-order option on an upcoming PowerBook "HD" model, which would bode with Steve Jobs' claim that 2005 will be the "year of high definition" ("HD").
I see 1920 x 1200 PB coming only along Tiger release...
The main reason Apple was not introducing high-resolution displays on PB is user experience. Some time ago I recommended a notebook with high-resolution display to a friend and still feel sorry for that. The vast majority of everyday tasks are a real pain on such screen. You have to be a geek to convince yourself that this is a "good thing". Using a non-native resolution on LCD display is not a pleasure either. The other problem is that viewing a document at 100% on a high-res display does not tell you much about the actual size of the document and "actual size" becomes an abstract term.
Hopefully this will change in Tiger (and Longhorn for that matter). The key is Resolution Independent GUI (see my post above). It's implementation, however, is much more complicated than it may look. To have a sharp user controls the interface should be rendered to an "integer" number of pixels (I mean no antialiasing or 50% gray to represent "half" of a pixel - we already have this with non-native resolutions), and all adjacent objects should be perfectly aligned, so it will take some time before we have polished resolution independent user interface (remember PostScript printing on 300 dpi printers a decade ago, and this is still much better than current high-res displays). Integer scaling factors should not be a problem but this brings 1920 x 1200 to 960 x 600 equivalent...
An important thing to note is that scaling factor in Tiger can be applied on by-window basis so this gives the option for developers to offer different scaling for pallets, panes and document windows.
Perhaps resolution GUI is a surprise annoucement for Tiger.
Think exposé. It can shrink a window and have it still operate. One could set a browser window to operate in a zoomed mode so pictures and text are more readable. Besides the browser the menu bar is the only other big thing that would need adjustability.
To tackle aps a new framework for aps could be intoduced that allow them to scale the text used in their aps. But that I don't think is such a big problem.
Hell if you think about it OS X is pretty much nearly resolution independednt right now. What can NOT be scaled up with a preference setting besides the menu bar?
Perhaps resolution GUI is a surprise annoucement for Tiger.
Think exposé. It can shrink a window and have it still operate. One could set a browser window to operate in a zoomed mode so pictures and text are more readable. Besides the browser the menu bar is the only other big thing that would need adjustability.
To tackle aps a new framework for aps could be intoduced that allow them to scale the text used in their aps. But that I don't think is such a big problem.
Hell if you think about it OS X is pretty much nearly resolution independednt right now. What can NOT be scaled up with a preference setting besides the menu bar?
The problem is that most of the system's as well as the apps' UI elements are still bitmap graphics.
Makings the system's UI elements vector based is completely in Apple's hand, but it will take a little longer for the app developers to catch up.
It would be a total break and will take a transition period. I am curious about how Microsoft will tackle this issue because they also plan to introduce a vector based UI (an altered form of the SVG standard) with Longhorn - unless they recently dropped those plans.
Am I the only one who doesn't understand all this talk of a 'resolution-dependent GUI'?
I semi-understand it, as in if you have a higher resolution you don't sacrifice size, but get detail or something...
Is there not an article somewhere with images and such?
Rather than churning through the long explanation Amorph gave a while back, just click here to view his wonderful explanation.
Quote:
Originally posted by Smircle
Not to be nitpicking, but OLED and LEP are one and the same - LEDs made of plastic forming the RGB subpixels of future flat panel displays. The technology is promising, but it still has some way to go, both technological and economical, before it can replace TFT in large (10" and above) panels.
LEP is a type of OLED but there are two different (the last time I checked) technologies - one uses small-molecule, vacuum evaporating particles (the typical OLED) where LEPs use large-molecule, inkjet-printed manufacturing processes that are much simpler (read: cheaper) to manufacture. Beyond that, some companies claim that the large-molecule based LEPs do not suffer from the shorter lifespan that OLED small-molecule displays do.
What exactly is the point in getting all those extra pixels, if all you want to do is make the icons, text, and UI bigger? It negates the reason why you got the extra pixels in the first place...
I for one would not want to see a 17" PB with a native-resolution above 1680x1050... anything more and, well, good luck using those new pixels properly...
What exactly is the point in getting all those extra pixels, if all you want to do is make the icons, text, and UI bigger? It negates the reason why you got the extra pixels in the first place...
I for one would not want to see a 17" PB with a native-resolution above 1680x1050... anything more and, well, good luck using those new pixels properly...
Resolution independence. See the link I posted above by Amorph. Basically, it is like a 300dpi printer versus a 600dpi printer. Same physical size display, just much sharper at higher resolutions. It takes the pixel out of the display measure.
What exactly is the point in getting all those extra pixels, if all you want to do is make the icons, text, and UI bigger? It negates the reason why you got the extra pixels in the first place...
I for one would not want to see a 17" PB with a native-resolution above 1680x1050... anything more and, well, good luck using those new pixels properly...
There is one more reason we need resolution independent display.
There are applications (games, kiosk applications etc. - mostly full screen stuff) which are designed for specific screen resolution. The "old style" for dealing with this was to switch the resolution while the application is running. This is OK for a CRT but we know what happens with the LCD when switched to a non-native resolution. As an extra credit we have more flexible user control.
I'm also a big fan of a resolution independent UI. People are already talking about a transition period for mac software.
But has anyone been thinking about the consequences this would have on websites? Fonts became res independent with HTML 4, but all graphics, with the exception of flash and svg, are res dependent.
Although it is possible, especially when using css, webdesigners have never used res independent graphics, partially because it renders ugly in IE (nearest neighbor scaling) but also because you need to use high res images resulting in longer download times.
I hope we get this long awaited transition in webdesign, but it might take a little longer than the transition of mac apps. In the meantime all the simeys will look ugly on your BTO hi-res PowerBook.
I'm also a big fan of a resolution independent UI. People are already talking about a transition period for mac software.
But has anyone been thinking about the consequences this would have on websites? Fonts became res independent with HTML 4, but all graphics, with the exception of flash and svg, are res dependent.
Although it is possible, especially when using css, webdesigners have never used res independent graphics, partially because it renders ugly in IE (nearest neighbor scaling) but also because you need to use high res images resulting in longer download times.
I hope we get this long awaited transition in webdesign, but it might take a little longer than the transition of mac apps. In the meantime all the simeys will look ugly on your BTO hi-res PowerBook.
I hope - and this is current reality in the developer preview - that resolution independance can be applied on a window by window basis by the developer.
And with the state of webdesign this is really necessary. A true separation of layout and content is hardly ever realised as most sites still use tables for their layout.
Another problem is pixel graphics that won't scale.
And most sites are designed for Windows and the IE and when style sheets are used, font sizes are declared in pt.
Imagine this in a resolution independant browser: scaled text, small graphics and a messed-up layout.
A solution would be to first render the pages at "old" ppi and then zooming in to match the resolution independance.
Bitmap graphics aren't really resolution dependent. You've just got to be aware that if you scale them past their native resolution, you'll get mixed results based on the image type.
If you're screen is in the 72-100 DPI range, they'll be at 100% they're native resolution. If your screen is 133 DPI, they'll be "enlarged" to stay the same size. So relative to the rest of your screen, they'll be blurrier, but they'll be pretty much the same as they are now.
Photographs and most Aqua-ish interface items will look exactly the same as they do now The problem comes with the really tight, graphic-designy pixel-sized art and text other people were talking about. That'll just look kinda blurry.
I take that back. I just did a photoshop test of scaling something from 72 DPI to 133 DPI and back. It was blurry, but just a sharpen filter made the graphic design side look the same and the Aqua element look much better than the original. So, I say, bring resolution independence on.
Imagine this in a resolution independant browser: scaled text, small graphics and a messed-up layout.
A solution would be to first render the pages at "old" ppi and then zooming in to match the resolution independance.
You are missing the point completely. You are describing the behaviour of the browser when you change the dpi in browser's preferences (that is, indirectly select different font size). In the resolution independent UI (at the later stage, when the user will be able to set scale factor) the developer should not bother whether the content is scaled or not. Even the methods which return information on applied transformations will ignore the UI scaling.
Currently the UI scaling will be control by the application (not by the user) but in any case it will be applied to the ENTIRE window. When the user control of the scaling is implemented (and I expect there will be a freeware/shareware/unsupported utility in place when Tiger ships) you may change on per user basis the scaling of everything, including the menu bar and window titles. On different res displays it may look like a 300dpi printer versus a 600dpi printer (see Rhumgod's post above).
You are missing the point completely. You are describing the behaviour of the browser when you change the dpi in browser's preferences (that is, indirectly select different font size). In the resolution independent UI (at the later stage, when the user will be able to set scale factor) the developer should not bother whether the content is scaled or not. Even the methods which return information on applied transformations will ignore the UI scaling.
Currently the UI scaling will be control by the application (not by the user) but in any case it will be applied to the ENTIRE window. When the user control of the scaling is implemented (and I expect there will be a freeware/shareware/unsupported utility in place when Tiger ships) you may change on per user basis the scaling of everything, including the menu bar and window titles. On different res displays it may look like a 300dpi printer versus a 600dpi printer (see Rhumgod's post above).
I am entirely aware of the fact that noone should bother about resolution (in)dependence once it is implemented. But some one has to implement it first!
The major obstacle I see is the Internet, the WWW specifically.
My solution describes a way for keeping compatibility with websites that were not designed with resolution independence in mind (i.e. 99,999999999% of all websites out there) for the reasons stated: mash-up of layout and content, mixture of absolute (mostly pixel-related: tables, bitmap images etc.) and relative (font sizes in pt etc.) settings.
What happens when a resolution independent browser renders a typical webpage is the following:
- the fonts will be blown up because they are meant to scale (measurements in pt)
- the graphics and tabels (measurements in pixels) will beome to small relative to the text
- thus the whole layout will be messed up
You can simulate this behavior today - as you correctly described - by pumping up the font size.
Since websites will be developed to be res-indepedent (all measurements being relative), the OS (or browser) will have to take care of it.
The easiest way is the one I described:
- scaling the absolute parts to match the resolution ratio set
UI scaling will be fairly easy to acomplish since it is almost completely in Apple's hands. Once they change the UI widgets to be vector based, all applications will adapt without the developers interaction.
The problem here are UI elements that are not OS inherent, e.g. bitmap icons for tool bar, paletts etc.
Apple introduced an obstacle to res-independence themselves with Dashboard. Since it will be Web-Kit based, they face the same problems as described above. No ture res-independence.
- the fonts will be blown up because they are meant to scale (measurements in pt)
- the graphics and tabels (measurements in pixels) will beome to small relative to the text
- thus the whole layout will be messed up
Well, may be I am not good enough in explaining things but this is not the case.
I will try once more (others -help!)
1. Open a browser window containing text and images. If you can not switch to higher resolution make the window smaller so it does not resize during step 2 (resizing the browser window does cause reflow but this has nothing to do with res independent UI).
2. Switch the display mode from System Preferences: Displays to different resolution.
What happens? Does the image on your web page keep the previous size? Does the size of the text and image change differently?
Another try:
1. Open a browser window containing text and images.
2. Make a screen dump (Command-Shift-3).
3. Open the file Picture 1 found on your desktop in Photoshop. Set the view to 100%.
4. From Image - Image Size change the Resolution from 72 to, say, 144. Make sure the checkboxes "Constrain Proportions" and "Resample image" are checked. Press OK.
5. Set the View to 50% and compare with 3. Does the text reflow?
You are confused by the fact that in most applications you use display different units for text and drawing/image sizes. This is not the case in Quartz. You always use common measurement units there. Namely, all coordinates are described in points (using floating point numbers, not integer!). And here comes the only difference: until now (resolution dependent UI) we assume that 1 point = 1 pixel, 100 points = 100 pixels. With the arrival of resolution independent UI there is a scaling factor. If the scaling factor is 1.25 then 100 points = 125 pixels and YES, this is performed AFTER all content (text, graphics, user controls) are in place.
There are 2 major problems here:
1. The developers should check their old apps that they never assumed that 1 pixel = 1 point. For example if the developer places an 100x100 pixels image in a 100x100 points window with scale factor 1.25 the window (and the cached image) will be scaled to 125x125 pixels. Now, if the developer checks the size of the image using method (system call) which returns the number of pixels (hey, it used to be the same before!) he will get wrong result. He used the assumption that 1 pixel = 1 point.
2. The rendering quality. It is not an easy task to scale (bitmap) using non-integer multipliers without artifacts. Take the PostScript: it uses so called "hints" for the fonts (otlines/vector format) to make sure that the left and right stem of the letter "H" has the same number of pixels (simple rounding may not work and this will not look good on not-so-hi-res devices). It could be worse: Some letters may be "broken" just because some of the pixels happen to round to 0. If the view content is already in bitmap format the UI will not have information how to do with this except using antialiasing which blurs the image/text.
- the fonts will be blown up because they are meant to scale (measurements in pt)
- the graphics and tabels (measurements in pixels) will beome to small relative to the text
- thus the whole layout will be messed up
Just one more try...
Download Opera and play with the View - Zoom menu. This will give you a good idea what happens. I am not aware of any other browser capable of zooming window contents. Forget Mozilla "resolution independence", it stands for "font size"!
Comments
Originally posted by Rhumgod
As for OLEDs I am not so sure that Apple wants to put a technology that has limited lifetime (thanks to the stank blue organics) in a laptop. There are tons of alternative technologies being developed, most notably LEPs.
Not to be nitpicking, but OLED and LEP are one and the same - LEDs made of plastic forming the RGB subpixels of future flat panel displays. The technology is promising, but it still has some way to go, both technological and economical, before it can replace TFT in large (10" and above) panels.
Link: http://www.appleinsider.com/article.php?id=610
It's either that, or the company is speaking with a loose interpretation of the term "native resolution" in the printed user manuals that are being shipped with the first batch of its new 17-inch PowerBook models.
Page 22 of Apple's new 17-inch PowerBook G4 manual reads: "Depending on how your PowerBook was configured, it may have a wide-screen display that has a 'native' resolution of 1920 x 1200 or 1440 x 900. For either of these native resolutions, other standard resolutions, such as 1024 x 768, are supported."
Currently, the 17-inch PowerBook G4 ships with a native screen resolution of 1440 x 900 pixels, which offers about 1,296,000 total pixels. A display with a native resolution of 1920 x 1200 is of much higher density, offering sharper images with nearly double the pixel count (2,304,000), and thus double the screen density. Nowhere on Apple's website is there mention of this higher density resolution, nor are there any configure-to-order options available at the Apple Store.
Apple Care customer support representatives are also perplexed by the statement in the user manual. None of the representatives with whom AppleInsider correspondents spoke could offer an explanation of the aforementioned documentation, but they did rule out the possibility that it was a reference to the PowerBook's video mirroring or external display feature.
Screens with a resolution of 1920 x 1200 are categorized as WUXGA displays, which is short for Wide Ultra eXtended Graphics Array. PowerBooks currently ship with WXGA displays (or Wide XGA).
For quite some time, Apple's laptop users have been clamoring for higher resolution displays. These higher density/higher resolution displays offer more desktop space in same-size screen, allowing power users and designers to work more efficiently and providing an alternative to connecting an external display for additional workspace.
In the past, Apple has only offered a single screen option for its PowerBooks, leaving consumers with little choice in configuring their laptops with the higher density screens that have been available from other vendors for quite some time. For example, both Dell and Sony offer WUXGA displays on their 17-inch Inspiron 9200 and VAIO A170B25 notebooks, respectively. Dell also offers a 15.4-inch WUXGA display option on its Precision M70 notebook for an additional US$130.
Some insiders speculate that Apple's PowerBook sales volume does not justify the additional costs of offering another configuration. But as of yet, Apple has even failed to offered a configure-to-order display option through its online store, which would presumably reduce costs and allow 'power users' to pay a premium for an optional higher density display.
Page 22 from the new 17-inch PowerBook user manual.
As far as Apple's reference a 1920 x 1200 WUXGA display in the 17-inch PowerBook user manual, it could be a mistake or simply a misleading statement. But more likely, the manual references an undelivered display option that was planned with the last round of PowerBook G4 updates, but canned just prior to the product line update released earlier this month.
Typically, Apple chooses not to author its user-based product documentation far in advance of product releases, due to the potential for product specs and features to change throughout the course of product development. In its shroud of secrecy, the company also holds off publication of such documentation until the very last minute to avoid leaks to the media and public.
Meanwhile, other sources claim the new display option may be announced as a standard or configure-to-order option on an upcoming PowerBook "HD" model, which would bode with Steve Jobs' claim that 2005 will be the "year of high definition" ("HD").
[ View this article at AppleInsider.com ]
The main reason Apple was not introducing high-resolution displays on PB is user experience. Some time ago I recommended a notebook with high-resolution display to a friend and still feel sorry for that. The vast majority of everyday tasks are a real pain on such screen. You have to be a geek to convince yourself that this is a "good thing". Using a non-native resolution on LCD display is not a pleasure either. The other problem is that viewing a document at 100% on a high-res display does not tell you much about the actual size of the document and "actual size" becomes an abstract term.
Hopefully this will change in Tiger (and Longhorn for that matter). The key is Resolution Independent GUI (see my post above). It's implementation, however, is much more complicated than it may look. To have a sharp user controls the interface should be rendered to an "integer" number of pixels (I mean no antialiasing or 50% gray to represent "half" of a pixel - we already have this with non-native resolutions), and all adjacent objects should be perfectly aligned, so it will take some time before we have polished resolution independent user interface (remember PostScript printing on 300 dpi printers a decade ago, and this is still much better than current high-res displays). Integer scaling factors should not be a problem but this brings 1920 x 1200 to 960 x 600 equivalent...
An important thing to note is that scaling factor in Tiger can be applied on by-window basis so this gives the option for developers to offer different scaling for pallets, panes and document windows.
Think exposé. It can shrink a window and have it still operate. One could set a browser window to operate in a zoomed mode so pictures and text are more readable. Besides the browser the menu bar is the only other big thing that would need adjustability.
To tackle aps a new framework for aps could be intoduced that allow them to scale the text used in their aps. But that I don't think is such a big problem.
Hell if you think about it OS X is pretty much nearly resolution independednt right now. What can NOT be scaled up with a preference setting besides the menu bar?
I semi-understand it, as in if you have a higher resolution you don't sacrifice size, but get detail or something...
Is there not an article somewhere with images and such?
Originally posted by salmonstk
Perhaps resolution GUI is a surprise annoucement for Tiger.
Think exposé. It can shrink a window and have it still operate. One could set a browser window to operate in a zoomed mode so pictures and text are more readable. Besides the browser the menu bar is the only other big thing that would need adjustability.
To tackle aps a new framework for aps could be intoduced that allow them to scale the text used in their aps. But that I don't think is such a big problem.
Hell if you think about it OS X is pretty much nearly resolution independednt right now. What can NOT be scaled up with a preference setting besides the menu bar?
The problem is that most of the system's as well as the apps' UI elements are still bitmap graphics.
Makings the system's UI elements vector based is completely in Apple's hand, but it will take a little longer for the app developers to catch up.
It would be a total break and will take a transition period. I am curious about how Microsoft will tackle this issue because they also plan to introduce a vector based UI (an altered form of the SVG standard) with Longhorn - unless they recently dropped those plans.
SVG would be a great route to go, I think.
Originally posted by CrunchinJelly
Am I the only one who doesn't understand all this talk of a 'resolution-dependent GUI'?
I semi-understand it, as in if you have a higher resolution you don't sacrifice size, but get detail or something...
Is there not an article somewhere with images and such?
Rather than churning through the long explanation Amorph gave a while back, just click here to view his wonderful explanation.
Originally posted by Smircle
Not to be nitpicking, but OLED and LEP are one and the same - LEDs made of plastic forming the RGB subpixels of future flat panel displays. The technology is promising, but it still has some way to go, both technological and economical, before it can replace TFT in large (10" and above) panels.
LEP is a type of OLED but there are two different (the last time I checked) technologies - one uses small-molecule, vacuum evaporating particles (the typical OLED) where LEPs use large-molecule, inkjet-printed manufacturing processes that are much simpler (read: cheaper) to manufacture. Beyond that, some companies claim that the large-molecule based LEPs do not suffer from the shorter lifespan that OLED small-molecule displays do.
I for one would not want to see a 17" PB with a native-resolution above 1680x1050... anything more and, well, good luck using those new pixels properly...
Originally posted by Ben_K
What exactly is the point in getting all those extra pixels, if all you want to do is make the icons, text, and UI bigger? It negates the reason why you got the extra pixels in the first place...
I for one would not want to see a 17" PB with a native-resolution above 1680x1050... anything more and, well, good luck using those new pixels properly...
Resolution independence. See the link I posted above by Amorph. Basically, it is like a 300dpi printer versus a 600dpi printer. Same physical size display, just much sharper at higher resolutions. It takes the pixel out of the display measure.
Originally posted by Ben_K
What exactly is the point in getting all those extra pixels, if all you want to do is make the icons, text, and UI bigger? It negates the reason why you got the extra pixels in the first place...
I for one would not want to see a 17" PB with a native-resolution above 1680x1050... anything more and, well, good luck using those new pixels properly...
There is one more reason we need resolution independent display.
There are applications (games, kiosk applications etc. - mostly full screen stuff) which are designed for specific screen resolution. The "old style" for dealing with this was to switch the resolution while the application is running. This is OK for a CRT but we know what happens with the LCD when switched to a non-native resolution. As an extra credit we have more flexible user control.
But has anyone been thinking about the consequences this would have on websites? Fonts became res independent with HTML 4, but all graphics, with the exception of flash and svg, are res dependent.
Although it is possible, especially when using css, webdesigners have never used res independent graphics, partially because it renders ugly in IE (nearest neighbor scaling) but also because you need to use high res images resulting in longer download times.
I hope we get this long awaited transition in webdesign, but it might take a little longer than the transition of mac apps. In the meantime all the simeys will look ugly on your BTO hi-res PowerBook.
Originally posted by vroem
I'm also a big fan of a resolution independent UI. People are already talking about a transition period for mac software.
But has anyone been thinking about the consequences this would have on websites? Fonts became res independent with HTML 4, but all graphics, with the exception of flash and svg, are res dependent.
Although it is possible, especially when using css, webdesigners have never used res independent graphics, partially because it renders ugly in IE (nearest neighbor scaling) but also because you need to use high res images resulting in longer download times.
I hope we get this long awaited transition in webdesign, but it might take a little longer than the transition of mac apps. In the meantime all the simeys will look ugly on your BTO hi-res PowerBook.
I hope - and this is current reality in the developer preview - that resolution independance can be applied on a window by window basis by the developer.
And with the state of webdesign this is really necessary. A true separation of layout and content is hardly ever realised as most sites still use tables for their layout.
Another problem is pixel graphics that won't scale.
And most sites are designed for Windows and the IE and when style sheets are used, font sizes are declared in pt.
Imagine this in a resolution independant browser: scaled text, small graphics and a messed-up layout.
A solution would be to first render the pages at "old" ppi and then zooming in to match the resolution independance.
If you're screen is in the 72-100 DPI range, they'll be at 100% they're native resolution. If your screen is 133 DPI, they'll be "enlarged" to stay the same size. So relative to the rest of your screen, they'll be blurrier, but they'll be pretty much the same as they are now.
Photographs and most Aqua-ish interface items will look exactly the same as they do now The problem comes with the really tight, graphic-designy pixel-sized art and text other people were talking about. That'll just look kinda blurry.
I take that back. I just did a photoshop test of scaling something from 72 DPI to 133 DPI and back. It was blurry, but just a sharpen filter made the graphic design side look the same and the Aqua element look much better than the original. So, I say, bring resolution independence on.
Originally posted by RolandG
Imagine this in a resolution independant browser: scaled text, small graphics and a messed-up layout.
A solution would be to first render the pages at "old" ppi and then zooming in to match the resolution independance.
You are missing the point completely. You are describing the behaviour of the browser when you change the dpi in browser's preferences (that is, indirectly select different font size). In the resolution independent UI (at the later stage, when the user will be able to set scale factor) the developer should not bother whether the content is scaled or not. Even the methods which return information on applied transformations will ignore the UI scaling.
Currently the UI scaling will be control by the application (not by the user) but in any case it will be applied to the ENTIRE window. When the user control of the scaling is implemented (and I expect there will be a freeware/shareware/unsupported utility in place when Tiger ships) you may change on per user basis the scaling of everything, including the menu bar and window titles. On different res displays it may look like a 300dpi printer versus a 600dpi printer (see Rhumgod's post above).
Originally posted by shadow
You are missing the point completely. You are describing the behaviour of the browser when you change the dpi in browser's preferences (that is, indirectly select different font size). In the resolution independent UI (at the later stage, when the user will be able to set scale factor) the developer should not bother whether the content is scaled or not. Even the methods which return information on applied transformations will ignore the UI scaling.
Currently the UI scaling will be control by the application (not by the user) but in any case it will be applied to the ENTIRE window. When the user control of the scaling is implemented (and I expect there will be a freeware/shareware/unsupported utility in place when Tiger ships) you may change on per user basis the scaling of everything, including the menu bar and window titles. On different res displays it may look like a 300dpi printer versus a 600dpi printer (see Rhumgod's post above).
I am entirely aware of the fact that noone should bother about resolution (in)dependence once it is implemented. But some one has to implement it first!
The major obstacle I see is the Internet, the WWW specifically.
My solution describes a way for keeping compatibility with websites that were not designed with resolution independence in mind (i.e. 99,999999999% of all websites out there) for the reasons stated: mash-up of layout and content, mixture of absolute (mostly pixel-related: tables, bitmap images etc.) and relative (font sizes in pt etc.) settings.
What happens when a resolution independent browser renders a typical webpage is the following:
- the fonts will be blown up because they are meant to scale (measurements in pt)
- the graphics and tabels (measurements in pixels) will beome to small relative to the text
- thus the whole layout will be messed up
You can simulate this behavior today - as you correctly described - by pumping up the font size.
Since websites will be developed to be res-indepedent (all measurements being relative), the OS (or browser) will have to take care of it.
The easiest way is the one I described:
- scaling the absolute parts to match the resolution ratio set
UI scaling will be fairly easy to acomplish since it is almost completely in Apple's hands. Once they change the UI widgets to be vector based, all applications will adapt without the developers interaction.
The problem here are UI elements that are not OS inherent, e.g. bitmap icons for tool bar, paletts etc.
Apple introduced an obstacle to res-independence themselves with Dashboard. Since it will be Web-Kit based, they face the same problems as described above. No ture res-independence.
Originally posted by RolandG
- the fonts will be blown up because they are meant to scale (measurements in pt)
- the graphics and tabels (measurements in pixels) will beome to small relative to the text
- thus the whole layout will be messed up
Well, may be I am not good enough in explaining things but this is not the case.
I will try once more (others -help!)
1. Open a browser window containing text and images. If you can not switch to higher resolution make the window smaller so it does not resize during step 2 (resizing the browser window does cause reflow but this has nothing to do with res independent UI).
2. Switch the display mode from System Preferences: Displays to different resolution.
What happens? Does the image on your web page keep the previous size? Does the size of the text and image change differently?
Another try:
1. Open a browser window containing text and images.
2. Make a screen dump (Command-Shift-3).
3. Open the file Picture 1 found on your desktop in Photoshop. Set the view to 100%.
4. From Image - Image Size change the Resolution from 72 to, say, 144. Make sure the checkboxes "Constrain Proportions" and "Resample image" are checked. Press OK.
5. Set the View to 50% and compare with 3. Does the text reflow?
You are confused by the fact that in most applications you use display different units for text and drawing/image sizes. This is not the case in Quartz. You always use common measurement units there. Namely, all coordinates are described in points (using floating point numbers, not integer!). And here comes the only difference: until now (resolution dependent UI) we assume that 1 point = 1 pixel, 100 points = 100 pixels. With the arrival of resolution independent UI there is a scaling factor. If the scaling factor is 1.25 then 100 points = 125 pixels and YES, this is performed AFTER all content (text, graphics, user controls) are in place.
There are 2 major problems here:
1. The developers should check their old apps that they never assumed that 1 pixel = 1 point. For example if the developer places an 100x100 pixels image in a 100x100 points window with scale factor 1.25 the window (and the cached image) will be scaled to 125x125 pixels. Now, if the developer checks the size of the image using method (system call) which returns the number of pixels (hey, it used to be the same before!) he will get wrong result. He used the assumption that 1 pixel = 1 point.
2. The rendering quality. It is not an easy task to scale (bitmap) using non-integer multipliers without artifacts. Take the PostScript: it uses so called "hints" for the fonts (otlines/vector format) to make sure that the left and right stem of the letter "H" has the same number of pixels (simple rounding may not work and this will not look good on not-so-hi-res devices). It could be worse: Some letters may be "broken" just because some of the pixels happen to round to 0. If the view content is already in bitmap format the UI will not have information how to do with this except using antialiasing which blurs the image/text.
Originally posted by RolandG
- the fonts will be blown up because they are meant to scale (measurements in pt)
- the graphics and tabels (measurements in pixels) will beome to small relative to the text
- thus the whole layout will be messed up
Just one more try...
Download Opera and play with the View - Zoom menu. This will give you a good idea what happens. I am not aware of any other browser capable of zooming window contents. Forget Mozilla "resolution independence", it stands for "font size"!