I’m generally appalled at the state of compound documents…
In the Apple world, Mac apps like Keynote love to use bundled directories which look like flat files at the UI level. Cute, but Thunderbird gleefully destroys them as attachments… Apple’s Mail.app transparently packages them into .zip archives for you, but Thunderbird just gives you a file with a directory listing, which naturally enough fails to open when you download it. Nice!
OpenOffice and the latest greatest MS Office stick their XML documents into a .zip archive and package image files, etc into that archive. These actually do act like flat files, so attachments and uploads work. :) But it makes file type detection and validation a little harder; verifying which file type your zip thingy is and whether it contains extra files slipped in…
And then you get fun packages like Scribus, which just give you an XML file referencing all your external image files by path, leaving no way to transfer your entire document without manually managing a directory structure and sending around or archiving multiple files manually.
We had a request for allowing Scribus uploads to Wikimedia sites for things like PR materials… sounds great, except for how any actually relevant document will need image files packed into the same directory which you can’t do. D’oh!
I’m putting together a talk proposal for SVG Open 2009, which will be in early October at the Google campus in Mountain View, CA.
I’ve got plenty of background I can pull in on the challenges and benefits of SVG on the web and the tradeoffs we’ve made in our usage and implementation, but I know lots of you folks out there have been more active on the ‘content-generation’ end of things and can point out some things I wouldn’t think of.
If anybody’s got any particularly interesting issues, examples, problems, or idea prototypes relating to usage of SVG on Wikipedia and other Wikimedia sites, I’d love to see how much I can pack in. :)
Pointers to cool feature proposals like Nikola’s localization presentation at Wikimania last year, or bulk anaylsis like benchmarks and compatibility tests on images in actual use would be of particular interest.
Preparing for the upcoming Wikimania in Buenos Aires, I’ve been attempting to practice my EspaÃ±ol in part by switching my computer’s user interface into Spanish.
OpenOffice 3.1 was released today, so of course I went and grabbed the Spanish-language Mac download and fired it up. Â¡Bueno! Except…. while editing a document, cmd+A brought up an “open” dialog instead of selecting all. Um?
Ok, “A” for “Abrir”, sounds good right? Except for the part where the entire rest of the operating system maintains the same keyboard shortcuts regardless of my language setting, and I would go completely mad if common shortcut keys randomly gave me different features in just one application.
A little googling turned up complaints about this sort of behavior going back years, but not a lot of good solutions. After some poking around, I did finally discover the configuration dialog for the keyboard shortcuts — under Tools/Customize… (Herramientas/Personalizar…) instead of, say, oh, in the preferences dialog.
I was able to — component by component — export the English keyboard settings to a file (saved conveniently with a “.*” extension) and — component by component — load my “customized” settings back up after relaunching in Spanish.
It seems to work now — cmd+A selects all, cmd+O brings up an open dialog — but it was a bit of a pain getting there. Let’s hope they don’t spontaneously revert…
Update: I’ve added a note on this to a bug on OOo’s bug tracker. Trying to track down some Spanish-speaking Windows users to check the standard platform behavior of Windows apps localized in Spanish… is Ctrl+A for Open and Ctrl+G for Save normal there?