Monday, March 21, 2022

Converting Ami Pro .SAM files to .doc or .txt

Ami Pro was by far the best word processor of it's time. That was the time of Windows 3.1, and later Windows 95. It was bought by Lotus, and instead of being developed into the word processor I wish I would have now, it eventually disappeared... 

Nowadays, there is no easy way to get to the content of these old .sam files. The files are just plain ASCII text (except when they have embedded bitmap images). But extracting the raw text from the files is not simple. For example, all accented characters are written in a strange format: "é" is written as "<\i>" in the file, "à" as "<\`>", etc.

After trying various solutions like installing Windows NT 4 into a virtual machine, or directly installing Lotus Ami Pro 3.1 into an old Windows XP VM, I came across mentions of a plugin for Microsoft Word that would allow it to read .sam files. That plugin itself was hard to find. It seems to have been included in old Microsoft converter packs which are not available anymore. This blog post from 2011 explains how to install the "Ami Pro" plugin from http://www.gmayor.com/downloads.htm but unfortunately the download is not available there anymore, saying "Sadly this old filter no longer appears to work".

Eventually, I could find it at http://www.lotusamipro.com/ where it can still be downloaded : http://www.lotusamipro.com/files/word2ami.zip

And it does work in MS Word 2003, which I had in an old Windows XP virtual machine.

So, if you have Word 2003,

  • Get that file from http://www.lotusamipro.com/files/word2ami.zip (or from here)
  • Copy "Ami332.cnv"
    to "C:\Program Files\Common Files\Microsoft Shared\TextConv\Ami332.cnv"
  • Open Word, and in the File / Open... window, under "Files of type:" select "Ami Pro 3.o (*.sam)" (or "All Files (*.*)")
    You will get this warning on which you will have to click "Yes":
    This file needs to be opened by the Ami Pro 3.0 text converter, which may pose a security risk if the file you are opening is a malicious file. Choose Yes to open this file only if you are sure it is from a trusted source.

If you have many files to convert, you can map macros to buttons in Word to make it easier. Here are 2 macros in that ancient VBS language which Word understands, to save the current file as ".doc" and as ".txt":

Sub SaveAsDOC()
' Save current document as .txt
    strDocName = ActiveDocument.Name
    strPath = ActiveDocument.Path & "\"
    intPos = InStrRev(strDocName, ".")
    strDocName = Left(strDocName, intPos - 1)
    strDocName = strPath & strDocName & ".doc"

    ActiveDocument.SaveAs _
        FileFormat:=wdFormatDocument, _
        FileName:=strDocName, _
        AddToRecentFiles:=True
End Sub

Sub SaveAsTXT()
' Save current document as .txt

    strDocName = ActiveDocument.Name
    strPath = ActiveDocument.Path & "\"
    intPos = InStrRev(strDocName, ".")
    strDocName = Left(strDocName, intPos - 1)
    strDocName = strPath & strDocName & ".txt"

    ActiveDocument.SaveAs _
        FileFormat:=wdFormatText, _
        FileName:=strDocName, _
        AddToRecentFiles:=True, _
        Encoding:=1252, _
        LineEnding:=wdCRLF
End Sub

If you are on Mac or Linux or have WSL installed in Windows, you may also want to use Bash to convert the .txt files from their Windows CP 1252 character set to UTF-8:

for f in *.txt; do recode cp1252/..utf8/ "$f"; done # using recode

Or if you don't have recode but have iconv:

for f in *.txt; do iconv -f cp1252 -t utf8 -o "$f.tmp" "$f" && mv -f "$f.tmp" "$f"; done

To set the modification time of the new files to the time of the originals, the touch command can be used in Bash :

for f in *.SAM; do touch -c -r "$f" "${f%%.SAM}.txt"; done  # date of .SAM file to .txt file
for f in *.SAM; do touch -c -r "$f" "${f%%.SAM}.doc"; done  # date of .SAM file to .doc file
# or for both .txt and .doc files a once;
for f in *.SAM; do touch -c -r "$f" "${f%%.SAM}.txt" "${f%%.SAM}.doc"; done

The Word converter does not import bitmap images embedded in the Ami Pro file. These can be extracted with te following perl script:

#!/usr/bin/env perl

## Extract bitmaps embedded in file (like in Ami Pro .SAM files)

use strict;

my $debug = 1;

my $file = shift;
die "Usage: $0 FILENAME\n" unless (-r $file);

open my $fh, '<:raw', $file;
read $fh, my $all, -s $fh;
close $fh;

my $filesize = -s $file;

