OmegaT and Snow Leopard
(anti-aliasing problem - solved)

I was surprised to see a bad lack of anti-aliasing (font smoothing) when I ran OmegaT 2.0 for the first time in Snow Leopard.

Work from English was possible, but from Japanese... Forget it !

The problem occurred in the Editor pane of OmegaT, not in the Matches or Glossary panes, and I suspected recent developments in the Editor to be the cause of the problem since OmegaT 1.8 did not show this issue.

After searching for information, a Java engineer at Apple who happens to monitor the Mac Java-dev list told me that the new Java 6 anti-aliasing default on OSX was probably the cause of the problem. He suggested to either add a line in the code, or to change the default value directly from the command line.

A brief exchange with the OmegaT developers concluded that the command line was the best approach especially since command line parameters could be hard coded in the Mac bundle.

The next release of OmegaT 2.0 will happen in a few days and the Mac package will include the font-smoothing parameter.

In the meanwhile, Mac users who work with the standard OmegaT package (the one that comes with the file OmegaT.jar) can start OmegaT from the command line with the following parameter:

$ java"true" -jar OmegaT.jar

Users of the Mac package (the file) can modify it so that it is launched with the correct parameters:

  • right-click on and select Show Package Contents

  • find the info.plist file within the Contents folder and open it with your favorite text editor

  • replace the following code:


  • with:


  • save the file, close the Contents folder, and relaunch

The two solutions are equivalent and should transmit the correct property to the system when you use OmegaT.
(Special thanks to Mike Swingler at Apple.)

Okapi new version

In case that had escaped you:


Hello everyone,

We are happy to announce the milestone 3 of the Okapi Framework for Java.

To try to make things easier there are now two main distributions:

=== okapi-lib (for developers):

--> This distribution includes the libraries, documentation and examples you would need to use the Okapi Framework with your programs. It also include Tikal, a command-line tool to do basic task like simple extract and merge. This distribution is not UI dependent and therefore the same for all platforms.

=== okapi-apps (for users and developers): <-- The one you are likely to want

--> This distribution is the same as okapi-lib (minus the developers documentation). And in addition, it includes the UI-dependent components of the framework, as well as Rainbow (Localization Toolbox) and Ratel (SRX Editor). Because the UI depends on each platform, there are different flavors of this distribution: Windows, Linux (32-bit and 64-bit), and Macintosh (Carbon and now Cocoa).

All this can be downloaded from Okapi's main Web site:,

as well as from the Google-Code project's site:

A large part of the work done for this milestone is not visible: We moved the build structure to Maven, so we can develop using continuous integration more efficiently. Ultimately it should make the framework more robust and better tested.

We did managed to work on a few visible changes too :) Here are some of them:

=== The first version of Tikal in Java has been implemented. This tool allows you to perform simple tasks from the command-line. For example:

C:/Tmp>tikal -x *.docx *.html -sl EN -tl FR

will extract to XLIFF all the DOCX and HTML files in the Tmp directory.

C:/Tmp>tikal -m *.xlf -sl EN -tl FR

will merge them back into their respective formats.

For more information on Tikal, see

=== Various bugs have been fixed in several filters (thanks for the bugs reports) and some improvements have been implemented in others.

=== There is a new filter for Qt TS files.

=== Cocoa support has been added for the Macintosh.

=== There is a new TM connector to query Translate Toolkit TM servers. You can try it using Tikal. For example, if you have a local server running on port 8080, the command:

C:/>tikal -q "open file" -tt localhost:8080 -sl EN -tl FR

will get the matches for "open file" in that TM.

=== As usual, a more complete list of the main changes can be seen in the changes.html document that comes with the distribution.

Bug reports and enhancement or features requests can be posted here:

-the Okapi Team

<end quote>

Snow Leopard

I've only used it for a few hours but here are the first things I found:

1) Default Java version is Java 1.6, and OmegaT seems to have issues with that. It works but there is an issue with the font selection that is not respected in the Editor window.

2) The input method can be set to stick to a document. For ex, you can have a TextEdit document that uses Kotoeri, another that uses US and changing of document will not change the input method. That's an improvement over the situation in Tiger where, if I remember well, the input method was "attached" to the application but not to the document.

3) The old option "multilingual spellchecking" can use a subset of the available languages. That way, you can more efficiently check the spelling without changing the language in the spellchecker interface every time a paragraph uses a different language.

4) The spellchecker can also automatically correct your mistakes.

