You need to be logged in to post in the forums. If you do not have an account, please sign up first.
maff-supportPlease support maf!
maf is Mozilla Archive Format, but please keep on reading after this information!
The advantage of maf is that it is a simple zip-file with a different file extension. In this zip file is a folder in the root location for every tab that should be opened. In this folders is a index.htm-files (automatically named that way) each that will be opened.
This system is far better than mht, because everybody could unzip the maff file if his browser does not support maff.
28. March 2006, 03:44:46 (edited)
Of course I think we need a standardized zip archive spec first.
The idea that some of us had was:
1.) use zip format (with some extension not currently in use like maybe .owa for OpenWebArchive or something)
2.) No ini files or anything like that. Just load the index.ext file in the root of the archive
3.) It doesn't matter if the extension is html, .htm, .xhtml, .xhtm, .xml etc.
4.) If more than one index file is present, there'd be a priority order where .html would probably be first.
I've actually done all that via an external program/script. You set up a file association for the archive extension so that it loads with the program. The program extracts the content of the archive to the temp directory and loads the script in the default browser, which should be opera. To use it you have to create the archive yourself though as Opera can't do it. (The program isn't up anywhere. I'll have to dig it up from my old site backup if you want to mess with it. I really need to rewrite some directory handling for it though.)
5.) How and where the files in the archive are extracted/loaded, would be up to the browser. If Opera did it, I think maybe an archive subfolder in its cache could be used.
A note about #1:
Some would say that if the archive was allowed to be created with different formats like 7zip, rar, zip etc., it might be even better, but zip would be good enough and probably best.
28. March 2006, 13:02:45 (edited)
owa would be a great extension name as it is not program "specific" as maff is, allthough you could read Opera.
I know it's a bit utopic but it would be great if W3 or other "organisations" would create (in the long-term) a standard for saving wepages.
If someone is planning and realising this, it would be great if the code would be OpenSource so that many other browser could implement the routines as well.
At the moment I'll stick to my (self-created)-maff-files.
Originally posted by burnout426:
Some of us have discussed this before
<http://my.opera.com/community/forums/topic.dml?id=72718> was the thread. (The files I linked to in that thread are no longer there (was my old site). I have them on a backup CD somewhere. But, I could probably reimplement it faster than finding the CD.)
Edit: esp. after double-checking wikipedia and confirming that _nobody_ except mozilla uses MAFF but everybody else uses MHT.
MHT however belongs in the Hall of Shame of file formats. It is clunky and dysfunctional.
MAFF is highly elegant, I don't even need a browser to look at the contents, I very often use a plaintext viewer (that autostrips HTML tags) to view the index.html to copy a citation for discussion. I can extract the images. I can add note files of my own.
Mozilla currently makes up a very large proportion of userbase so it can be considered pretty universal. And there just isn't any point in re-inventing a proprietary wheel when an elegant wheel exists and is widely used.
Lack of proper archival support is the primary reason why I don't use Opera much these days. It was my main browser for over a decade.
1) mhtml is not proprietary, there is an rfc, namely http://tools.ietf.org/html/rfc2557
2) while its arguably not too awesome too read in plain text(because at least opera wraps all lines to 80 characters, not sure if thats in the standard) I dont really see the point of reading html in plaintext anyhow. apart from that it essentially looks like any other multi-part functionality like mtom or html-mail, so nothing too crazy or crufty imo.
3) firefox's market share is at 20% according to statcounter, other major browsers (which all support mht) are at >75%
So in short, MHT was there way earlier (the RFC is from '99), has a bigger supporting base and actually even plaintext reading after some parsing should be easier as you dont need to decompress anything (and yes, the format is way easy, so if you can remove html-tags you can strip away the other mht-syntax as well).
16. April 2013, 02:43:11 (edited)
Plaintext viewers are fast, browsers are slow, I usually just need to quote some reference text quickly.
MHTML is HUGE and stores images and files using space-wasting inline base64 encoding. An MHTML file is essentially an email with attachments, renamed to *.MHT. An ancient unhandy format. If it were great then MAFF would never have been created.
In MHTML I can not replace the images (science magazines usually display only thumbnails in article view so I manually replace them with full-res images afterwards). MAFF I can easily manipulate as I see fit. Extract images, replace images, add my own files that I want to keep together with the main document.
Compression-decompression is built-in and transparent in most file managers and OSes these days.
In fact it was pretty transparent already in Norton Commander under MSDOS in about 1993
"plaintext viewers are fast, browsers are slow" ... for startup/loading maybe (though also not really true on any semi-modern hardware), for interaction its a different story.
"MHTML [...] stores images and files using space-wasting inline base64 encoding" ... no disagreement there, though I dont remember when I last was worried about disk space (not to mention that many file-systems offer completely transparent compression).
"In MHTML I can not replace the images" ... true, but imo pretty much a corner case for normal use
"Compression-decompression is built-in and transparent in most file managers and OSes these days." except not quite, eg. when it comes to executables and so on. File-system level compression is much better in terms of transparency, but this is kinda off-topic
In any case, lets agree to disagree. Also I think this wish should better go to the Chromium/Blink bug tracker considering that both Opera and Chrome will switch to that engine in the near future and storage format support is probably part of core and not the UI http://code.google.com/p/chromium/issues/list