Opened 12 years ago
Closed 12 years ago
#8653 closed bug (fixed)
SVG files mistakenly marked as html file or text file
Reported by: | Giova84 | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Preferences/FileTypes | Version: | R1/Development |
Keywords: | svg file marked as html and text file | Cc: | |
Blocked By: | Blocking: | ||
Platform: | x86 |
Description
Every time that i download an SVG file on the disk (BFS) is marked as html file or as text file. So i have to set the proper mimetype from Add-ons > Filetype.
Attachments (3)
Change History (10)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
I have attached two files.. But here in browser are shown correctly (i'm using QupZilla).
comment:3 by , 12 years ago
Personally I don't think that file extensions work. Recognizer always use sniff rules. Mayble I am wrong.
Then will file be recognized by extension in theory?
comment:4 by , 12 years ago
Player.svg is identified as text/html because text/html SNIFF_RULE find a <!-- in the first 64 bytes and, unfortunatly, image/svg+xml don't have SNIFF_RULE saying if there is a <svg in the first ~512 bytes it's certainly a SVG file, not an html file at a 40% probability ;-)
comment:5 by , 12 years ago
And calendar.svg ends as text/plain maybe, indeed, the file extension is not working yet. Anyway, let's add this string attribute to your mime_beos/image/svg+xml:
attribute name:
META:SNIFF_RULE
type:
String
value:
0.60 [0:512] ( -i "<SVG" | "<!DOCTYPE SVG")
That will translate in append these lines to src/data/mime_beos/image/svg+xml:
+ resource(4, "META:SNIFF_RULE") #'CSTR' array { + "0.60 [0:512]( -i \"<SVG\" | \"<!DOCTYPE SVG\")" + };
comment:6 by , 12 years ago
My bad, seems 512 is too much for the sniffer parser. Should be:
0.60 [0:511] ( -i "<SVG" | "<!DOCTYPE SVG" )
And considering that we don't have SVG image translator yet, maybe it's also smarter to set Web+ as preferred application for SVG image instead of the supertype default, ShowImage:
+ resource(4, "META:SNIFF_RULE") #'CSTR' array { + "0.60 [0:511] ( -i \"<SVG\" | \"<!DOCTYPE SVG\" )" + }; + +resource(5, "META:PREF_APP") #'MSIG' "application/x-vnd.Haiku-WebPositive";
Our SVG mimerule don't have a sniff rule, which make text/html rule wins over if the SVG have a DOCTYPE tag.
Adding a SNIFF_RULE to image/svg+xml checking that an "<SVG" open tag is present in the first 1024 bytes for example should fix this.
I don't understand why it may be identified as a plain text file though: if the SVG file has an .svg[sz] extension at least, the current image/svg+xml MIME definition should wins.
Could you attach to this ticket samples SVG files that trigger either text/html or text/plain mis-identification? Thanks.