5) The services are indeed much better integrated to the workflow. A right click on an element (text, image etc) will trigger a contextual menu that shows possible services for that element.

Calculator bug ?

This bug seems to have been fixed in Snow Leopard.

My bug report to Apple:

Calculator does not accept "." input after conversion from the "Convert" menu.

Steps to reproduce:
1- enter a value with a decimal point, the decimal point can be entered either from the keyboard or from the the Calculator UI.
2- select any conversion from the Convert menu
3- the conversion result is displayed
4- enter a value with a decimal point again

Expected result:
The new value should have a decimal point in the location where it has been input

Actual result:
The decimal point cannot be input, neither from the keyboard nor from the Calculator UI. It is necessary to hit "C" on the Calculator UI to reinitialize Calculator to be able again to input a decimal point.

OmegaT Java Web Start

In previous article, I mentioned the release of OmegaT as a Java Web Start application.

Once OmegaT.jnlp is downloaded, a double-click should open it in Java Web

If that is not the case, if it opens as a text file for example, it means that .jnlp files associations to Java Web are broken.

To fix that, right-click on the .jnlp file, Choose "Open With", select "Others..." at the bottom of the list and browse your disk to find the application.

Java Web is located in /Applications/Utilities/Java/ for older versions of Java and in /System/Library/CoreServices/ for the most recent version of Java (Java update 4, released on June 15 2009).

Once you have selected the application, check the "Always open with" box at the bottom of the dialog.

Thanks to Yves who send me the comment that triggered this "investigation" and to this blog article that clarified everything.

Rainbow, XLIFF and OmegaT

