[kman42]

Originally Posted by Don Pickett 

No it should not, and I set type for a living. There are times, especially when I'm reading a long document, that I want to cram as much text onto the screen as possible. Having 12 point type always be 12 point type limits the amount of text I can cram onto my screen. I don't want that limitation. It would be an absolute killer on a laptop screen. OS X is hungry for deskop real estate as it is.

No one is arguing that you shouldn't be able to set a zoom factor to cram as much on the screen as you want, just that when the zoom factor is 100%, it should actually be 100%.

Originally Posted by Don Pickett 

All of you need to pop a couple Xanax and go otuside for a while. It's the place with the sun and the trees and other people.

Where did that come from? What's with the insults coming out of the blue? I have only made one post in this thread and it certainly didn't merit a response like that.

kman

[TETENAL]

Originally Posted by OreoCookie 

Hence the paradigm shift from a pixel-based to a vector-based UI is a good thing

The Dock isn't vector based and it scales beautifully. I doubt Leopard will be vector based (at least not much more). I will probably just be larger bitmap images that are scaled down or multiple versions of bitmap images for each available scaling factor.

[OreoCookie]

Originally Posted by TETENAL 

The Dock isn't vector based and it scales beautifully. I doubt Leopard will be vector based (at least not much more). I will probably just be larger bitmap images that are scaled down or multiple versions of bitmap images for each available scaling factor.

The icons are bitmaps, yes. But they are scaled in a vector model with Quartz (which is pdf-based). Quartz has been vector-based from the very beginning. What isn't vector-based up to now (and probably will change in Leopard) is that the dialog boxes aren't scaled bitmaps, but scaled vector-based `drawings'. You won't have any problems scaling down (as with icons in the Dock), but you will have problems scaling up.

As you might imagine, drawing an Aqua button as a small bitmap is much easier (on the cpu) than drawing it using a vector-based description like you would in Illustrator. As far as I understand, Avalon underlies the same limitation: in principle, you can draw resolution-independent objects, but most UI elements are still resolution-dependent bitmaps. Hence zoomed interface parts still looked pixelated.

Does that clear up the confusion?

[TETENAL]

Nope. I think you are still confused.

First, you are right of course. Quartz has been built for resolution independence right from the beginning. Then you stop making sense though. Why do you single out dialog boxes? All windows are treated the same by the window manager. And windows and dialogs are defined in .nibs. Those aren't drawings, those are the numerical descriptions of origin and size of objects (amongst other things). So they have been "vector based" right from the beginning. And while you always were able to use PDF for button images (again right from the beginning in 10.0), I don't believe that Leopard will do this for most of its user interface elements. They will more likely provide bitmap images in multiple resolutions.

[OreoCookie]

I haven't singled out dialog boxes, they are merely one UI element among many. Perhaps Leopard will use several bitmaps of several sizes in Leopard to achieve resolution `independence' for buttons. I know how windows and dialogs are defined: you tell OS X to draw a button 5 pixel from the left margin, for instance. But the unit of measurement is pixel. This is where the important change will have to take place: you need to describe a window layout independently of the number of pixels. (Up until Tiger at least) nibs aren't vector-based, Quartz is.

I'm not sure why you find my explanation concerning the Dock confusing: just as you would scale bitmaps in Illustrator (or any other vector-based drawing app), you scale Dock icons down. As long as you stay below the native resolution, you will see little difference between a vector-based icon and a bitmap-based icon.

[P]

Originally Posted by JKT 

