Can you name any other company that does it that way? I haven't.
I don't think the problem is the existence of the notice, mostly the excess of it in this case, making the complaint well founded.
What is the problem? What excess?
We've looked at the legal notices and there is one copy in one language basically for every individual application we've installed, including Adobe's Creative Suite. Updates have apparently wiped out or replaced a previous one as there are no duplicates.
However, our rules are straight forward, i.e., install applications in the APPLICATIONS folder. We insist that nobody move, remove or alter any folders or files that were part of the install. As a result, we seldom get, if any at all, the issues that others have complained about.
It is interesting that over the years, I have been responsible/director for literally thousands of machines/applications/systems for my clients and students. Invariably, most of the problems is due to laziness, not following basic instructions and worst of all dragging the primary apps and system utilities, plug-ins, registration files, etc., out of their respective folders or worse yet moving the primary application to the root level of their hard drive or even on the desktop. Cripes, I've had guys with duplicate and even triplicate copies of their applications, double systems, multiple registrations, etc., and they wonder why they are having problems.
As a developer of custom applications, I demand that that any alteration of the application's folder contents, including Legal Notices, Read Me's, etc., or are found not to reside where they were initially installed, voids the the warrantee. Any complaints? Nope. But then, they know where to come if their is a problem, and if any, they are virtually remedied immediately.
We've looked at the legal notices and there is one copy in one language basically for every individual application we've installed, including Adobe's Creative Suite. Updates have apparently wiped out or replaced a previous one as there are no duplicates.
You didn't say that before.
The person you replied to said they saw legal notices for as many as three dozen languages. I don't know if that changed or not, maybe you two have different versions of the same program.
The person you replied to said they saw legal notices for as many as three dozen languages. I don't know if that changed or not, maybe you two have different versions of the same program.
I have checked 8 machines in various locations. Same results.
Oh, and thanks. I used xSlimmer and things are rolling right along it seems. I also tend to only use my Mac for work stuff. No development, or anything "stressful". Is there a difference between the two apps? I will say that my system is much faster and snappier than before.
When I said xSlimmed, I mean an app that has been fixed by xSlimmer. Kind of like 'I Googled it'
Yes, hard drives are cheap. I'm more interested in the OS ability to manage memory, VM space and messaging to work without having the system lock up before I am about localization packages filling up a dumb device.
My guess is that the motivation for the Jenny Craig "Snow Leopard" update isn't the Mac Pro computers.
Apple likely has some flash-based OS X-running products in the pipeline that would most benefit from a general slimming down of the operating system. Something like a multi-touch enabled full-fledged OS X -running tablet.
My guess is that the motivation for the Jenny Craig "Snow Leopard" update isn't the Mac Pro computers.
Apple likely has some flash-based OS X-running products in the pipeline that would most benefit from a general slimming down of the operating system. Something like a multi-touch enabled full-fledged OS X -running tablet.
In the spirit of Jenny Craig we can have Bertinelli come on and describe the newfound slimness as states of being instead of honestly stating this once attractive women gorged, became a pig and suddenly realized I'd better get "energetic" once more or I'll be an old maid known for her Cats.
It has been suggested that moving to vector graphics for interface elements would do a lot to shrink apps, but I am incredibly irritated by lazy programmers that don't take the time to optimize the bitmap graphics they use.
If you open up any App package and poke around in its Contents/Resources there are likely to be plenty of tiff files for interface elements. A major one is often reserved for the About box. My gripe is that sometimes these tiff's are not even compressed (Yikes!) and that converting them to png or jpg can save a substantial amount. The nice thing is that the majority of apps I've been experimenting with still function transparently if you replace a given resource tiff file (XXX.tiff) by an identically named png file (XXX.png). Only in rare cases does the corresponding graphic disappear from the user interface (I suspect this means that the programmer has somehow specified a filename including the .tiff extension).
Case in point, since we're talking about the Mail app (I'm still on 10.4, where Mail.app weighed in only at 49 MB [sic]... no way that new features in Leopard justify even a doubling in size after putting it on the "designable.nib" diet):
I took the largest graphic inside Mail.app/Contents/Resources, called Mail_Large.tiff, of 168 KB. I opened it up in Preview, then saved as PNG, which dropped down the size to 120 KB, then put it through optipng, which further reduced the size to 116 KB, a 31% overall savings. After removing the .tiff from the application bundle, leaving the .png in its place, I relaunched Mail.app and checked in the Preferences/Accounts/Add account dialog box, and there you are, the same pretty graphic still graces the background.
Other large graphics can be sometimes even further reduced, for example if they use only a limited number of colors, yet have been mindlessly saved as a 32-bit uncompressed tiff.
Of course, not much can be gained on the gazillion tiff's that are smaller than the minimum file size on disk of 4k (on an HFS+ harddisk), yet they add up. I count some 260 in the top level of Mail.app/Contents/Resources alone (i.e. more than a meg!) plus some 4 that are 8 KB and that with optimization might drop below the 4 KB level.
Instead of wasting a huge amount of disk space a smart programmer could apply the same trick as savvy web programmers use to speed up web sites by combining several icons into a single "rollover" graphics file, only part of which is then shown at any time by applying some CSS magic. This speeds up websites by reducing the number of separate server requests for graphics files, plus a single large PNG or JPEG often compresses better than the same graphic split up into smaller ones. Similarly, copying out a small region representing an icon from a single optimized png or even jpeg file that represents a collection of all needed icons would save a huge amount of disk space and disk accesses for the elementary work of displaying the interface of an app. And as you know, disk accesses are still a huge speed bottleneck in computers....
If anyone at Apple is reading this, I strongly suggest they invest in making this as easy as using individual image files. After all, in the "old" Mac world, icons and other resources from the resource fork were all inside a single file as far as the file system was concerned, and therefore much more densely and efficiently packed than the current situation where each resource that an app uses, even if it is only a few bytes large, eats up at least one disk block. No wonder apps bloated hugely with the introduction of the bundle paradigm for applications.
I took the largest graphic inside Mail.app/Contents/Resources, called Mail_Large.tiff, of 168 KB. I opened it up in Preview, then saved as PNG, which dropped down the size to 120 KB, then put it through optipng, which further reduced the size to 116 KB, a 31% overall savings. After removing the .tiff from the application bundle, leaving the .png in its place, I relaunched Mail.app and checked in the Preferences/Accounts/Add account dialog box, and there you are, the same pretty graphic still graces the background.
After writing this post I experimented some further, because I only mentioned the possibility of replacing tiff's by png. For some larger photographic items, however, using jpg makes more sense, as any web programmer knows. The Mail_Large graphic uses transparency, which JPEG does not handle, so I did not consider it. However, JPEG2000 can also handle transparency, so I did a quickie test, replacing the png with a jp2 at 50% quality with transparency (conversion done by Preview, which uses the Quicktime code for JPEG2000 compression, which is far from the best implementation for high quality). Anyhu, KAZOOM, all of a sudden an originally 168 KB graphic has magically shrunk to 20 KB. And I cannot by eyeball power detect any quality degradation from the lossy compression. And indeed the "Add account" dialog box still happily displays the image in the background.
Another item of interest in this discussion is the use of sounds in an interface, in the case of Mail.app, 4 .aiff sounds for a total of 564 KB. Again, from my experience, sound files that are saved as uncompressed .aiff can be transparently replaced by .mp3's for a factor 8-20 gain in space and everything still "just works" thanks to the magic of CoreAudio, which apparently doesn't care what you feed it.
Comments
Can you name any other company that does it that way? I haven't.
I don't think the problem is the existence of the notice, mostly the excess of it in this case, making the complaint well founded.
What is the problem? What excess?
We've looked at the legal notices and there is one copy in one language basically for every individual application we've installed, including Adobe's Creative Suite. Updates have apparently wiped out or replaced a previous one as there are no duplicates.
However, our rules are straight forward, i.e., install applications in the APPLICATIONS folder. We insist that nobody move, remove or alter any folders or files that were part of the install. As a result, we seldom get, if any at all, the issues that others have complained about.
It is interesting that over the years, I have been responsible/director for literally thousands of machines/applications/systems for my clients and students. Invariably, most of the problems is due to laziness, not following basic instructions and worst of all dragging the primary apps and system utilities, plug-ins, registration files, etc., out of their respective folders or worse yet moving the primary application to the root level of their hard drive or even on the desktop. Cripes, I've had guys with duplicate and even triplicate copies of their applications, double systems, multiple registrations, etc., and they wonder why they are having problems.
As a developer of custom applications, I demand that that any alteration of the application's folder contents, including Legal Notices, Read Me's, etc., or are found not to reside where they were initially installed, voids the the warrantee. Any complaints? Nope. But then, they know where to come if their is a problem, and if any, they are virtually remedied immediately.
What is the problem? What excess?
We've looked at the legal notices and there is one copy in one language basically for every individual application we've installed, including Adobe's Creative Suite. Updates have apparently wiped out or replaced a previous one as there are no duplicates.
You didn't say that before.
The person you replied to said they saw legal notices for as many as three dozen languages. I don't know if that changed or not, maybe you two have different versions of the same program.
You didn't say that before.
The person you replied to said they saw legal notices for as many as three dozen languages. I don't know if that changed or not, maybe you two have different versions of the same program.
I have checked 8 machines in various locations. Same results.
How many do you have?
I have checked 8 machines in various locations. Same results.
How many do you have?
I only have one with Adobe software, that one program has "legal" with files in 17 different languages.
Oh, and thanks. I used xSlimmer and things are rolling right along it seems. I also tend to only use my Mac for work stuff. No development, or anything "stressful". Is there a difference between the two apps? I will say that my system is much faster and snappier than before.
When I said xSlimmed, I mean an app that has been fixed by xSlimmer. Kind of like 'I Googled it'
Safari = 11 MB
Mail = 11.3 MB
ical = 11.1 MB
and I am using LEOPARD!!!
The secret: just use monolingual to delete all unnecessary languages and then open terminal and type
find /Applications/ -depth -name ?designable.nib? -exec rm ?{}? \\; -print
to delete all designable.nib files on your computer.
backup first. use this command at your own risk.
Yes, hard drives are cheap. I'm more interested in the OS ability to manage memory, VM space and messaging to work without having the system lock up before I am about localization packages filling up a dumb device.
My guess is that the motivation for the Jenny Craig "Snow Leopard" update isn't the Mac Pro computers.
Apple likely has some flash-based OS X-running products in the pipeline that would most benefit from a general slimming down of the operating system. Something like a multi-touch enabled full-fledged OS X -running tablet.
My guess is that the motivation for the Jenny Craig "Snow Leopard" update isn't the Mac Pro computers.
Apple likely has some flash-based OS X-running products in the pipeline that would most benefit from a general slimming down of the operating system. Something like a multi-touch enabled full-fledged OS X -running tablet.
In the spirit of Jenny Craig we can have Bertinelli come on and describe the newfound slimness as states of being instead of honestly stating this once attractive women gorged, became a pig and suddenly realized I'd better get "energetic" once more or I'll be an old maid known for her Cats.
I have much less than advertised. Here is my numbers...
Safari = 11 MB
Mail = 11.3 MB
ical = 11.1 MB
and I am using LEOPARD!!!
The secret: just use monolingual to delete all unnecessary languages and then open terminal and type
find /Applications/ -depth -name ?designable.nib? -exec rm ?{}? \\; -print
to delete all designable.nib files on your computer.
backup first. use this command at your own risk.
That's the problem, it carries considerable risk, I would do that only after several other clean-up options are taken first.
If you open up any App package and poke around in its Contents/Resources there are likely to be plenty of tiff files for interface elements. A major one is often reserved for the About box. My gripe is that sometimes these tiff's are not even compressed (Yikes!) and that converting them to png or jpg can save a substantial amount. The nice thing is that the majority of apps I've been experimenting with still function transparently if you replace a given resource tiff file (XXX.tiff) by an identically named png file (XXX.png). Only in rare cases does the corresponding graphic disappear from the user interface (I suspect this means that the programmer has somehow specified a filename including the .tiff extension).
Case in point, since we're talking about the Mail app (I'm still on 10.4, where Mail.app weighed in only at 49 MB [sic]... no way that new features in Leopard justify even a doubling in size after putting it on the "designable.nib" diet):
I took the largest graphic inside Mail.app/Contents/Resources, called Mail_Large.tiff, of 168 KB. I opened it up in Preview, then saved as PNG, which dropped down the size to 120 KB, then put it through optipng, which further reduced the size to 116 KB, a 31% overall savings. After removing the .tiff from the application bundle, leaving the .png in its place, I relaunched Mail.app and checked in the Preferences/Accounts/Add account dialog box, and there you are, the same pretty graphic still graces the background.
Other large graphics can be sometimes even further reduced, for example if they use only a limited number of colors, yet have been mindlessly saved as a 32-bit uncompressed tiff.
Of course, not much can be gained on the gazillion tiff's that are smaller than the minimum file size on disk of 4k (on an HFS+ harddisk), yet they add up. I count some 260 in the top level of Mail.app/Contents/Resources alone (i.e. more than a meg!) plus some 4 that are 8 KB and that with optimization might drop below the 4 KB level.
Instead of wasting a huge amount of disk space a smart programmer could apply the same trick as savvy web programmers use to speed up web sites by combining several icons into a single "rollover" graphics file, only part of which is then shown at any time by applying some CSS magic. This speeds up websites by reducing the number of separate server requests for graphics files, plus a single large PNG or JPEG often compresses better than the same graphic split up into smaller ones. Similarly, copying out a small region representing an icon from a single optimized png or even jpeg file that represents a collection of all needed icons would save a huge amount of disk space and disk accesses for the elementary work of displaying the interface of an app. And as you know, disk accesses are still a huge speed bottleneck in computers....
If anyone at Apple is reading this, I strongly suggest they invest in making this as easy as using individual image files. After all, in the "old" Mac world, icons and other resources from the resource fork were all inside a single file as far as the file system was concerned, and therefore much more densely and efficiently packed than the current situation where each resource that an app uses, even if it is only a few bytes large, eats up at least one disk block. No wonder apps bloated hugely with the introduction of the bundle paradigm for applications.
Just my little gripe....
I took the largest graphic inside Mail.app/Contents/Resources, called Mail_Large.tiff, of 168 KB. I opened it up in Preview, then saved as PNG, which dropped down the size to 120 KB, then put it through optipng, which further reduced the size to 116 KB, a 31% overall savings. After removing the .tiff from the application bundle, leaving the .png in its place, I relaunched Mail.app and checked in the Preferences/Accounts/Add account dialog box, and there you are, the same pretty graphic still graces the background.
After writing this post I experimented some further, because I only mentioned the possibility of replacing tiff's by png. For some larger photographic items, however, using jpg makes more sense, as any web programmer knows. The Mail_Large graphic uses transparency, which JPEG does not handle, so I did not consider it. However, JPEG2000 can also handle transparency, so I did a quickie test, replacing the png with a jp2 at 50% quality with transparency (conversion done by Preview, which uses the Quicktime code for JPEG2000 compression, which is far from the best implementation for high quality). Anyhu, KAZOOM, all of a sudden an originally 168 KB graphic has magically shrunk to 20 KB. And I cannot by eyeball power detect any quality degradation from the lossy compression. And indeed the "Add account" dialog box still happily displays the image in the background.
Another item of interest in this discussion is the use of sounds in an interface, in the case of Mail.app, 4 .aiff sounds for a total of 564 KB. Again, from my experience, sound files that are saved as uncompressed .aiff can be transparently replaced by .mp3's for a factor 8-20 gain in space and everything still "just works" thanks to the magic of CoreAudio, which apparently doesn't care what you feed it.