(I've updated the contents of the file to make things clearer for people who are not familiar with XLIFF - 08/05)

OmegaT's support for complex XLIFF is not really optimal. I'm going to spare you the details but basically, unless you tweak the file significantly, OmegaT is likely not going to be able to leverage all the available data.

Let's say that we have a XLIFF file with the following data:

First segment, not yet translated:
ba bi bu
In OmegaT, this part should be in a supported source file located in /source/

Reference translation from a first reference file:
ba bi, translated to バ ビ, matches the segment to translate at 66%
In OmegaT, this part should be in a TMX file located in /tm/

Reference translation from a second reference file:
ba bi bu be, translated to バ ビ ブ ベ, matches the segment to translate at 75%
This part too should be in a TMX file located in /tm/

Second segment, already translated in the same document:
ba bi, translated to バ ビ
Since this data comes from the same document and is a validated translation, it should be in the project_save.tmx file located in /omegat/

Such an XLIFF file would look like this:

First segment, not yet translated(<target> is empty):

<trans-unit approved="no" id="source_file">
<source xml:lang="en">ba bi bu</source>
<target state="new" xml:lang="ja"/>

First reference translation for that segment:

<alt-trans match-quality="66" origin="first_reference_translation">
<source xml:lang="en">ba bi</source>
<target xml:lang="ja">バ  ビ</target>

Second reference translation for that segment:

<alt-trans match-quality="75" origin="second_reference_translation">
<source xml:lang="en">ba bi bu be</source>
<target xml:lang="ja">バ ビ ブ ベ</target>

(↑ end of the first segment)

Second segment, already translated in that document:

<trans-unit approved="yes" id="source_file">
<source xml:lang="en">ba bi</source>
<target xml:lang="ja">バ  ビ</target>

If you want to know more about the XLIFF specification, look at this page: XLIFF Version 1.2

Now, let's see how Rainbow can help us leveraging all the data directly from within OmegaT.


Here comes Rainbow. I'm mentioned Rainbow, or the Okapi Framework a number of times already.

Rainbow is a Java software that acts as a swiss army knife for localization processes. It is a filter to/from complex formats, it is a batch search/replace tool etc.

Don't forget to see the Okapi Webinar that was given a few weeks ago by Yves Savourel. It is about 1h long and goes into great details to show you what Rainbow/Okapi is about. OmegaT is used as an example too and the following text can be considered as a detailed explanation of what you see in the Webinar.


The Okapi group has decided to frequently release snapshots of the code so that users don't have to wait for milestones to get a taste of the most recent features.
The snapshots are available here: Get the rainbow_carbon-macosx_... file.

When you unzip the package, you will find a script file. Open the Terminal where the file is located, make the file executable by typing the following command at the prompt:
chmod +x

Then, call the script from Terminal to launch Rainbow.

When you launch Rainbow, you're displayed with an empty file list.

  1. drag & drop your XLIFF file on that list. It should be the list corresponding to the "Input List 1" tab.
  2. click on the "languages and encoding" tab and set the appropriate information. For example, an English manual translated to Japanese should be:
    • Source=EN (you can use a variant, like EN-US)
    • Encoding=UTF-8
    • Target=JA
    • Encoding=UTF-8
  3. Then go to the "Utilities > Translation Package Creation"
  4. Select OmegaT
  5. click on the Package Location tab
  6. Select a directory where Rainbow will create the OmegaT project
  7. Click OK.

You're back to the main window where the status bar indicates that the XLIFF file has been processed. What has Rainbow done to your XLIFF file ?


A XLIFF file is a mix of a number of things. First, it contains strings to translate in <trans-unit> sections:

<trans-unit approved="no" id="source_file">
<source xml:lang="en">ba bi bu</source>
<target state="new" xml:lang="ja"/>

Then, it may contain reference data. The first type is, obviously, what has already been translated, in similar <trans-unit> sections:

<trans-unit approved="yes" id="source_file">
<source xml:lang="en">ba bi</source>
<target xml:lang="ja">バ  ビ</target>

The other type is what is embedded to serve as reference, it comes as <alt-trans> sections within a <trans-unit>:

<trans-unit approved="no" id="source_file">
<source xml:lang="en">ba bi bu</source>
<target state="new" xml:lang="ja"/>
<alt-trans match-quality="66" origin="first_reference_translation">
<source xml:lang="en">ba bi</source>
<target xml:lang="ja">バ  ビ</target>
<alt-trans match-quality="75" origin="second_reference_translation">
<source xml:lang="en">ba bi bu be</source>
<target xml:lang="ja">バ ビ ブ ベ</target>

When Rainbow is used to create OmegaT projects from XLIFF files it looks for the 3 types of information and separates them in a way that OmegaT can manage.

  1. OmegaT cannot manage "empty" <target> elements in <trans-unit> sections. So, Rainbow recreates the source file so that it contains the <source> data in the <target> section. That way, OmegaT only has to overwrite that data:

    <trans-unit id="source_file">
    <source xml:lang="en">ba bi bu</source>
    <target xml:lang="ja">ba bi bu</target>

  2. OmegaT cannot manage already translated data in the XLIFF file. So, Rainbow creates a typical "already translated" OmegaT data file that contains the already translated segments: the project_save.tmx located in the /omegat/ folder of the project:

    <tu tuid="source_file">
    <tuv xml:lang="en"><seg>ba bi</seg></tuv>
    <tuv xml:lang="ja"><seg>バ ビ</seg></tuv>

  3. OmegaT cannot managet reference data in the XLIFF file. So, Rainbow creates a typical "reference translation" OmegaT data file that contains all the embedded translation segments: the alternate.tmx located in the /tm/ folder of the project:

    <tu tuid="first_reference_translation">
    <tuv xml:lang="en"><seg>ba bi</seg></tuv>
    <tuv xml:lang="ja"><seg>バ ビ</seg></tuv>

    <tu tuid="second_reference_translation">
    <tuv xml:lang="en"><seg>ba bi bu be</seg></tuv>
    <tuv xml:lang="ja"><seg>バ ビ ブ ベ</seg></tuv>

That way, OmegaT can seamlessly access all the data available in that complex XLIFF file. Since Rainbow creates a whole OmegaT project, the only thing necessary to proceed is to open the project with OmegaT and translate.


Nothing could be simpler. When you are done with your translation, create the translated files from within OmegaT.

Then, drag and drop the manifest.xml file located at the root of the OmegaT project created by Rainbow on Rainbow's main window where the Input List 1 tab is displayed. When manifest.xml is visible on the list, use the "Utilities > Translation Package Post-Processing..." menu.

Rainbow will use all the data it saved in the project to recreate a "proper" XLIFF file for delivery. That file contains all the data that was contained by the original XLIFF, its structure is identical. The only difference is that now it includes the data you have translated in OmegaT.

Excel files with colored non translatables... (2)

Just to show you that I am not lying:

Here is one of the Excel cells that I have to translate:

<h1>This is ugly<br />ugly ugly ugly</h1>Ugly ugly ugly ugly ugly ugly:<br /><br /><a href='%%LINK_A%%' class='yellow'>Ugly ugly:</a> Ugly ugly ugly ugly.<br /><a href='%%LINK_B%%' class='yellow'>Ugly ugly:</a> Ugly ugly ugly ugly ugly.<br /><a href='%%LINK_C%%' class='yellow'>Ugly ugly:</a> Ugly ugly ugly ugly ugly. <br /><a href='%%LINK_D%%' class='yellow'>Ugly ugly:</a> Ugly ugly ugly ugly ugly.!

Putting that straight into OmegaT as an ODS file

  1. keeps the various styles that exist in the original Excel file (fonts/colors/etc)
  2. keeps the HTML codes as plain text.

So, in OmegaT, you end up with segments like this (I colored in green the formating inherited from the Excel file, and in red the original HTML tags):

First segment:

<h1><f0>This is ugly</f0><f1><br /></f1><f2>ugly ugly ugly</f2><f3></h1></f3><f4>Ugly ugly ugly ugly ugly </f4><f5>ugly</f5><f6>:</f6><f7><br /><br /><a href='%%LINK_A%%' class='yellow'></f7><f8>Ugly </f8><f9>ugly:</f9><f10></a></f10><f11> </f11><f12><s13/>Ugly ugly ugly ugly</f12><f14>.</f14><f15><br /><a href='%%LINK_B%%' </f15><f16>class='yellow'></f16><f17>Ugly ugly:</f17><f18></a> </f18><f19><s20/>Ugly ugly ugly ugly ugly</f19><f21>.</f21><f22><br /><a </f22><f23>href='%%LINK_C%%' class='yellow'></f23><f24>Ugly ugly:</f24><f25></a> </f25><f26>Ugly </f26><f27><s28/>ugly ugly </f27><f29>ugly ugly</f29><f30>.

Second segment:

</f30><f31><br /><a href='%%LINK_D%%' class='yellow'></f31><f32>Ugly </f32><f33>ugly</f33><f34>:</f34><f35></a> </f35><f36>U</f36><f37>gly ugly ugly ugly ugly</f37><f38>.</f38>

You see ?

All the original HTML is here, and all the original formatting is applied to each cell part separately...

This is obviously not the solution. For one thing, the inherited formatting (all the green tags) is totally irrelevant as far as the translation is concerned. Then, the HTML tags should rather be handled as HTML and not as plain text, to be able to see the translatable text better, but also to reduce the modification risks when you translate the segment.

Now, if you follow my earlier advice, the above segment would look like this in OmegaT (with blue color for emphasis), after being handled as a "normal" HTML file:

First segment:

This is ugly<br0/>ugly ugly ugly

(notice that the tags <h1> and </h1> are not shown since they are block level tags and the whole block is the segment! You just reduced the total number of tags in the segment!)

Second segment:

Ugly ugly ugly ugly ugly ugly:<br0/><br1/><a2>Ugly ugly:</a2> Ugly ugly ugly ugly.<br3/><a4>Ugly ugly:</a4> Ugly ugly ugly ugly ugly.<br5/><a6>Ugly ugly:</a6> Ugly ugly ugly ugly ugly.

Third segment:

<br7/><a8>Ugly ugly:</a8> Ugly ugly ugly ugly ugly.!

Much better isn't it ? Now, how much time and energy do you think this trick will save you next time you have such a (not so uncommon) file to translate ?

ps: I did try to do all the heavy editing in Emacs, but I fear I am not yet familiar enough with its regex syntax. I eventually had to revert to TextWrangler, but I am not giving up...

ps2: If you know a CAT tool that does not require any manipulation to reach a manageable tag number, let me know !

OmegaT small (?) update

OmegaT 2.0.3 update 2 has been released.

From the release file:

OmegaT beta version 2.0.3 update 2 has been released. For the first time, OmegaT is available as a Java Web Start application (

Launching OmegaT from requires no installation, and future updates of this version will happen automatically.

Two bugs have been corrected. One concerns segment detection in the Editor, and the other StarDict dictionaries.

Belarusian, Dutch and Catalan localisations have been updated.The OmegaT Project always welcomes developers, localizers and users to contribute their experience, knowledge and insights to the software we release.

Regarding Webstart and privacy (quoting Tony):

OmegaT Java Webstart does NOT save any of your information to our web servers. The application runs on YOUR machine. Your documents and translation memories remain on your computer, and the OmegaT project will have no access to your work or information.

(end quote)

The fact that OmegaT is now available directly from the network without any specific install procedure does not mean that OmegaT better supports network interaction between translators (data sharing etc). It only means that it is easier to distribute/use/update.

There are still issues to iron out though: how to use the Lucene tokenizer with that WebStart version... We're investigating this right now... :)

Excel files with colored non translatables...

Here comes an excel file, with pseudo HTML in the cells.

The HTML tags are red and must not be modified. If you want how the segments look check the follow up post.

Translating that in OmegaT is relatively straightforward:

  • save the file as ODS in (or NeoOffice)
  • put that source file in the /source/ folder of your OmegaT project
  • load the project and translate

The problem is that not only you are going to have all the HTML tags displayed for what they are within the translatable text, but you're going to have to deal with the red color tags that will surround all the HTML...

Not user friendly at all...

Another solution is to do like this:

  • copy-paste the column into a text file -> no more red color, will deal with that later
  • insert a visible marker like @@@ at each end of line
  • save the file as .html -> no more full HTML tags in the segments
  • put in /source/
  • go to Options > Segmentation and add 2 rules. One where you segment before @@@ and one where you segment after @@@, that way you'll nicely isolate the marker and it will be translated only once
  • load, translate

The resulting file should contain all the original tags, without modifications, but some characters in the original may have been converted to HTML references. Replace those with the original character if you think it is better.

Now, open your file in a text editor, remove the @@@ markers and paste the contents into a Write page in OpenOffice.

There, do a "Regular Expression" search for the string: (<[^>]*>)

The string means: a "<" followed by a number of anything but ">" followed by a ">": (basically any HTML tag). The surrounding parenthesis put the matching string into a memory for later retrieval!

and replace by "&" with the style "font color=red". "&" means "the group that was just put into memory".

All your HTML tags should be colored in red now.

Copy-paste the contents into the original file where it needs to be, and deliver !!! Also make sure that one line corresponds to one cell (manipulating the @@@ marker should not change the overall structure but one never knows!)

(There are probably easier ways to deal with such files. Let me know!)

Yes ! Okapi snapshots available !

From Yves Savourel @ Okapi Framework:

If you are interested in testing the latest build of the Java-based Okapi tools and libraries you can download them from here:

Those are the latest development builds (more recent than the normal releases), they have all the latest features, BUT they are not tested and may be unstable. They are the versions the developers are using. Use them at you own risks.

The times listed in the directory is date/time when the files was generated (in US Pacific Time). We will update those snapshots relatively frequently.

OmegaT small update

OmegaT 2.0.3_1 was just released, it comes now with a complete Japanese/German/Slovenian UI/tutorial.

Okapi webinar

A message from Okapi's Yves Savourel:

Just a note to let you know that I'll be giving a little introduction on using the Okapi Tools. Note that it will be focused on the new Java-based tools.

ENLASO is hosting this free webinar on July 16th at noon Mountain Time.
It's free and you can register here:

The latest version of the Java Okapi tools is here:

Bored Trados users ?

For bored Trados users who want to work in a free software environment, here are the latest news:

1) OmegaT is able to translate TTX files that have source=target (output option if I am not mistaken), that requires a small utility called Toxic, to be found here:

2) It is possible to deliver "cleaned/uncleaned" file sets by translating the file in OmegaT and processing the resulting TMX in with the Anaphraseus macro (a Wordfast equivalent for OOo). The discussion about the process is here:

