When I import a Final Draft File Converter format into Scrivener, characters with an accent or trema are preserved in the text. But when I export from Scrivener to Final Draft File Converter format, and then import into Final Draft (7), the accent and trema are altered into gibberish (like √© for é, and √´ for ë). I need this to work correctly, as I make quite a lot of use of characters with accent and trema.
I think it maybe a character encoding problem.
Yes, as you suspect, it’s a character encoding problem - unfortunately the FCF file format is an old binary format, very basic, so doesn’t support a great character set to the best of my knowledge. If you can afford the upgrade to Final Draft 8, FDX is a much better way of transferring your work across, as it supports a lot more.
All the best,
Keith
Ah, that’s unfortunate. I have to see about upgrading to Final Draft 8. I usually wait a while. Thanks for the quick reply.
Best regards,
Tim
A small question, though. Why does importing a FCF file containing those characters into Scrivener pose no problem?
Best regards,
Tim
On its way out, it has to go through a particular encoding - it is going through UTF8 encoding currently, so presumably that is where the stumbling block lies.
Best,
Keith
Yeah, I believe Final Draft 7 and previous need text encoding to be: Western (Mac OS Roman).
If there is any chance you could convert the UTF8 encoding to Western (Mac OS Roman) on its way out, that would solve the problem. Accent and trema would be preserved. I don’t know how easy this is, but it would make me happy (and maybe others too).
It’s unlikely that I upgrade to Final Draft 8 any time soon, as money is a bit tight at the moment.
Best regards,
Tim
Actually, that should be very easy (though I need to test), but before I do so for 1.52 (1.5 bug fix 2…) and 2.0, how would that affect opening the file on Windows (encoding it in Western Mac OS)?
All the best,
Keith
Ah, yes, the Windows version of Final Draft. I don’t know. I only know that Final Draft 7 for Mac has problems with any encoding other than Western (Mac OS Roman). I just tested it, and this includes a Final Draft File Converter formatted text file encoded in Western (Windows Latin 1), which is usually used on Windows, I presume.
Know that when I export from Final Draft 7 for Mac to Final Draft File Converter file, it is always encoded in Western (Mac OS Roman). So you never have the option to export from the Mac version of Final Draft into a Final Draft File Converter file with Western (Windows Latin 1) encoding.
This can mean two things: It is no problem for the Windows version of Final Draft to import a Western (Mac OS Roman) file. Or two, it is a problem, but then it is always a problem between the Mac and Windows version of Final Draft 7 and earlier. This means that there are always two encodings used: Western (Mac OS Roman) and probably Western (Windows Latin 1). So a solution for Scrivener is to just have two options during the export: Final Draft FCF (Mac), and Final Draft FCF (Windows).
I assume, though, that if you use Scrivener on the Mac, you will also use the Final Draft File Converter format to import into Final Draft on the Mac. I don’t think anyone would write in Scrivener on the Mac, and then export to FCF and immediatly work on it on a PC. Even if you need to share with someone on the PC, you would want to import into Final Draft on the Mac first for some formatting touch ups.
Best regards,
Tim
I have altered my post.
When I export in Scrivener to Final Draft 5-7 File Converter (FCF), that file is when openened up in SubEthaEdit identified as already having Western (Mac OS Roman) encoding! Yet, when I look at the characters like é, they are not preserved in the text and are displayed in SubEthaEdit as √©. This should not be the case. If the file really was in Western (Mac OS Roman) encoding, an é would be displayed as é in the text.
So it seems characters like é are encoded like UTF8, but the file is identified as being in Western (Mac OS Roman) encoding, and is loaded as such.
This seems a bit strange.
Best regards,
Tim
It’s probably because the text gets passed to the exporter as UTF8 - when the converter is finished with it, it must be back to Mac OS Roman.
Anyway, the good news is that I have fixed this for 1.52 - changing the encoding to Mac OS Roman internally sorted everything out. There are a couple of other things that have come up that I still need to fix for 1.52, so the update won’t be out for a couple of weeks, but if you need this urgently drop me a line at the support e-mail address and I’ll make an version available to you.
All the best,
Keith