Closed Bug 167962 Opened 23 years ago Closed 22 years ago

Chimera doesn't add a File Creator to saved JPEG's (=> problems in FileMaker)

Categories

(Camino Graveyard :: Downloading, enhancement)

Product:
Camino Graveyard
Component:
Downloading
Platform:
PowerPC
macOS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX
Milestone:
Camino1.0

People

(Reporter: stf, Assigned: jaas)

References

Details

After several tests from various sources, JPEG saved from Chimera (Build 0905 - OSX 10.1.5) are not recognized in FileMaker Pro 5.5, you are not able to select them. Make an Multimedia field and ask Insert Image from menu or Ctrl-click. It seems that during the save process something is not 'set' correctly. No matter the extension jpg, jpeg. GraphicConverter and Apple Preview open them correctly. I can't find why and I did not tried the other graphic file format.
over to dagley for a look, but i doubt this is really a problem.
Assignee: pinkerton → sdagley
Stephane, does FM open JPEG files saved from Mozilla or IE?
It could be that in Chimera we're not setting the type/creator metadata and FM may rely on that rather than the extension. Of course all good OS X apps should ignore the type/creator metadata and rely solely on file extension for filetype determination (rant on Apple's idiotic attitude on this subject deleted). Stephane, since I don't have FM Pro 5.5, can you try using a utility like XRay to ensure the downloaded JPEGs have a type of 'JPEG' and see if they then work? I doubt creator is important but you could use 'JVWR' if '????' doesn't work.
Mozilla save them correctly, finder info says CREATOR 'Preview' and for those saved with Chimera it says 'Unknown'. Please change it to 'Preview' as a default as everyone has that program. Filemaker opens without problem those saved from Mozilla.
If I save the JPEG without a .jpg or .jpeg extension, it's saved as a generic document. Is this what you're doing, Stephane?
Confirmed using Build 20021018 - OS X 10.1.5 Type and Creator are empty (or 4 blanks?) according to HexEdit. FileMaker does not recognize them with or without the .extensions.
Maybe what Chimera/Mozilla needs to do is still add the extension even if the user deletes it but set it as hidden. Don't some other applications do this?
Seems to me like a FileMaker problem. Apps shouldn't rely on type/creator codes alone in Mac OS X. It's the Apple policy of using the "lowest common denominator" to specify file types in various contexts, and generally that means using filename extensions (that can be hidden from the user).
It should not be too difficult to add the type/creator when the file is saved. If that makes life easier for everyone...
The problem is that Apple doesn't want developers using those any more, Stephane.
Re: Comment #10 From Greg Kolanek 2002-10-25 10:45 > The problem is that Apple doesn't want developers using those any more, > Stephane. They apparently aren't that certain about that strange policy either. After all, FileMaker is a subsidiary of Apple and thus should communicate well with them. The question of this bug is: do we want to stricly adhere to Apple's file extensions stupidity (we used to laugh about extensions, didn't we?), or do we want to add a Creator just for FileMaker (quite silly also).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Saved JPEG not recognized in FileMaker → Chimera doesn't add a File Creator to saved JPEG's (=> problems in FileMaker)
>The problem is that Apple doesn't want developers using >those [type/creator] any more, Stephane. I think the actual 'strategery' now is to leave creator blank to avoid binding documents to something other than a user's default application for that file type, but to fill in type where it makes sense to do so. IMO it always makes sense to do so. I believe these urls are current, but a lot of us are hoping there's some other master plan at work for the future other than "it was good enough for grandpa". http://developer.apple.com/techpubs/macosx/ReleaseNotes/FileExtensionGuidelines.html http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/ProgrammingTopics/Documents/Tasks/SavingHFSTypeCodes.html
Target Milestone: --- → Chimera0.8
*** Bug 189006 has been marked as a duplicate of this bug. ***
Sigh.
Assignee: sdagley → sfraser
Reporter could you update the status of this bug with a recent nightly ?
Confirmed in build 2003090102: no type nor creator is assigned to a saved JPEG image.
I don't think this is a bug, and I think it should be marked wontfix. Apple says they don't want the meta data used, and just because one application ignored that recommendation (Apple subsidiary or not) doesn't mean we have to support their bad habit. Lets get this off of the Camino 0.8 target list, or somebody please post a good reason to discuss this further.
As mentioned in comment 3, Apple's policy in this matter is, well, suboptimal (to put it politely.) Type/Creator codes should be authoritative, but if they are not present then filename extensions should be used to determine file types. Filemaker in this case is at fault for not looking at the extension, but that does not mean that Camino shouldn't set the type. The correct behaviour would be to set the creator code based on the MIME type. If the file is not of a known type, the user should be allowed to name it whatever they want; but if the type is known and the user deletes the extension, it should be put back on but hidden. (As mentioned in comment 12 and comment 7.) I'm not entirely sure what to do with the creator code. I think that not setting it or setting it to '????' should associate it with the default app for the file type. OTOH, Internet Config keeps a database of MIME type <-> type/creator code pairs, so perhaps the creator could be set according to this. The lack of a UI for this outside of IE is a major problem, however.
I get 2 things out of comment #18 and its suggestion to reread comment #3... 1. This is definitely FileMaker's problem not Camino's. 2. If all "good OS X apps" should ignore creator/type data, then lets go ahead and ignore it. Camino is a good OS X app right? :) What makes you think that the behavior in comment #18 is the correct behavior? Is there an Apple guideline for this? If so please post it and that will be the end of the debate. If not its just as much somebody wanting an unnecessary and against-guidelines fix as the guy that reported this not-bug. Its probably good that this got discussed for the sake of precedence though. And as for comment #7, that would mean Camino should go out of its way to do what the user specifically undid, which is usually a bad thing.See MS Word for examples ;-) I don't mean to sound too forward but I'm not seeing any solid arguments for fixing this not-bug.
The way things have been traditionally done on the Mac: <http://developer.apple.com/ documentation/mac/Toolbox/Toolbox-447.html>. The OS X compromise to be more compatible with systems with less capable file metadata (read: Windows): <http://developer.apple.com/documentation/ReleaseNotes/MacOSX/ FileExtensionGuidelines.html>. Personally I dislike the "reapply and hide the extension when the user deletes it" behaviour, but that's what the latter document specifies. Other selected quotes: "Applications may set an HFS file type for documents they create if they wish. The benefit is increased interoperability with Mac OS 9 applications." And Filemaker Pro as well. :) "Applications that are not a primary editor for documents of a given type should not set a creator code for those documents. The main example of this is an Internet browser that downloads files of many different types. In Mac OS X, users can associate applications with files of a given type using file name extensions. Browsers downloading files from the Internet should allow the user to choose which application to use to view those files by simply allowing the Finder to open them with the user's default application for that file type." So to conclude, by Apple's guidelines, Camino should 1. Set the HFS file type of downloaded files, 2. Not set the creator code, and 3. Do the reapplying/hiding thing with filename extensions. There's a whole section in the guidelines about how save dialogs should behave in regard to this last point.
Thanks for posting a clean argument with documentation. According to Apple's guidelines, your conclusion points 2 and 3 are the way things ought to be. Point one is not necessarily correct "by Apple's guidelines" as you stated - it is a point explicitly left open: "Applications may set an HFS file type for documents they create if they wish." Camino's current behavior is correct - "In Mac OS X, users can associate applications with files of a given type using file name extensions." The question is basically whether or not to spend time on supporting quirks (FileMaker) and maybe Mac OS Classic users. That should give this not-bug a low priority, and perhaps it should even be classified as an enhancement.
regardless, not an 0.8 issue
Target Milestone: Camino0.8 → Camino1.0
taking
Assignee: sfraser → josha
This is an enhancement since Camino's current behavior is correct by the specs.
Severity: normal → enhancement
I agree with Josh that it might be best to let the OS determine what app should be used to open the file by using the file extension. Especially since this would make sure the file would be opened using the setting the user made in the finder.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.