And Anaphraseus is here:

(updated 7/8)

3) Ask your Trados clients to send you TMX memories instead of Trados memories, you'll be able to use them in OmegaT without problems. Trados seems to have problems creating conforming TMX files. If OmegaT complains, use TMXValidator from Maxprograms.

TMXValidator is here:

4) Some file formats are not directly supported by OmegaT. Use Rainbow to create OmegaT projects from unsupported files. Not all files supported by Trados are supported by Rainbow but Rainbow still covers a very reasonable range of "exotic" formats.

OmegaT directly supports the following formats:

  • OpenDocument/
  • Microsoft Open XML
  • DocBook XML
  • TeX
  • Plain text
  • SRT subtitles
  • PO (monolingual)
  • XLIFF (Okapi generated)
  • ResX ressources
  • INI ('key=value' format)
  • Java
  • HTML Help Compiler
  • QuarkXPress CopyFlow Gold
Rainbow has filter for the following formats: Okapi Framework - Filters. Rainbow is here:


That is the title of an article I wrote in Japanese about OmegaT.

The article was published in the 45th issue of the AAMT Journal. I've put a copy of the article online, here: 自由に翻訳!

The article is not an introduction to using OmegaT, if you want the introduction, download OmegaT and start it. You'll have a tutorial in the language of your OS.