my $count;
while ( $all =~ /(BM.{12})/sg ) {
    my $m = $1;
    warn "# ", join(" ", unpack("(H2)*", "$m")), "\n" if $debug;
    #https://en.wikipedia.org/wiki/BMP_file_format
    my ($bm, $size, $res1, $res2, $offset) = unpack "A2 V H4 H4 V", $m;
    if ( $offset > $size or $size > $filesize ) {
        warn "# Skipping false positive at $-[0] (size $size > file size $filesize)\n" if $debug;
        next;
    }

    warn "Found at $-[0]:\n",
          "BM     = $bm\n",
          "size   = $size\n",
          "res1   = $res1\n",
          "res2   = $res2\n",
          "offset = $offset\n" if $debug;

    $count++;
    my $bitmap = substr($all, $-[0], $size);
    print "Saving $file-$count.bmp\n";
    open my $bmfile, '>:raw', "$file-$count.bmp" or die;
    print $bmfile $bitmap;
}

Finally, an alternative which I only found afterwards is to install Lotus SmartSuite 9.8 which can be downloaded from the WinWorld site : https://winworldpc.com/product/lotus-smartsuite/9-8

That will also let you open Ami Pro files and save them in various other formats. One advantage is that when saving to Word 97 .doc files, embedded images are preserved.

Labels: , , , , , ,

Wednesday, February 10, 2010

PDF to Word conversion notes

Had a complex PDF to convert to something editable like .doc, so I had another look at what was available.

This comparative test from 2008 was very helpful, as were some readers' comments. It concluded by recommending the koolwire.com service, which was indeed quite good, and also very convenient because it can be used through email. It produced an RTF with mostly actual tables. Visually, however, the tables in this particular case would have needed quite some re-formatting to look like the original ones.

