On Sep 1, 2005, at 11:16 PM, Marco Ugolini wrote: In a message dated Thu, 01 Sep 2005 19:54:03, Roger Breton wrote:
So, this looks to me like the french _expression_ "two weights two measurements" (deux poids, deux mesures). What's going on Apple? Why are you *not* having problems with those profiles created under a foreign system that don't abide by your strict 32 characters file name convention?
In a message dated Thu, 1 Sep 2005 22:22:49, Roberto Michelena wrote:
I guess the reason could be that the profile creation software (in this case ProfileMaker) is Carbon, not Cocoa, and/or using file manager libraries created for OS 9. Thus at the time of profile creation is when the limitation arises.
Roberto's explanation is the one that makes the most sense, meaning that ProfileMaker is Carbon, not Cocoa, therefore bound by the file-name-length strictures of Mac OS 9.x (which begs the question: when are we going to see a fully Cocoa-ized ProfileMaker suite of products?).
By the way, you may already know this, but there is a workaround for the name-length limitation. Double-click a profile, which launches the ColorSync Utility. Select the 'desc' tag (#2), and in the box at the bottom of the window that reads "ASCII name," type away a whole poem's worth of type, if you wish (I haven't tried to see how many characters can go in there, but it's probably 255 at the very least). Then save the profile (File -> Save). Copy the new name, then assign it to the profile file in your directory. Your profile now will have the same long name, both internally and externally.
This renaming procedure can also be done in ColorThink 2.1.2, for those who have it. ColorThink has the added advantage of renaming the file with just one click, making sure that the external and internal name match. So far there has been a lot of groping around in the dark for the reasons behind the file-name limitation. Nathan Duran's post was almost certainly correct when he said that CMIterateColorSyncFolder() and, in particular, the FSSpec (a programming construct) might be the culprit. With that, I'd like to clear up a couple of points:
1. HFS+ allows for 255 character file names. 2. The Carbon/Cocoa dichotomy means absolutely nothing as far as support for long file names. The 31 character limit is inherited from old, pre OS8, days when the Finder would refuse to show more than 31 characters of a file name. Hence a lot of people just hard-coded the 31 character limit into their application code. This is wrong and should have been changed years ago. 3. Apple, ColorSync, Carbon, etc. are not to blame for GretagMacbeth's failure to provide long name support. It is only laziness on GretagMacbeth's part. 4. There are four ways for a programmer to specify a file. They are, ii. FSSpec which is basically: a number to specify the volume, a number to specify the parent directory, and a 63 character name. However, the 63 character name in the FSSpec is not the actual name if the name is longer than 31 characters. However, you can find the full 255 character name from an FSSpec, so this should not cause any problems. iii. FSRef which has undocumented internals, but which you can pass into lots of different functions and get all the information you could ever want about the file. iv. Aliases which are much like the programmer's version of the alias files you can make in the Finder. All of these ways of identifying a file are roughly equivalent and there is no excuse for not providing long name support when using any of them.
Given the horrendous hack of an interface that ProfileMaker has, I am not surprised that their programmers were too lazy to implement long name support. Nonetheless, for what it costs, there is no excuse for not supporting up to 255 character names.
Brendan Younger |