Download link: OmegaT_2.0.3_Beta.dmg

OmegaT in Kyoto on July 11th

I'll be making a presentation about OmegaT at the "Open Source Conference 2009 Kansai" on the 11th of July, from 11.15 to 12.00.

People who can't make it for the seminar are welcome to the OmegaT "booth" where I'll be from Friday morning.

Bash (command line) shortcuts

Until today, I only used the following shortcuts on the command line:

ctrl+a → go to beginning of line
ctrl+e → go to end of line
ctrl+k → delete to end of line

And even though I was very frustrated by the fact that I had to use
the mouse to select/copy/paste etc, it never really occured to me to
google for "bash command line shortcuts"...

To make it short: bash uses the readline library.

The user documentation for readline is at:

All the shortcuts that exist on your machine can be found by using the
'bind' command:
$ bind -P | more
You'll have more shortcuts with:
$ bind -p | more
If you want to know how to use 'bind' to add shortcuts, check its help
$ help bind

Select/cut/paste require to first bind a shortcut to "kill-region":
$ bind "\C-xx": kill-region
(ctrl+x followed by x)

Now we need to select the string (create a "region").

A region is automatically created between a "mark" and the cursor. So, we only need to put the mark at one end of the region and to move the cursor
to the other end.

To create a mark use: ctrl+@ or ctrl+space,
then move the cursor, then hit ctrl+xx to "kill" the