Several readers suggested the PDF-to-Word service at pdftoword.com. For me, this gave me the best looking results. It converted the complex tables into columnized sections instead, but that was fine. (As an aside, it is not very clear which engine this service is using. It is related to Nitro PDF, a commercial Windows application which is promoted from the pdtftoword.com page. Also, the Nitro PDF pages link to the free pdftoword.com service as their free version. However, the produced Word document mentions Solid Converter PDF, another commercial Windows application, in it's properties. Weird...)

I also tried the convertpdftoword.net service which others suggested. It also gave a good looking Word document, but built it with tons of independent text boxes which was quite unconvenient in my case. A closer look, showed that this service was actually using VeryPDF's PDF2Word, which produced an RTF file (but with a .doc extension). PDF2Word turns out to actually be a re-packaging of xpdf, and is free (GPL) software. The source is available, but VeryPDF sells the Windows executable.

The funny thing from theses tests: the only completely useless conversions happened to be the one from Adobe itself.

Conclusion: I had the best results with pdftoword.com. But it all depends on your source document and what you want to do with it.

Labels: , , , , , ,

Wednesday, March 18, 2009

Installing latest FFMPEG on Debian Etch

How to install the latest FFMPEG on a Debian 4 ("Etch") server? This post encouraged me to try it, despite the fact that it needs compiling from source, and that Etch isn't even the current "stable" Debian anymore. PhillC's post helped a lot, but it still didn't work for me exactly as described there. So here is how it eventually did work for me.

# echo "deb http://www.debian-multimedia.org etch main" >>/etc/apt/sources.list

or

# echo "deb http://www.debian-multimedia.org stable main" >>/etc/apt/sources.list

(I used both, and fiddled with enabling and disabling that repository, so I'm not sure anymore which one ended up being useful).

aptitude update gave me a GPG error, so I had to add the key it mentioned:

# gpg --keyserver hkp://wwwkeys.eu.pgp.net --recv-keys 07DC563D1F41B907
# gpg --armor --export 07DC563D1F41B907 | apt-key add -
# aptitude update

The following didn't work, or only worked partially:

# apt-get build-dep ffmpeg
Reading package lists... Done
Building dependency tree... Done
E: Unable to find a source package for ffmpegcvs
I continued anyway with the long install line of various libraries. I had to remove some of these libraries from the suggested install line. Particularly, since I had to recompile libx264 anyway, I should have removed libx264-dev at this point. It is removed in the line below:
# aptitude install liblame-dev libfaad-dev libfaac-dev libxvidcore4-dev liba52-0.7.4 liba52-0.7.4-dev build-essential subversion

# cd /usr/src
# svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg

And so I got the current version as of March 17:

Checked out external at revision 28979.
Checked out revision 18021.

And I tried configure:

# cd /usr/src/ffmpeg
# ./configure --enable-gpl --enable-pp --enable-libvorbis --enable-liba52 --enable-libdc1394 --enable-libgsm --enable-libmp3lame --enable-libfaad --enable-libfaac --enable-pthreads --enable-libx264 -enable-libxvid

After various errors, and removing options, I ended up with this error:

ERROR: libx264 version must be >= 0.65.

And trying to install that from the debian-multimedia.org repository didn't work either:

# aptitude install libx264-65
The following packages have unmet dependencies:
libx264-65: Depends: libc6 (>= 2.7-1) but 2.3.6.ds1-13etch8 is installed and it is kept back.
So this thread came to rescue, and I embarked on getting x264 and compiling that from source too:
# aptitude install git git-core

Trying to use Git at this point gives an error, but suggests the solution:

# update-alternatives --config git
There are 2 alternatives which provide `git'.
Selection    Alternative
-----------------------------------------------
*+        1    /usr/bin/git.transition
        2    /usr/bin/git-scm

Press enter to keep the default[*], or type selection number: 2

Next steps:

# cd /usr/src/
# git clone git://git.videolan.org/x264.git
# cd x264
# ./configure --enable-shared

This gave an error about yasm, which was not the right version. I could have tried to compile that too, as shown on the Ubuntu forum, but impatiently decided to try the suggested disable option instead. So the x264 part which worked:

# ./configure --enable-shared --disable-asm
# make
# make install
# ldconfig

And finally, ffmpeg:

# cd /usr/src/ffmpeg/
# ./configure --enable-gpl --enable-postproc --enable-pthreads --enable-libfaac --enable-libfaad --enable-libmp3lame --enable-libx264 --enable-libxvid
# make
# make install
I also had to remove the old ffmpeg version (aptitude purge ffmpeg) which I had installed some time before this, and finally did this:
# echo /usr/local/lib >> /etc/ld.so.conf.d/local.conf
# ldconfig

Since I had a leftover libx264 installed with aptitude and which was too old, that caused a segmentation fault when I tried to encode with ffmpeg. After searching (aptitude search x264), I found i had to aptitude purge libx264-54 libx264-dev . Then, just to be sure, I re-did the ./configure, make clean, make, make install incantations for both x264 and ffmpeg.

In the end, ffmpeg is working. I suppose the --disable-asm option on x264 will make encoding slower, so it may be worth compiling yasm, and re-compiling x264 again.

Now that ffmpeg is working, the main problem is trying to understand it's myriad of incomprehensible and cryptically documented options.

Labels: , , , , , ,

Friday, January 23, 2009

Encoding video sizes

Video compression usually works on square blocks of pixels. These can have sizes of 8x8 or 16x16 or other powers of 2. H264 (AVC) for example, uses macroblocks of 16x16.

So when compressing video, it helps if the frame size is such that both width and height are evenly divisible by 16 or at least by 8. This is why videos encoded for the web or for portable video players are often not exactly in a 16/9 aspect ratio. The PSP's screen, for example, is 480 x 272 even though true 16/9 would require 480 x 270. But 270 is not divisible by 16 whereas 272 is. Youtube uses 640x360, which is true 16/9 and divisible by 8. If you use other sizes, FFmpeg will print a message like

width or height not divisible by 16 (480x270), compression will suffer.

So what are the sizes which are both the right aspect ratio and nicely divisible by 16 or by 8? This little Perl script will let us know:

#!/usr/bin/perl

my $aspect_width  = 16;
my $aspect_height = 9;
my $max_height = 1200;
my @dividers = (16, 8);

for my $divider (@dividers) {

print "$aspect_width/$aspect_height with both ",
     "width and height divisible by $divider :\n\n";

# try sizes up to Full HD
for my $i (1..$max_height/$aspect_height) {
   my $h = $aspect_height * $i;
   unless ($h % $divider) {
       my $w = $aspect_width * $i;
       printf "$aspect_width/$aspect_height divisible by %2d : %4d x %4d\n",
              $divider, $w, $h;
   }
}

print "\n";
}

For 16/9, this gives, among others, numbers like

16/9 divisible by 16 :  256 x  144
16/9 divisible by 16 :  512 x  288
16/9 divisible by 16 :  768 x  432
16/9 divisible by 16 : 1024 x  576
16/9 divisible by 16 : 1280 x  720

For sizes divisible by 8, you obviously have all of the above, plus (among others):

16/9 divisible by  8 :  384 x  216
16/9 divisible by  8 :  640 x  360
16/9 divisible by  8 :  896 x  504
16/9 divisible by  8 : 1920 x 1080
16/9 divisible by  8 : 2048 x 1152

Labels: , , , , ,