PDF (and DTP) rant

Yes, you probably already guessed what the subject of this rant is.

The usual nightmare - the client sends you a text to translate, but it's in PDF! And, what's even worse, you need to deliver not only the translation, but they want full DTP service - meaning they want the finalized PDF of the translated material, ready for printing :(

Of course, the PDF is a low-resolution version, and the illustrations will have to be "upped" to 300DPI, as required by the printing service vendor.

So, you try to explain that it's not done that way, that you cannot simply "reconstruct" the translated PDF from the low-res PDF you received. You try to argue that it simply cannot be done - at least not at the usual rates and within the usual timeframe.

However, the end client isn't aware of the technical problems, and you need to "simplify" the explanation of the problem, without getting too technical.

(As an aside, I'm constantly amazed by the fact that so many people think that, in order to get a translation of a 200-page manual you just need to press a few keys on the keyboard and - presto! - the perfectly printed (and bound) 200-page full-color book comes out of your office printer!)

But, to get back to the point, I usually have several "colorful" analogies in reserve, in order to explain WHY it isn't so easy to do. One of my favorites goes something like this:

"Well, to put it simply, you're providing me with 400 pounds of pork sausages and expecting me to return a 400-pound pig that happily runs around the pigsty.... Can't be done, sorry...."

So, somehow you manage to make them understand that it's no easy feat to get the final PDF which is just barely acceptable for printing, you agree on the price and the deadline, and now the real work begins...

The problem of PDF originals is multiple - first you have to extract the text (preferably preserving at least some of the formatting), then you have to extract the illustrations (and increase the resolution, if necessary), making sure nothing has been left out.

Then you have to do the DTP from scratch, using any of the usual DTP programs (in our case it's usually InDesign).

However, none of the problems stated are simple.

First, you cannot easily extract text from PDF - at least not in a usable format, which would not require additional "manual" work. For this purpose I still use Acrobat 5 and its "Save as RTF" function. It exports all of the text, but all lines of text usually end with line breaks, which have to be removed, so that the text can be translated using Trados or whatever TM software you use.

Acrobat 6 and 7 do this better, and usually do not place line breaks at the end of every line of text, but they have other, more serious faults - one of the most serious being that they tend to arbitrarily skip portions of the text when exporting to RTF - which makes them unusable.

There are other non-Adobe solutions, one of them being Abby PDF Transformer. It uses OCR principle, and actually works OK. However, it often does not preserve formatting (bold and italic text, etc.), so, again, it's not a perfect solution.

Most of the translations we do this way are manuals of one kind or another, mostly containing references to commands which should appear as bold text, like this:

To open the file, press Open, and browse to the file you want to open.

So, it's extremely important to have the bold formatting applied to appropriate strings...

In order to avoid any errors in the DTP process, and to make the DTP process as fast as possible, we usually tag our PDF-exported RTF files prior to translating - checking whether all the necessary formatting (usually only italic and bold) has been retained. It's a manual work, and sometimes it takes a long time, since we also insert special tags as placeholders for pictures and symbols, so that the text which will be translated looks e.g. like this:

To open the file, press Open or use the <PIC> icon on the toolbar.

(Otherwise, the DTP crew would have to find the locations of all those tiny icons themselves, wasting significantly more time, not to mention the increased possibility of errors!)

Then, the translation is done the usual way (Trados + Word), and the final, translated RTF is then processed using the VBA Word macro we developed in-house for export to InDesign tagged text. The tagged text has special formatting (red color) for our picture tags, and also some other stuff which makes the life of our DTP crew a lot easier when doing the DTP "from scratch".

However, the whole process is still extremely labor-intensive and time-consuming - and the end result is usually still just barely "acceptable" (since you obviously can't e.g. "upsize" a picture from 72DPI to 300DPI without any loss of quality...)

I don't have to mention that for this type of work we charge a lot more than when we work from "normal" DTP files.

But, even when we get the original InDesign (or any other DTP) files with all the links and fonts, the situation isn't always as clear as it might seem - often the original INDD files were prepared by... hmmm, let's say "less than professional" people, and are best left alone. In such cases we just use the original links (pictures), and create new INDD files "from scratch" - which is usually a lot faster than trying to use the originals we receive.

By "less than professional" I mean the situation where you have e.g. 12 InDesign paragraph styles defined, and when ALL of those styles applied in the document use manual overrides :(

Or the situation where e.g. indented text in INDD file is "created" using tabs, or - even worse - spaces... :(

You get the picture....

Linux (and tools)

Well, this one definitely isn't a rant :)

I'm constantly amazed how much Linux has improved in the last few years.

Right now I'm using SuSE 10.1, and more often than not I find that most of the peripherals I sometimes use (like a cheap digital camera, etc.) work better in Linux than in Windows :)

One of the best Linux programs I've been using for years is Hylafax - a powerful office faxing package, which I can heartily recommend to anyone who needs a robust office faxing solution. And, what's best, there's nothing like it in Windows world - well, nothing quite as robust, not to mention free.

The only thing I'm still missing is a simple replacement for FileMaker database. I keep my books in FileMaker - I developed my own accounting system in it, and have been using (and improving) it for years.

So far, I haven't been able to find something as simple and as compact as FileMaker. I don't need a full-blown MySQL or PostgreSQL installation, with dozens of directories, etc.. Something simple with an SQLite background would be quite OK, but the problem is that I also need simple and easy (visual) forms and reports creation... :(

I often need to change the reports I use, due to ever-changing legal requirements, and in FileMaker I can do it in a couple of minutes. No such luck with anything I've tried under Linux so far. However, I'm confident that I won't have to wait much longer, given that there are several promising Linux projects of that kind being actively developed...

Translation tools

As regards translation tools, there are many - but almost none that can be used "out-of-the-box" for any kind of "general" translation work.

By that, I mean there aren't many universal Linux translation tools - most are intended only for use with .po files - i.e. for localization of Linux software.

One Open Source exception is OmegaT - which I intend to test-drive soon.

There are other tools, like Heartsome XLIFF Editor - which isn't free, let alone Open Source, but still (somewhat) usable...

I've tried Heartsome XLIFF Editor (HXE), but wasn't exactly overwhelmed with it. I guess I'm spoiled by years of working with Trados, but HXE isn't exactly intuitive to use, and its Help is also very sparse...

Another thing is that it handles tags rather strangely. I tried to do a translation of an XLF file with it, but it didn't come out very well. Perhaps I did not configure it properly, but even after preparing a good TMX and importing old translations, the matches were rather strange. Combined with some segmentation problems, which I couldn't resolve quickly, I decided I didn't have the time to fiddle with it any more, and gave it up for that particular task. However, for simpler (non-tagged) texts, it should do OK, I guess.

I just wish there was a TM system under Linux that could be plugged into Emacs ;)

Working with Passolo

Recently I had a project I had to do in Passolo. I was given instructions to download version 5 Translation Editor (the stripped-down "satellite version", intended for translators), and to use that for translation of a software project.

I've never used Passolo before, so it was a bit of challenge at first - trying to get to know the program and understand how it works.
At first I was glad to see that it has some kind of Trados integration, but soon realized that it doesn't really work in "Translation Editor" - at least I couldn't get it to work.

The help file does not really help, since obviously the same version of help file is used both in "full" and "translation editor" versions, so most of the functions described in the Help file don't actually work in the "satellite" Translation edition.

After some e-mails with my PM on this project, it was determined that Trados integration doesn't actually work. :(
I re-checked several times, and even tried to change the Trados integration macro, but to no avail - the macro cannot be edited in "satellite" edition of Passolo.
BTW, I realized what kind of hack it was when I saw that the reference to Trados Workbench file was hard-coded in the macro! :o

Another thing I couldn't exactly get the hang of was its fuzzy matching. I've properly populated the glossaries I was to use (a kind of workaround in order to be able to use existing translations, at least for terminology and shorter segments/sentences), but the fuzzy matches were rather surprising. Sometimes I'd get the expected match, and sometimes not. Strange.

Not to mention that once your glossary exceeds about 2.000 lines/terms, it tends to get rather slow... I had several glossaries, ranging from about 1.000 terms, up to 10.000 terms. I had to "switch on" (enable) those larger ones only when absolutely necessary, as it slowed the program almost to a crawl - I'd wait 10 seconds or more for the program to populate the window with matches for each new segment...

In short, not an easy job. What bothered me the most is the fact that the Help file that comes with this "satellite" edition actually refers to the full version, so you have to find out yourself what actually works in this "bare-bones" version :(

It's not all bad, though. The "live dialog" preview works fine, and is helpful when you need to shorten the translated string to make it fit on the dialog.

However, you should not rely completely on Passolo and its fuzzy-matching function to ensure consistency...

Logoport from Linux

So, you also work for Lionbridge, and have to use Logoport more and more.

Wouldn't it be nice if you could use Word + Logoport directly from Linux, without having to boot vmware Windows virtual machine?
Well, I've managed to do it, and it works.

I've used Crossover Office to install Word from the Office XP package, which works flawlessly. I've also added the "Logoport.dot" file in the templates directory, and also added the "Logoport.dll" to "system32" directory in the "fake Windows" in cxoffice.

Once you boot Word under Crossover, activate the Logoport.dot, and connect to Logoport using your account details.

Logoport will most likely tell you that you need to update Logoport, just click "OK", and the new dll will be installed.
After that close Word and restart it, as per instructions, and after that you can work without and problems in Word, connecting to Logoport and translating as usual.