Pasting requires ctrl+y.

But, the ctrl-y (Yank/paste) command works only within
the application from where the string was "killed". The "kill-ring" is
not shared by other applications (even though they may accept
ctrl-y as a Yank command).

So, if you want to get a string from terminal and paste it outside
(like select a command and paste it into a mail for ex), here is
something that may not be the most efficient way to go, but it works:

echo string | pbcopy
echo "complex string" | pbcopy

For ex, to put the above line in the pastebpard, I'd do:
echo "echo \"complex string\" | pbcopy" | pbcopy

Static electricity and your fan...

My fan started to blow like crazy yesterday. But it was not really blowing in fact. It was just making a lot of noise. A little bit like when those little model planes take off... Since my MacBook is not equipped for flying I understood something was very wrong. I was doing CPU intensive things when all this started... Like (re)install the trial version of iWork' 09 and simultaneously move 3 gb of data to my external disk...

I did not sleep well last night. The prospect of having to complete 3 translations on my backup machine (an old Titanium) while the MacBook was sent to repairs -for the 4th time- was not making me very cheerful.

I called Apple support this morning and they told me this fan problem could be triggered by static electricity.

The procedure to solve that is as follows:

  1. turn the machine off
  2. unplug it
  3. remove the battery
  4. press the start button for more than 10 seconds
  5. plug the machine and put the battery back
  6. press Command+Option+P+R simultaneously right after pressing the start button

The machine is supposed to emit 2 long beeps after booting and then starts normally.

I did not have 2 beeps, instead of that the MacBook entered a just as scary cycle of reboots. So I eventually stopped pressing the keys, and the machine decided to stop pedaling with my nerves and properly boot.

Now, the fan seems to behave properly. I'll hopefully be able to complete the jobs without having to send the machine to repairs... Only 5 months left on my AppleCare !!!

iWork 09, no backward compatibility...

I just downloaded the iWork '09 trial package. Reports on the net mention its enhanced Applescript support, its new looks and new functions.

Pages '09 opens Pages '08 files without difficulties and can save into that format (see the new Share menu), but the new format cannot be opened in Pages '08.

A Pages '08 was basically a folder with a .pages extention. You could go to Terminal and do a:

$ cd

to find the following list of files:

$ ls
Contents QuickLook index.xml.gz

where both Contents and Quicklook were folders with files in them, while the file itself was a gz-compressed XML file (index.xml.gz)

Now, the same file created by Pages '09 would have a totally different structure.

Where file_name.pages was a folder containing compressed data in Pages '08, the file is a compressed folder containing normal files.

To see what it looks like, change the .pages extension to .gz and double-click that file. The result is a folder with the following files:

$ ls
QuickLook buildVersionHistory.plist index.xml

Quicklook is still a folder with a PDF (Quicklook) and a JPEG (thumbnail) preview of the file but the old Contents folder is not there and the index.xml contains XML code that significantly differs from the one in Pages 08.

Keynote '09 and Numbers '09 show a similar internal structure for their files.

Popular posts (last 30 days):