I'm not going to argue against this concept (though there are issues of usability in terms of being able to see e.g. your whole document and all your palettes etc on screen at the same time), but what I am curious to know is if this has actually ever been the case in the past. DG appears to be saying that it has, but for the life of me, I can't recall it being so (however, I didn't start using GUI computers regularly until the early nineties, and Macs until the early to mid-nineties, by which time screen resolutions and physical document sizes bore no relationship to each other).

If it hasn't been the case in the past, then RI is actually the first time it will be possible for the OS to do this entirely by default, no matter (CRTs notwithstanding) what monitor you have attached and what resolution you use.

It was the case in the past - the original 9" Macs for one thing. The computer could not read out the size of the display, but then most displays only supported one or a small number of resolutions back then. Provided that one of them - the main one - used 72 dpi (or really ppi, I suppose), the trick worked. For this reason, a 21" display was required to show 2 A4/US Letter pages side by side (19" if you didn't show the margins). When multisync displays arrived, people could set any resolution they wanted - for computer professionals that did not work in graphics, this was usually higher than 72 dpi. The system completely broke down when LCDs and their native resolutions broke the 72 dpi default.

RI will let us bring back this case as an option. Personally I'll zoom slightly out to fit more pixels on screen, but it will let graphics professionals work in the way that was intended.

[P]

Originally Posted by teszeract 

But on the whole, I am looking so forward to resolution-independence because as I get older (happy 40th to me), all those tiny tiny pull out arrows on pallettes is making my arm ache with hits and misses. Not to mention reduced productivity. Adobe, put your hand up.

The reason we sometimes have very small or very large icons is that the designer cannot know how big they will be on your display. OS X looked very big and clumsy on my old iMac G3 that only used a 15" display that maxed out at 1024*768. Note that this is not 72 dpi - the closest to that would be the default 800*600 mode - but not enough higher to offset the huge icons. Apple assumed that we all used a very high dpi. Presumably Adobe assumes that everyone is using 72 dpi (they should!) and designs their controls to that. If you use a higher resolution (most of us do, these days) they look tiny. RI can finally fix this - if designers assume that the interface is zoomed to 100% when designing.

[Fusion]

Sorry to go back to the original topic, but does anyone know if it will be possible with resolution independant Leopard to scale elements down?

I guess I'm one of the few who's looking forward to resolution independance not so I can scale things up for readability, or so I can scale things to be WYSIWYG, but rather, I'd like more screen real estate and would love to scale elements down.

I've always found Apple's UI a little chunky. 13px font for menu bar, etc.. is a bit too much. I'd love to scale all that down and give myself some more screen real estate.

[Dark Goob]

OreoCookie wrote:
> > >
I'm aware of that, gee. But up until recently, we didn't have the technology to do a resolution-independent interface. Hence, calling 1 pixel 1 pixel and not 1 point is accurate, identifying 1 pixel with 1 point (coz that used to work for 72 dpi displays) is not.
< < <

LOL the technology is not "recent;" it would have been possible 10 years ago with PostScript and TrueType fonts in OS 8, had the feature to recognize the monitor's physical size been programmed into the OS. It's just that it has taken us 10 years to finally update the OS in an intelligent manner, because we have been so busy with other things such as transitioning from 68XXX to PowerPC, and from OS 9 to OS X, and from PowerPC to Intel. Maybe now we can finally make the OS actually behave like it's supposed to, now that Steve's Noah's Ark has finally landed on stable ground (hopefully).

Even if the technology WAS recent, this does not lead one to the conclusion that one pixel is one pixel, since one pixel has always been one pixel, since the beginning of the pixel. And the fact that it's inaccurate to identify one pixel with one point has to do with not-so-recent technology (multi-scan monitors and then LCDs) -- it does not have to do with the recent innovations of resolution independent GUIs.

Further, ALL I have tried to argue this whole time, is that when I tell the computer (via a preferences dialog, font menu, or what have you) that a font should be 12-point, that the actual font showed on the screen should measure 12-points if one were to put a real life ruler up to the screen... whether we're talking about the fonts in a browser, in the Finder, or in a word processor.

> > >
You don't have to convince me of the fact that resolution-independent UIs are clearly superior, there is no disagreement here. Again, the technology for resolution-independent displays wasn't there! You need a vector-based (as opposed to pixel-based) UI for that. If the UI is pixel-based, then pixel is the natural unit, not point, not cm, not inch. Just try and change the font-size of a pixel-based UI for all the menus and dialogs (there is/used to be an option for that under Windows). It's a nightmare for an interface designer (who measures in pixels, I've dealt with that problem extensively).
< < <

Well, duh! I mean, at what point in this thread have I made any statements to lead you to believe I don't agree with this? I know that resolution-independent GUIs require vector rendering. For example, to render a 12-point font accurately on a computer screen would require (a) knowledge of the monitor's physical size, (b) knowledge of the monitor's current resolution, and (c) a vector font-rendering engine uses this knowledge to render "outline" fonts (aka vector-based fonts like PostScript or TrueType, as opposed to "bitmap" or "Screen" fonts) at the size they're supposed to be.

I have not been advocating a pixel-based or resolution-dependent interface this whole time. It's almost like when you read my posts, you get them totally backwards, and think I'm arguing the opposite of what I am.

> > >
Now, the technology is there and we can measure independently of pixels. But that's because we have a vector-based model of UI elements.
< < <

Yep. We finally got around to implementing it.

> > >
Note that I'm not saying Word and Illustrator, for instance, should measure font sizes in pixel, because that is an ill-defined unit of measurement; here you should use point, millimeter or inch.
< < <

So you ARE saying that some other aspects of the interface should still be measured in pixels?? Now you're really confusing me.

> > >
For pixel-based applications such as UI elements and websites, using pixel to specify font sizes makes sense; indeed, web designers are used to specify things in pixels (if they wish to), and you can specify font sizes in pixels.
< < <

Uh, yeah it makes sense if you're working in a resolution-dependent (pixel-based) interface. But what we're talking about here is going away from that sort of interface to one that does NOT use pixels to specify font sizes or interface elements. And good riddance to those that do! Because I'm tired of my so-called "12-point fonts" showing up on the screen at an unreadable 9-point in TextEdit! Tired of it!

> > >
It's not hard to understand, you've just misinterpreted what I've said. I'm a big fan of resolution-independent UIs and I see it as the only way to solve some of the issues consistently!
< < <

So then why did you say, in the previous sentence, "For pixel-based applications such as UI elements and websites, using pixel to specify font sizes makes sense"? Because that's not describing a resolution-independent interface; it's describing a resolution-dependent one.

> > >
I don't think there are any camps here. 12 points should be 12 points and 12 pixels shouldn't be confused with 12 points. Hence the paradigm shift from a pixel-based to a vector-based UI is a good thing
< < <

There ARE two camps here. There is one camp, which thinks that if (in the Finder) you set your display font to 12-point, then when you measure the "I" in "FILENAME" it should be 1/6" in size. Then there is you, who thinks that the Finder preference should just be changed to letting the user set the option to "12 pixel font", apparently. Which means you don't even really understand what a resolution-independent interface is.

-=DG=-

[OreoCookie]

Originally Posted by Dark Goob 

So you ARE saying that some other aspects of the interface should still be measured in pixels?? Now you're really confusing me.

No, I'm just talking about the current state of technology, i. e. pixel-based UIs and not resolution-independent UIs. Right now (i. e. before the release of Leopard), there is no real resolution-independent UI on the market and things are effectively measured in pixels (via the point-to-pixel@72 dpi paradigm). I don't say they should be measured in pixels, I'm saying they are measured in pixels. A matter-of-fact statement, nothing more, nothing less and not an opinion.

Originally Posted by Dark Goob 

So then why did you say, in the previous sentence, "For pixel-based applications such as UI elements and websites, using pixel to specify font sizes makes sense"? Because that's not describing a resolution-independent interface; it's describing a resolution-dependent one.

I'm describing the current state of affairs. If you've ever worked with css, for instance, you know that you can specify the size of divs or whatnot in pixels. I'm not describing a resolution-independent UI, I'm just saying how it is done now, it's not an opinion of mine.

Originally Posted by Dark Goob 

If we switch to resolution-independent descriptions, things have to change.
There ARE two camps here. There is one camp, which thinks that if (in the Finder) you set your display font to 12-point, then when you measure the "I" in "FILENAME" it should be 1/6" in size. Then there is you, who thinks that the Finder preference should just be changed to letting the user set the option to "12 pixel font", apparently. Which means you don't even really understand what a resolution-independent interface is.

No, this isn't at all what I've said. I'm saying that a long, long time ago, computer manufacturers have set points equal to pixel on computer displays (when it made sense), but stuck to calling a 12 pixel font `12 points' even for UI elements. The 12 pixel font is not an option, but a reality for many years.

For resolution-independent interfaces that should change, then point should be used again. I'm not arguing for an option for Leopard to set a `12 pixel font' for that wouldn't make any sense. I'm just talking about the current state of affairs (i. e. prior to the release of a resolution-independent UI).

I'm not sure why you are convinced that every time I start saying something, you immediately conclude (i) I'm talking about a resolution-independent UI and (ii) it's my opinion.

Would you mind using regular quote tags? Your posts are pretty hard to read.

[olePigeon]

Originally Posted by OreoCookie 

... perhaps also Vista, I'm not sure ...

Almost. Vista's UI breaks on high resolution screens.

[TETENAL]

Originally Posted by OreoCookie 

I'm saying that a long, long time ago, computer manufacturers have set points equal to pixel on computer displays (when it made sense), but stuck to calling a 12 pixel font `12 points' even for UI elements.

That's not quite true. "Computer manufacturers" didn't do that. Apple did. Microsoft didn't. Windows assumes a fixed display resolution of 96 dpi. Therefore when you ask for a 12 point font in Windows you will get a 16 pixels font on screen.

[Chuckit]

Originally Posted by olePigeon 

Almost. Vista's UI breaks on high resolution screens.

Still? I thought that was just in the beta.

[OreoCookie]

Originally Posted by TETENAL 

That's not quite true. "Computer manufacturers" didn't do that. Apple did. Microsoft didn't. Windows assumes a fixed display resolution of 96 dpi. Therefore when you ask for a 12 point font in Windows you will get a 16 pixels font on screen.

This just means MS uses a different conversion factor, but not a different principle. In older windows version (at least up until 2k, not sure about XP and Vista), you could even `measure' the dpi and tell Windows the resolution of your screen (you literally had to use a ruler). However, that didn't change the UI's font size (which you could do separately in points, but with all the expected problems).

[OreoCookie]

Originally Posted by olePigeon 

Almost. Vista's UI breaks on high resolution screens.

I see, thanks. I knew that Avalon is also vector-based, but I definitely had some doubts about resolution-independence … (if you dig deep enough, you can stilly find Windows 3.1-style and Windows 95-style dialogs )

The text clippings problem was the reason why practically no one was running Windows with non-standard font sizes (some dialogs were unusable then).

[besson3c]

Originally Posted by olePigeon 

Almost. Vista's UI breaks on high resolution screens.

The article you linked to was written in Aug. 2005.

[CaptainHaddock]

I've seen up-to-date Vista screenshots showing that Microsoft's flagship apps, like the new Office, are not vector-based, and look like crap at any resolution other than the default.

[krove]

You guys are arguing in circles about semantics, both wanting the same end result: resolution independence.

1. Mac OS has always wrongly associated pixel == point. Hence why 12 pt fonts do not show up as 1/6 inch, but rather 12 pixels on any display where the dpi != 72.

2. WYSIWYG does not mean EXACT size. It is a virtual, to scale representation of the final output. You can see the margins, you can see the images in the document, etc. While I hardly consider Wikipedia to be a definitive resource, they agree with Oreo that WYSIWYG does not have to mean explicitly to the same size as the final output.

3. Apple filed a patent for rendering resolution-independent bitmaps of UI elements using parts of CoreImage, where instead of storing really large bitmaps and scaling them as needed, or storing vectors (which don't always allow for some of the neat effects that can be made with the likes of Photoshop without resorting to a gazillion elements), it stores the representation of said element as a series of steps to build it like a Photoshop action, but it builds it at the size required by the DPI setting of the interface! If this summary has escaped you or you feel that I have totally mangled it, see here:
cabel.name: Apple's Next-Generation Themes

4. Number three solves the whole bitmap vs vector problem. Each has pros and cons but neither is really that great a solution for resolution-independent UIs.

[Fusion]

I don't think anyone saw my question so I'll try it again:

Sorry to go back to the original topic, but does anyone know if it will be possible with resolution independant Leopard to scale elements down?

I guess I'm one of the few who's looking forward to resolution independance not so I can scale things up for readability, or so I can scale things to be WYSIWYG, but rather, I'd like more screen real estate and would love to scale elements down.

I've always found Apple's UI a little chunky. 13px font for menu bar, etc.. is a bit too much. I'd love to scale all that down and give myself some more screen real estate

[Chuckit]

Originally Posted by Fusion 

I don't think anyone saw my question so I'll try it again:

Sorry to go back to the original topic, but does anyone know if it will be possible with resolution independant Leopard to scale elements down?

Again, nobody knows what the final interface will look like, but it seems pretty certain that if it allows you to scale the interface up, it will let you scale it down.

[JKT]

The RI UI in Tiger lets you scale down as well as up so, if Leopard builds on the semi-implementation in Tiger, it should do too. However, until someone breaks their NDA or uses a release version of Leopard... who knows?

[- - e r i k - -]

OK guys. I'm sorry to disappoint you, but it doesn't look like RI has moved very much from what we have already seen in Tiger:

http://www.erikveland.com/arkiv/images/ui/ir1.png
http://www.erikveland.com/arkiv/images/ui/ir2.png
http://www.erikveland.com/arkiv/images/ui/ir3.png
http://www.erikveland.com/arkiv/images/ui/ir4.png

Of note: Some UI controls are resolution independent, most are not. Implementation is still hideously buggy, with artifacting everywhere. Most applications even lack their 512x512 icons (readily apparent with coverflowing through the applications folder). I'm sure the latter will be fixed before release. Doubt we will truly see Leopard IR-ready at release though.

Curiously the window border of Safari got pixelated, but the Finder's didn't (in fact the rounded border didn't scale at all).

[MindFad]

That's interesting, the toolbar icon controls in Safari are looking nice. They almost look like they may be vectors. I really wasn't expecting that. Unless they're oversized bitmaps being scaled accordingly (like I predicted, creating bitmap icons 3-5 times their usual size would essentially "future proof" them for higher-res displays for years to come). Leopard does contain 512x512 icon resources now, right? Can you actually make them this big on the Desktop via View Options?

[Chuckit]

Originally Posted by - - e r i k - - 

OK guys. I'm sorry to disappoint you, but it doesn't look like RI has moved very much from what we have already seen in Tiger:

http://www.erikveland.com/arkiv/images/ui/ir1.png
http://www.erikveland.com/arkiv/images/ui/ir2.png
http://www.erikveland.com/arkiv/images/ui/ir3.png
http://www.erikveland.com/arkiv/images/ui/ir4.png

Of note: Some UI controls are resolution independent, most are not. Implementation is still hideously buggy, with artifacting everywhere. Most applications even lack their 512x512 icons (readily apparent with coverflowing through the applications folder). I'm sure the latter will be fixed before release. Doubt we will truly see Leopard IR-ready at release though.

Curiously the window border of Safari got pixelated, but the Finder's didn't (in fact the rounded border didn't scale at all).

I wonder if that's why it was pushed to October.

[- - e r i k - -]

Originally Posted by MindFad 

Leopard does contain 512x512 icon resources now, right? Can you actually make them this big on the Desktop via View Options?

Tiger also contains 512x512 icon resources. Not a whole lot of Software uses it though. AFAICT, Safari, Spaces, Exposé, Time Machine are among the very few that has it yet. (IE all the new apps).

The next time I have access to a Leopard machine, I'll check if you can make them that big just with the slider, but I doubt it. Big icons are regularly seen in Cover Flow, so there's a definite need for them. Software developers should take note.

[- - e r i k - -]

Oh, and just a note to confirm that zooming with universal access (weirdly enough I couldn't get ctrl-scrollwheel to work) does NOT take advantage of resolution independence. Not even scaling the mouse cursor

If Apple is really serious about resolution independence, it seems weird that they didn't create a large version of the Apple icon when they did the new one. It's the first thing you notice when you scale up the menu bar :/

[MindFad]

Originally Posted by - - e r i k - - 

Tiger also contains 512x512 icon resources. Not a whole lot of Software uses it though. AFAICT, Safari, Spaces, Exposé, Time Machine are among the very few that has it yet. (IE all the new apps).

Duh, I knew that. I meant "does it use them." Cool, though, I can't wait to see them all update with their 512x512s. I especially like the snazzy new Terminal icon.

The next time I have access to a Leopard machine, I'll check if you can make them that big just with the slider, but I doubt it. Big icons are regularly seen in Cover Flow, so there's a definite need for them. Software developers should take note.

Maybe 256x256 max on the Desktop. We'll see! And developers are definitely going to take note!

[- - e r i k - -]

Nope. Still only 128x128 on the desktop max.

Icons do grow bigger than that with putting up the resolution slider though.

[TETENAL]

Originally Posted by Fusion 

Sorry to go back to the original topic, but does anyone know if it will be possible with resolution independant Leopard to scale elements down?

http://www.erikveland.com/arkiv/images/ui/ir1.png

In the build Erik has, apparently you can not scale down.

[- - e r i k - -]

That is true. Quartz Debug only allows you to scale up.

[Chuckit]

Originally Posted by TETENAL 

http://www.erikveland.com/arkiv/images/ui/ir1.png

In the build Erik has, apparently you can not scale down.

Bear in mind, that is still Quartz Debug. It's not anything like an official UI.

[Dark Goob]

Originally Posted by krove 

2. WYSIWYG does not mean EXACT size. It is a virtual, to scale representation of the final output. You can see the margins, you can see the images in the document, etc. While I hardly consider Wikipedia to be a definitive resource, they agree with Oreo that WYSIWYG does not have to mean explicitly to the same size as the final output.

I stand by my statement earlier that the original idea of WYSIWYG is literally, "What you see is what you get." Not, "What you see is smaller than what you get." Hence, original Apple monitors like the Apple Two-Page Display which were (almost) the same size as 2 regular sheets of paper.

Now that technology has gotten as far as it has, there is no reason why the full meaning and potential of WYSIWYG should not be realized. I.e., that by default, things should be exactly the same size as they say they are.

Wikipedia is full of crap. Just read their article on esotericism. The editor-nazi's of Wikipedia favor "the popular meaning" of words, rather than actual meaning. I.e., they favor the current state of affairs, over the original intention. They favor the prevailing milieu, over the true best way. They favor the colloquial meaning, rather than the logical, literal meaning.

WYSIWYG has been bastardized and come to basically just mean WYSIPTYG -- What You See is Proportional To What You Get.

And don't tell me it's "just semantics," since in language, meaning is everything. I am all about having things mean what they say, and say what they mean. If you find my idealism impractical, then go switch to Windows or something. There you will find an OS populated by users who do neither demand simplicity nor common sense out of their OS, and who do not care if it does what it says, since they can just change the meaning of the words in their head to match what it is doing. Since hey, if it says it's WYSIWYG, then whatever it's doing must be WYSIWYG, especially since Wikipedia agrees!

-=DG=-

[himself]

Originally Posted by Dark Goob 

I stand by my statement earlier that the original idea of WYSIWYG is literally, "What you see is what you get." Not, "What you see is smaller than what you get." Hence, original Apple monitors like the Apple Two-Page Display which were (almost) the same size as 2 regular sheets of paper...

According to your definition, an application/document is WYSIWYG when, and only when, you are viewing a document at 100% and 100% scale on screen is exactly the same as a physical representation, because anything else is not a "literal representation." Scale it up or down at all, and it is no longer WYSIWYG. The problem is, your definition severely limits what WYSIWYG is meant to allow us to do: handle documents of any size and get an accurate representation at any scale we choose.

What happens if you're working on a Quark Xpress document on a Cinema Display, which (according to you) wouldn't be WYSIWYG, but then you simply attach a 72dpi display... is it then true WYSIWYG? Extending your argument further, we would never have true WYSIWYG unless our displays could exactly match the resolution of physical output, i.e. we have 1200dpi displays so we could proof our 1200dpi printouts with precision.

The software developers who made WYSIWYG possible knew about the limitations and the potential of the hardware and software, and part of the job of the software was to eliminate (or greatly reduce) the need to constantly measure and convert measurements. The computer does that for you. Why would I want or need to measure my screen to make sure it's virtual environment is precisely calibrated with my physical environment? If I have an element on a page that measures 9 picas on screen, and the printout is a literal 9 picas, the computer has done it's job, and I can trust what the display tells me. That is what WYSIWYG is meant to do.

[Chuckit]

If I take out a ruler and hold it up to the sky, the moon appears to be about 60 points wide. Is reality not WYSIWYG?

[JLL]

Originally Posted by MindFad 

That's interesting, the toolbar icon controls in Safari are looking nice. They almost look like they may be vectors.

For symbols In the black toolbar icons they use PDFs

[JLL]

Originally Posted by Chuckit 

I wonder if that's why it was pushed to October.

No, according to what Apple said at WWDC06 end users shouldn't expect see RI until the end of 2008 at the earliest.

[Chuckit]

Originally Posted by JLL 

No, according to what Apple said at WWDC06 end users shouldn't expect see RI until the end of 2008 at the earliest.

Oh, did he say end? I thought he said beginning.

[- - e r i k - -]

Originally Posted by JLL 

For symbols In the black toolbar icons they use PDFs

And some of them are vectors within those PDFs. Strangely not all, like the web-clipping icon for instance. You'd think that the latest additions would be the first to receive the vectorised treatment

[chabig]

Originally Posted by JLL 

No, according to what Apple said at WWDC06 end users shouldn't expect see RI until the end of 2008 at the earliest.

That just doesn't make any sense, since Leopard is coming out in October and will be resolution independent.

[Brass]

Originally Posted by Dark Goob 

I stand by my statement earlier that the original idea of WYSIWYG is literally, "What you see is what you get." Not, "What you see is smaller than what you get." Hence, original Apple monitors like the Apple Two-Page Display which were (almost) the same size as 2 regular sheets of paper.

-=DG=-

Well how about clipping? Does that mean that WYSIWYG does not include any clipped documents? So if a document is too big to fit on screen, it cannot possibly be shown is WYSIWYG, unless the printer is going to clip it the same way as the screen.

I really don't think you an apply WYSIWYG to scaling, unless you also apply it to clipping.

[- - e r i k - -]

Originally Posted by chabig 

That just doesn't make any sense, since Leopard is coming out in October and will be resolution independent.

In theory yes. In practice no. Just like Tiger really, except a few more elements have actually been vectorised this time around.

[JKT]

As erik says... Tiger already is Resolution Independent - it just isn't a flawless implementation.

In any case, the single biggest problem that Apple faces for a RI interface is third party developers. For e.g. Office - all the icons in Office will need to be recreated for the app to look any where near decent during RI usage. And when I say all, I mean all. That is no small task to undertake and given MSs record, it is not something they are likely to do as an upgrade to 2004. IOW, 90% of your apps are going to look awful under an RI interface until the developers have had the chance to upgrade and test their icons. Some shareware developers have released updates that do this, but not the majors - another example, would CS3 look any good under an RI interface?

[JLL]

Originally Posted by Chuckit 

Oh, did he say end? I thought he said beginning.

They said that developers had until the end of 2008 to get their apps RI ready.

I don't know if they updated that time frame this year.

[- - e r i k - -]

End-users likely won't see RI in action outside of Quartz Debug until the next major cat. But it's good to see that Apple is finally serious about getting it implemented in pressuring third party developers.

[solofx7]

I leopard and I can say that since I started this topic.
I do not really know what resolution independence is, but someone explained how mac and Microsoft render their fonts differently and that sorta answered the question for me.
I can say though that Leopard is a lot sharper and the fonts are sharper too.

[digital_dreamer]

Wow. You guys just don't get this stuff do you!

I've been in printing and publishing for some 25 years, before Macs appeared on the scene and we were using CompuGraphic phototypesetting equipment. We were familiar with what 9-pt type meant — it was and still is a unit of measurement that defines the physical size of the type. And, viewing anything at 100% scaling meant just that.

However, over the years, as the resolution capabilities of monitors increased and their physical sizes varied, the industry got away from that definition. Part of the reason is because most people were only concerned about the final printed page size, so they let it go. However, to say WYSIWYG only applies to the output page is BS. It doesn't just refer to the relative size and placement of elements on the page. It USED TO refer to the ACTUAL SIZE.
Today, it's a mess. We have typefaces defined in point sizes that have no barring on the actual size when viewed at 100%. We have viewing ratios expressed as percentages that have no meaning in real life. We have rulers that are only useful for output devices and relative measurements on screen.

With resolution independence, WYSIWYG has the potential to be EVERYTHING that it was once meant to be.

Originally Posted by himself 

According to your definition, an application/document is WYSIWYG when, and only when, you are viewing a document at 100% and 100% scale on screen is exactly the same as a physical representation, because anything else is not a "literal representation."

<sigh>. It should always be WYSIWYG. It shouldn't go in and out of WYSIWYG, depending on the scaling factor. If you are viewing the document at 100% of actual size, don't you think it should be 100% OF THE ACTUAL SIZE? " If you scale the document to 50%, it should be 50% OF THE ACTUAL SIZE. If you scale the document to 200%, it should be 200% OF THE ACTUAL SIZE. It can still be WYSIWYG, as long as the viewing percentage actually matches the real world physical representation. Otherwise, what's the point of using scaling percentage if the numbers are abstract, unpredictable, and bare no meaningful relationship to the document size?

Originally Posted by himself 

....Extending your argument further, we would never have true WYSIWYG unless our displays could exactly match the resolution of physical output, i.e. we have 1200dpi displays so we could proof our 1200dpi printouts with precision.

Eh? We are trying to get AWAY from resolution dependence. The 1200dpi resolution you are referring to applies to the output device resolution. We want 1" at 100% viewing size to mean 1" at 100% viewing size.

Originally Posted by himself 

...The software developers who made WYSIWYG possible knew about the limitations and the potential of the hardware and software, and part of the job of the software was to eliminate (or greatly reduce) the need to constantly measure and convert measurements. The computer does that for you. Why would I want or need to measure my screen to make sure it's virtual environment is precisely calibrated with my physical environment? If I have an element on a page that measures 9 picas on screen, and the printout is a literal 9 picas, the computer has done it's job, and I can trust what the display tells me. That is what WYSIWYG is meant to do.

Your point is only valid if what you get from your output device is all that you're concerned with. From the very beginning, and I remember this when we got our first Mac SEs at the newspaper, WYSIWYG meant what you see on the screen at 100% is what you get on the LaserWriter. If you viewed your QuarkXPress document at 100% and some elements looked too large for your taste, you KNEW it would look too large on the printed page. No if, ands, or buts. That was the beauty of WYSIWYG.
On screen zooming or viewing percentage has lost its real meaning today. It's only relative, and if you want the absolute figures, you have to calculate it based on your monitor resolution (the actual width of the horizontal and vertical scan lines) and physical size. The computer DOES NOT do it for you. Booo.

With resolution independence, WYSIWYG has the potential to be EVERYTHING that it's meant to be, once again.

Today, I still run into problems with clients who take the viewing percentage of the proofs we send them too literally. They look at their pdfs in Acrobat Reader at 100% and tell me document is too small. Really. I ask them what to look up Document Properties and tell me the Page Size. There it is. Then, they ask me why it looks smaller. Then, I ask them was resolution their monitor is set at. They say, "Eh?" I then have to explain that the size of the document on screen is dependent on their monitor size and resolution. They go, "eh?" Why should I have to explain this to them?
The pdf sent to the client is supposed to be a proof of the actual job. Some clients don't bother printing them and actually expect to measure the size of their logo on screen to see if it matches their specification. If their printer went down and they have the proof on screen, shouldn't they be able to view it at the actual size without the goofy, nerdy math only geeks care about? What's the point of having these units of measurements if soft-proofing at specified viewing percentages are meaningless?

Again, with resolution independence, WYSIWYG has the potential to be EVERYTHING that it's meant to be. I expect Apple to make it a reality, once again.

12 point type should be 12 point type when viewed at 100% of actual size.
Is there anyone who wants to continue to disagree with this point?

regards,
MAJ

[TETENAL]

Originally Posted by digital_dreamer 

Today, I still run into problems with clients who take the viewing percentage of the proofs we send them too literally. They look at their pdfs in Acrobat Reader at 100% and tell me document is too small. Really. I ask them what to look up Document Properties and tell me the Page Size. There it is. Then, they ask me why it looks smaller. Then, I ask them was resolution their monitor is set at. They say, "Eh?" I then have to explain that the size of the document on screen is dependent on their monitor size and resolution. They go, "eh?" Why should I have to explain this to them?
The pdf sent to the client is supposed to be a proof of the actual job. Some clients don't bother printing them and actually expect to measure the size of their logo on screen to see if it matches their specification. If their printer went down and they have the proof on screen, shouldn't they be able to view it at the actual size without the goofy, nerdy math only geeks care about? What's the point of having these units of measurements if soft-proofing at specified viewing percentages are meaningless?

Adobe Reader is actually one of the very few applications that can consider the screen resolution and zoom to real 100% of the physical document size. Usually it even reads the physical screen size and you don't have to measure something, but you can enter a custom PPI if your screen is not supporting telling the OS it's physical size.

The only problem is that this feature is off by default. I currently don't have Adobe Reader installed, but I used this feature before. So have a look into its preferences and find the checkbox, then next time your customers think they document is too small, make them turn on this feature.

[Chuckit]

Originally Posted by digital_dreamer 

Today, it's a mess. We have typefaces defined in point sizes that have no barring on the actual size when viewed at 100%.

I don't really see this as a grave problem. Like I pointed out before, a 56 pt character might appear to be a 9 pt character from the right distance — measurement is only possible if the measure and the thing being measured are equidistant. Therefore, the distance a character takes up on a ruler held up to the screen matters only if you assume the window is supposed to be perceived as being directly on the screen's surface rather than inside the screen.

[himself]

Originally Posted by digital_dreamer 

Wow. You guys just don't get this stuff do you!

I've been in printing and publishing for some 25 years, before Macs appeared on the scene and we were using CompuGraphic phototypesetting equipment. We were familiar with what 9-pt type meant...

I can agree that 100% on screen should be representative of 100% scale in the real world. That would be really nice. But it isn't necessary. The fact that these two environments don't match up exactly doesn't hamper my ability to accurately produce a layout that will be everything I expect it to be on output.

You're using a device (the screen) where the primary unit of measurement is the pixel to create for another medium with a totally different unit of measure (multiple units of measure, actually). Things won't always translate precisely, especially considering that the size of a pixel and the pitch between them varies between displays. Right now, 1px=1pt on a Macintosh display, regardless of resolution or pixel density. Some say that provides a great point of reference and allows for an accurate means of measurement, even if it isn't truly representative of scale. In a precisely proportional environment on a 150dpi display (as an example), 1pt would be equal to just over 2px. I can then imagine some will complain of how their 1pt rules look blurry (due to anti-aliasing) at 100%. The fact is, your current concept of WYSIWYG works perfectly on displays that are 72dpi or an exact multiple of 72dpi. Otherwise, objects measured in points will always be off on screen, and nothing will be true WYSIWYG (according to your definition) even in that case.

The point of WYSIWYG is not to provide an absolute precise 1-to-1 reproduction of a physical environment. If it does provide that, then that is great, but if it doesn't provide that, it doesn't disqualify it as being WYSIWYG. I'm not expecting WYSIWYG to fit the definition you have for it, because there are too many variables with hardware and software that have to be taken into account. When displays are 72dpi, your definition fits well, outside of that, your criteria for WYSIWYG will never be truly met.

[P]

WYSIWYG originally meant that what came out of the printer should look exactly like what you had on the display. That did indeed include the size - if you held up the printed document to the display, it should be the same size. Of course you can say that it's fine to use a scaled representation - after all, that's what we all do today - but that was not the meaning of the term, and to even have a decent claim to WYSIWYG, the user would have to know the scaling factor. Today, the user generally doesn't know the scaling factor to 100%, and the only hint is the margins if you decide to show them. To say that you look at the paper from different distances doesn't really hold up unless you have a steroscopic display.