X-Mozilla-Status(2) explained :: Mozilla-Features :: Mozilla vs. Antivirus :: Mozilla-Links :: Mozilla-Applications
For quite some time it seemd I had lost my access password for the FxIF project on Google Code. Because of that it was nearly silent there which is particularly sad because of the commited users who filed issues there. No (November 2010) however I recovered my access and will put some work in resolving the issues and cheer it up a bit.
Thanks for your patience.
In August 2009 I got full maintainership for the extension FxIF from the original author Ted Mielczarek after he uploaded the code to a public repository on Google Code at http://code.google.com/p/fxif/ back in early 2008. Since his page it fairly outdated, I set this one up as homepage for FxIF (with his permission).
What’s it
FxIF (Firefox exIF) allows you to view meta information data contained in JPEG images from the convenience of your Firefox (or SeaMonkey or other compatible) browser. Most digital cameras add EXIF data to all images you take and much editing software adds or allows you to add more informations on the picture and you the creator.
FxIF is written in JavaScript and XUL, and as such should be portable to all platforms that Mozilla runs on.
Usage
After installing FxIF, simply right click on an image, then click Properties. The meta data will be displayed in the properties window. This integration into the existing dialog keeps the interface simple.
Since this window has been removed with Firefox 3.6 I’ve added my own one accessible through the EXIF data entry for those versions. Note: in the event of the Element-properties extension being installed, FxIF integrates itself there.
Doesn’t work?
I’d like my extension to work on your system as much as you do. Though sometimes it doesn’t work for you and for changing this I definitely need your help.
For trouble shooting I prefer e-Mail. What would be very helpful is where’s the problem exactly (no context menu entry?, no properties dialogue?, no data?, error message?), what other Add-ons you’ve installed, screenshot of the error, output from the Error Console and image you tried to get data from.
In detail
What can it display?
Meta data that’s contained in JPEG image files in three forms:
- binary EXIF data. This is added by most cameras automatically and contains technical informations on the camera model and manufacturer, date and time the image was taken, aperture and shutter speed used, focal length and much much more.
- IPTC-NAA data in a binary structure (IIM). IPTC-NAA comprises a standardized set of fields focusing on informations as the name of the photographer, caption and title for the image, copyright informations, keywords a.s.o.
- XMP (Extensible Metadata Platform). In contrast to aforementioned this data isn’t stored binary but as an XML document within the image and isn’t restricted to only camera or image informations but can hold both and even more. It’s developed by Adobe and pushed by their applications including Photoshop. As said, XMP can hold various informations as all the EXIF data mentioned above and also those from IPTC-NAA as well as application specific.
Its advantage is the use of UTF-8 encoding—so data can be added in every language available—and also the possibility to hold an information in more than one language simultaneously.
Out of the camera most images will only contain binary EXIF data but this may change in future and there’s much software for adding the other informations by you. And software like Photoshop will at least duplicate the EXIF information into XMP data and add data of its own to your image if you just save it—or at least if you don’t do Save for Web.
What does it look like?
Like I wrote, nothing fancy. Here are two pictures of it in action.
And which fields in detail?
In detail you can view the following EXIF fields: ImageDescription, Make, Model, Orientation, ModifyDate/DateTimeOriginal/DateTimeDigitized, Artist, Copyright, ExposureTime., FNumber, ExposureProgram, GPSInfo, ISO, ShutterSpeedValue, ExposureCompensation, MaxApertureValue, SubjectDistance, MeteringMode, LightSource, Flash, FocalLength, UserComment, ExifImageWidth, ExifImageLength, FocalPlaneXResolution, FocalPlaneResolutionUnit. ExposureMode, WhiteBalance, DigitalZoomRatio, FocalLengthIn35mmFormat, ColorSpace
Also following fields are taken from IPTC-NAA: By-line, Caption-Abstract, Headline, Instructions, CopyrightNotice, City, Sublocation, Province/State and Country
And the following from XMP: dc:Creator, photoshop:Headline, dc:title, dc:description, dc:rights, xmpRights:UsageTerms, cc:license, photoshop:City, Iptc4xmpCore:Location, photoshop:State, photoshop:Country, tiff:Make, tiff:Model, aux:Lens, exif:DateTimeOriginal, exif:DateTimeDigitized, exif:FNumber, exif:ApertureValue, exif:FocalLength, exif:FocalLengthIn35mmFilm, exif:SubjectDistance, exif:ExposureTime, exif:Flash, tiff:Orientation, exif:ExposureBiasValue, exif:WhiteBalance, exif:LightSource, exif:MeteringMode, exif:ExposureProgram, exif:ExposureIndex, exif:ExposureMode, exif:ISOSpeedRatings, exif:DigitalZoomRatio, exif:GPSAltitude, exif:GPSAltitudeRef, exif:GPSLatitude, exif:GPSLongitude, exif:ColorSpace, photoshop:ICCProfile, photoshop:Instructions, xap:CreatorTool, softwareAgent in mm:History
Additionally the JFIF comment field is interpreted.
That said, not all data is displayed always and at once. First not all files contain all fields. And second if fields that exist to hold the same information like the photographers name or description of the image are present in more than one structure, the information is only displayed once. The priority in which they’re used is XMP, IPTC-NAA, EXIF in descending order.
Also for your convenience if GPS coordinates are available in the EXIF fields, a weblink to a map provider is displayed behind them. At least it is in Firefox 3 and SeaMonkey 2 because earlier don’t support the technique used. And be aware that these are the coordinates of the camera, not the object photographed which can differ significantly especially for tele photos.
That’s not that much, why not more?
FxIF wants to give you the informations which most people most likely want to see when viewing an image in the browser. That is a quick look when, by which camera with which settings, where and some informations on the subject.
There are other applications that give you any possible information found in the image. But from our point of view their purpose is different and doesn’t make much sense in the browser. Displaying all informations available in the file can simply be overwhelming and makes the basic informations hard to find.
And why only in JPEG images?
That image format is by far the most common and concentrating on it keeps the extension simple.
Where is it supposed to run on?
As mentioned earlier it’s written in JavaScript and XUL, so it should run in combination with the GRE (Gecko Runtime Environment) everywhere GRE runs.
Out of the box the extension is made for the Firefox browser from version 0.10 on, the Mozilla Application suite from version 1.7 on and its successor SeaMonkey from version 1.0 on.
How much does it cost?
Nothing. It’s free software in terms of the Free Software Foundation. It’s triple licensed as MPL 1.1, GPL 2.0, LGPL 2.1 and like most extensions for the Mozilla platform comes with the source code in the XPI file itself.
Configure me
Since likings are different we decided to make two functions configurable. You can do this via the options dialog on the Add-on Manager (available in Firefox and SeaMonkey 2) or by directly manipulating the respective pref.
First option is to choose the format used for displaying coordinates. This is either Degrees Minutes (DM), Degrees Minutes Seconds (DMS) like 40° 43′ 20.7″ N, 74° 02′ 47.2″ W or decimal degree (DD) like 40.722417° N, 74.046444° W. Any informations are rounded to two decimal places in DM/DMS and six decimal places in DD format. The associated pref is extensions.fxif.gpsFormat where 0 means DMS, 2 DM, and 1 DD.
The other option is the map provider to use for the weblink. The default (when the pref isn’t available or empty) is to use openstreetmap.org, but as I wrote, likings are different.
So to change it, insert any URL into the field (or pref). You can use really any URL, but to have the respective coordinates used, put a %lat% anywhere the latitude shall be inserted and %lon% anywhere the longitude shall be inserted.
So the default is
http://www.openstreetmap.org/?mlat=%lat%&mlon=%lon%&layers=M
but if you want to use Google as a map provider, insert for example
http://maps.google.com/maps?ll=%lat%,%lon%&q=%lat%,%lon%&hl=%lang%
or for Yahoo use
http://maps.yahoo.com/#mvt=m&lat=%lat%&lon=%lon%
or
http://atlas.mapquest.com/maps/map.adp?searchtype=address&formtype=latlong&latlongtype=decimal&latitude=%lat%&longitude=%lon%
for MapQuest a.s.o. In URL langitude and longitude will always get inserted in unrounded decimal format.
Noticed the %lang% in the Google Maps URL? This is the third placeholder available and will be replaced by the content language code you’ve chosen in your general browser settings. It’s not necessary but at least in case of Google offers the site in your language.
You can also add another parameter which is “z=” for Google or “zoom=” for OpenStreetMap and Yahoo! if you don’t like the providers standard zoom setting. Simply write a zoom level after the equal sign (interesting levels should be around 15).
The associated pref is extensions.fxif.mapProvider.
Are there localized versions?
FxIF is already available in Brazilian Portuguese, simplified Chinese, Czech, Dutch, English, Finnish, French, German, Italian, Japanese, Polish, Russian, Spanish and Swedish. The one used depends on the browsers locale.
If you don’t find your language in the list, you’re welcome to do a translation and donate it. You can get the english version .dtd and .properties files from the FxIF repository and mail us the translated file for inclusion. Also fixes for errors in translations are welcome.
FxIF also has a page on BabelZilla.org where translations are organized. You can add translations there as well.
How do I get it?
You always find the current version of FxIF on addons.mozilla.org for SeaMonkey or for Firefox.
I’ve found a bug
That happens. You can send me a mail about it. Or add an issue on the Google Code project. I’ll look into it then.
When will the next version be released?
Like most projects “when it’s done”. Since 0.2.3 the FxIF code has its home at Google Code and the source kept online can be checked out via svn.
Version history
What’s new in 0.30
- Displaying of GPS coordinates
- Decoding of IPTC-NAA and XMP data
- Decoding of creator, title, description and copyright
- Ability to operate on images opened from mailbox, news and imap
- Also works with Firefox >= 3 and SeaMonkey >= 2
- Also works with images that aren’t cached.
What’s new in 0.3.1
- Also works in Firefox >= 3.6 where the properties dialogue has been removed.
What’s new in 0.3.2
- A few bugfixes, among them is “All toolbars disappear on closing print preview”.
What’s new in 0.4
- Added interpretation of EXIF values that are contained in XMP format rather the old binary format. Added some fields mainly regarding the location of the subject. Internally more fields are inspected to fill the license field.
- Also rearranged the order of the field listing, fixed some bugs in the XMP interpreter and the binary EXIF reader.
- Own EXIF window is now closable with ESC and the Copy button has an Alt+C (Option+C on Mac) shortcut.
- Can now cope with images delivered compressed (e.g. "Content-Encoding: gzip")
- Enabled overlaying of the properties window that’s being readded by Geoff Lankows Element properties
- Added new translation for Russian thanks to Max Pozdeev. All localizations have been overhauled, thanks to old and new contributors on BabelZilla.
What’s new in 0.4.1
- Only use DateTime if no DateTimeOriginal or DateTimeDigitized is available.
- Relaxed detection of XMP data a bit to work around a bug in some photo software.
- Not existing flash information in XMP data doesn’t cause fail of XMP evaluation anymore.
- Made evaluation of following data not fail if some error occurs. Instead a note is placed in the window that evaluation stopped and data shown might be incomplete.
- Fixed a bug where "chr" was used as language if intl.accept_language was left at the default for the browser. (Thanks to Hector Zhao)
- Added new translation for Dutch thanks to markh van BabelZilla.org.
What’s new in 0.4.2
- Flash data from XMP is now better evaluated (also as child values of the Flash tag instead only attributes of it). Thanks to Phil Lattimore for reporting.
- At least one software appends a null byte to the XMP document and the Mozilla XML parser doesn’t like this at all. I added a workaround for this case which shortens the document by one byte.
What’s new in 0.4.3
- Fixed some reads which were to optimistic on the bytes contained in a JPEG marker which could lead to negative byte counts tried to be read (and causing the stream reader to bail out). Thanks to Jemini for reporting.
- Fixed a bug preventing to catch and report it the aforementioned bug correctly to the user.
- Fixed Issue 4: ”Copy“ button does not copy GPS coords.
- Fixed Issue 5: EXIF tag Orientation with unknown value caused FxIF to bail out.
- Fixed Issue 6: Dates from binary EXIFs where copied verbatim containing colons as separators. These are now replaced by hyphens to match the date formatting for binary IPTC and XMP dates (YYYY-MM-DD as recommended in ISO 8601).
- Also dates comming from binary EXIF don’t carry timezone informations. This is now mentioned.
- Fixed Issue 8: Support for Degrees Minutes (DegMin) GPS format.
- Reworked flash data evaluation and strings on basis off a patch by Max Pozdeev.
- Added new translations for Swedish by Jan Kardell (via BabelZilla.org) and for Finnish by Ilari Oras (fixing Issue 9).
- Polish translation is not contained since newly added strings weren’t translated.
- Fixed Issue 10: Endless recursion if Exif Interoperability Offset or Exif Offset point to its own start offset. That’s an error in the data.
What’s new in 0.4.4
- Reading of informations about lens (from binary Exif, XMP data has already been read in the past) and used software.
- Dropping Support for the old Mozilla Suite. It’s dead for quite some time and no one should use it for his or her own good anymore anyway.
- At least in Gecko 2 (Firefox 4, SeaMonkey 2.1) the XML parser became picky about non-ASCII characters not correctly encoded as UTF-8 or Unicode. Some images do contain such documents which violate XMP specification (and actually XML specification too). I inserted a workaround which makes a second try after converting non-ASCII characters. This can lead to wrong display of such chars in buggy files, but they’re at least parsable this way.
- Ctrl+W, resp. Cmd+W now closes FxIF’s own dialogue (like Esc already does since version 0.4).
- FxIF’s own window now behaves like when the data is shown in the browsers own property window (resp. that of the Element-properties extension). I.e. it’s now possible to have multiple FxIF windows open in parallel instead reusing one.
- Improved IPTC date handling: If IPTC only contains either date or time, only use it if there’s no date already set.
- JFIF comments are now displayed
- Added new translation for Turkish thanks to contributor omrakin on BabelZilla and polish translation is included again.
What’s new in 0.4.5
- Fixed a bug which caused the browser to hang hard. Thanks to Radek Docekal for notifying.
- Fixed a bug which displayed a FxIF Data window with all fields but without any data. It was triggered by images using a
- If the mapProvider pref isn’t set, a default is used but wasn’t filled in the corresponding input field in the options. This is now done.
- Among the fields evaluated for the designation of the software used for creating the photo is the XMP field CreatorTool. When present it overwrote the value in the EXIF field Software. But CreatorTool only contains (at least following the specification) the software used for originally creating the photo, not the last version (like it should in the EXIF field Software).
So now also the field softwareAgent (in the History list) is evaluated and its last list entry is used for displaying the software. Also the field CreatorTool is only used if the EXIF field Software isn’t present.
- More lens information are read from Canon Maker Notes.
- A few bugfixes, among them is “All toolbars disappear on closing print preview”.
What’s new in 0.4
- Added interpretation of EXIF values that are contained in XMP format rather the old binary format. Added some fields mainly regarding the location of the subject. Internally more fields are inspected to fill the license field.
- Also rearranged the order of the field listing, fixed some bugs in the XMP interpreter and the binary EXIF reader.
- Own EXIF window is now closable with ESC and the Copy button has an Alt+C (Option+C on Mac) shortcut.
- Can now cope with images delivered compressed (e.g. "Content-Encoding: gzip")
- Enabled overlaying of the properties window that’s being readded by Geoff Lankows Element properties
- Added new translation for Russian thanks to Max Pozdeev. All localizations have been overhauled, thanks to old and new contributors on BabelZilla.
What’s new in 0.4.1
- Only use DateTime if no DateTimeOriginal or DateTimeDigitized is available.
- Relaxed detection of XMP data a bit to work around a bug in some photo software.
- Not existing flash information in XMP data doesn’t cause fail of XMP evaluation anymore.
- Made evaluation of following data not fail if some error occurs. Instead a note is placed in the window that evaluation stopped and data shown might be incomplete.
- Fixed a bug where "chr" was used as language if intl.accept_language was left at the default for the browser. (Thanks to Hector Zhao)
- Added new translation for Dutch thanks to markh van BabelZilla.org.
What’s new in 0.4.2
- Flash data from XMP is now better evaluated (also as child values of the Flash tag instead only attributes of it). Thanks to Phil Lattimore for reporting.
- At least one software appends a null byte to the XMP document and the Mozilla XML parser doesn’t like this at all. I added a workaround for this case which shortens the document by one byte.
What’s new in 0.4.3
- Fixed some reads which were to optimistic on the bytes contained in a JPEG marker which could lead to negative byte counts tried to be read (and causing the stream reader to bail out). Thanks to Jemini for reporting.
- Fixed a bug preventing to catch and report it the aforementioned bug correctly to the user.
- Fixed Issue 4: ”Copy“ button does not copy GPS coords.
- Fixed Issue 5: EXIF tag Orientation with unknown value caused FxIF to bail out.
- Fixed Issue 6: Dates from binary EXIFs where copied verbatim containing colons as separators. These are now replaced by hyphens to match the date formatting for binary IPTC and XMP dates (YYYY-MM-DD as recommended in ISO 8601).
- Also dates comming from binary EXIF don’t carry timezone informations. This is now mentioned.
- Fixed Issue 8: Support for Degrees Minutes (DegMin) GPS format.
- Reworked flash data evaluation and strings on basis off a patch by Max Pozdeev.
- Added new translations for Swedish by Jan Kardell (via BabelZilla.org) and for Finnish by Ilari Oras (fixing Issue 9).
- Polish translation is not contained since newly added strings weren’t translated.
- Fixed Issue 10: Endless recursion if Exif Interoperability Offset or Exif Offset point to its own start offset. That’s an error in the data.
What’s new in 0.4.4
- Reading of informations about lens (from binary Exif, XMP data has already been read in the past) and used software.
- Dropping Support for the old Mozilla Suite. It’s dead for quite some time and no one should use it for his or her own good anymore anyway.
- At least in Gecko 2 (Firefox 4, SeaMonkey 2.1) the XML parser became picky about non-ASCII characters not correctly encoded as UTF-8 or Unicode. Some images do contain such documents which violate XMP specification (and actually XML specification too). I inserted a workaround which makes a second try after converting non-ASCII characters. This can lead to wrong display of such chars in buggy files, but they’re at least parsable this way.
- Ctrl+W, resp. Cmd+W now closes FxIF’s own dialogue (like Esc already does since version 0.4).
- FxIF’s own window now behaves like when the data is shown in the browsers own property window (resp. that of the Element-properties extension). I.e. it’s now possible to have multiple FxIF windows open in parallel instead reusing one.
- Improved IPTC date handling: If IPTC only contains either date or time, only use it if there’s no date already set.
- JFIF comments are now displayed
- Added new translation for Turkish thanks to contributor omrakin on BabelZilla and polish translation is included again.
What’s new in 0.4.5
- Fixed a bug which caused the browser to hang hard. Thanks to Radek Docekal for notifying.
- Fixed a bug which displayed a FxIF Data window with all fields but without any data. It was triggered by images using a
- If the mapProvider pref isn’t set, a default is used but wasn’t filled in the corresponding input field in the options. This is now done.
- Among the fields evaluated for the designation of the software used for creating the photo is the XMP field CreatorTool. When present it overwrote the value in the EXIF field Software. But CreatorTool only contains (at least following the specification) the software used for originally creating the photo, not the last version (like it should in the EXIF field Software).
So now also the field softwareAgent (in the History list) is evaluated and its last list entry is used for displaying the software. Also the field CreatorTool is only used if the EXIF field Software isn’t present.
- More lens information are read from Canon Maker Notes.
- Only use DateTime if no DateTimeOriginal or DateTimeDigitized is available.
- Relaxed detection of XMP data a bit to work around a bug in some photo software.
- Not existing flash information in XMP data doesn’t cause fail of XMP evaluation anymore.
- Made evaluation of following data not fail if some error occurs. Instead a note is placed in the window that evaluation stopped and data shown might be incomplete.
- Fixed a bug where "chr" was used as language if intl.accept_language was left at the default for the browser. (Thanks to Hector Zhao)
- Added new translation for Dutch thanks to markh van BabelZilla.org.
What’s new in 0.4.2
- Flash data from XMP is now better evaluated (also as child values of the Flash tag instead only attributes of it). Thanks to Phil Lattimore for reporting.
- At least one software appends a null byte to the XMP document and the Mozilla XML parser doesn’t like this at all. I added a workaround for this case which shortens the document by one byte.
What’s new in 0.4.3
- Fixed some reads which were to optimistic on the bytes contained in a JPEG marker which could lead to negative byte counts tried to be read (and causing the stream reader to bail out). Thanks to Jemini for reporting.
- Fixed a bug preventing to catch and report it the aforementioned bug correctly to the user.
- Fixed Issue 4: ”Copy“ button does not copy GPS coords.
- Fixed Issue 5: EXIF tag Orientation with unknown value caused FxIF to bail out.
- Fixed Issue 6: Dates from binary EXIFs where copied verbatim containing colons as separators. These are now replaced by hyphens to match the date formatting for binary IPTC and XMP dates (YYYY-MM-DD as recommended in ISO 8601).
- Also dates comming from binary EXIF don’t carry timezone informations. This is now mentioned.
- Fixed Issue 8: Support for Degrees Minutes (DegMin) GPS format.
- Reworked flash data evaluation and strings on basis off a patch by Max Pozdeev.
- Added new translations for Swedish by Jan Kardell (via BabelZilla.org) and for Finnish by Ilari Oras (fixing Issue 9).
- Polish translation is not contained since newly added strings weren’t translated.
- Fixed Issue 10: Endless recursion if Exif Interoperability Offset or Exif Offset point to its own start offset. That’s an error in the data.
What’s new in 0.4.4
- Reading of informations about lens (from binary Exif, XMP data has already been read in the past) and used software.
- Dropping Support for the old Mozilla Suite. It’s dead for quite some time and no one should use it for his or her own good anymore anyway.
- At least in Gecko 2 (Firefox 4, SeaMonkey 2.1) the XML parser became picky about non-ASCII characters not correctly encoded as UTF-8 or Unicode. Some images do contain such documents which violate XMP specification (and actually XML specification too). I inserted a workaround which makes a second try after converting non-ASCII characters. This can lead to wrong display of such chars in buggy files, but they’re at least parsable this way.
- Ctrl+W, resp. Cmd+W now closes FxIF’s own dialogue (like Esc already does since version 0.4).
- FxIF’s own window now behaves like when the data is shown in the browsers own property window (resp. that of the Element-properties extension). I.e. it’s now possible to have multiple FxIF windows open in parallel instead reusing one.
- Improved IPTC date handling: If IPTC only contains either date or time, only use it if there’s no date already set.
- JFIF comments are now displayed
- Added new translation for Turkish thanks to contributor omrakin on BabelZilla and polish translation is included again.
What’s new in 0.4.5
- Fixed a bug which caused the browser to hang hard. Thanks to Radek Docekal for notifying.
- Fixed a bug which displayed a FxIF Data window with all fields but without any data. It was triggered by images using a
- If the mapProvider pref isn’t set, a default is used but wasn’t filled in the corresponding input field in the options. This is now done.
- Among the fields evaluated for the designation of the software used for creating the photo is the XMP field CreatorTool. When present it overwrote the value in the EXIF field Software. But CreatorTool only contains (at least following the specification) the software used for originally creating the photo, not the last version (like it should in the EXIF field Software).
So now also the field softwareAgent (in the History list) is evaluated and its last list entry is used for displaying the software. Also the field CreatorTool is only used if the EXIF field Software isn’t present.
- More lens information are read from Canon Maker Notes.
- Fixed some reads which were to optimistic on the bytes contained in a JPEG marker which could lead to negative byte counts tried to be read (and causing the stream reader to bail out). Thanks to Jemini for reporting.
- Fixed a bug preventing to catch and report it the aforementioned bug correctly to the user.
- Fixed Issue 4: ”Copy“ button does not copy GPS coords.
- Fixed Issue 5: EXIF tag Orientation with unknown value caused FxIF to bail out.
- Fixed Issue 6: Dates from binary EXIFs where copied verbatim containing colons as separators. These are now replaced by hyphens to match the date formatting for binary IPTC and XMP dates (YYYY-MM-DD as recommended in ISO 8601).
- Also dates comming from binary EXIF don’t carry timezone informations. This is now mentioned.
- Fixed Issue 8: Support for Degrees Minutes (DegMin) GPS format.
- Reworked flash data evaluation and strings on basis off a patch by Max Pozdeev.
- Added new translations for Swedish by Jan Kardell (via BabelZilla.org) and for Finnish by Ilari Oras (fixing Issue 9).
- Polish translation is not contained since newly added strings weren’t translated.
- Fixed Issue 10: Endless recursion if Exif Interoperability Offset or Exif Offset point to its own start offset. That’s an error in the data.
What’s new in 0.4.4
- Reading of informations about lens (from binary Exif, XMP data has already been read in the past) and used software.
- Dropping Support for the old Mozilla Suite. It’s dead for quite some time and no one should use it for his or her own good anymore anyway.
- At least in Gecko 2 (Firefox 4, SeaMonkey 2.1) the XML parser became picky about non-ASCII characters not correctly encoded as UTF-8 or Unicode. Some images do contain such documents which violate XMP specification (and actually XML specification too). I inserted a workaround which makes a second try after converting non-ASCII characters. This can lead to wrong display of such chars in buggy files, but they’re at least parsable this way.
- Ctrl+W, resp. Cmd+W now closes FxIF’s own dialogue (like Esc already does since version 0.4).
- FxIF’s own window now behaves like when the data is shown in the browsers own property window (resp. that of the Element-properties extension). I.e. it’s now possible to have multiple FxIF windows open in parallel instead reusing one.
- Improved IPTC date handling: If IPTC only contains either date or time, only use it if there’s no date already set.
- JFIF comments are now displayed
- Added new translation for Turkish thanks to contributor omrakin on BabelZilla and polish translation is included again.
What’s new in 0.4.5
- Fixed a bug which caused the browser to hang hard. Thanks to Radek Docekal for notifying.
- Fixed a bug which displayed a FxIF Data window with all fields but without any data. It was triggered by images using a
- If the mapProvider pref isn’t set, a default is used but wasn’t filled in the corresponding input field in the options. This is now done.
- Among the fields evaluated for the designation of the software used for creating the photo is the XMP field CreatorTool. When present it overwrote the value in the EXIF field Software. But CreatorTool only contains (at least following the specification) the software used for originally creating the photo, not the last version (like it should in the EXIF field Software).
So now also the field softwareAgent (in the History list) is evaluated and its last list entry is used for displaying the software. Also the field CreatorTool is only used if the EXIF field Software isn’t present. - More lens information are read from Canon Maker Notes.