cuneiform team mailing list archive

[Ben Jackson <ben@xxxxxxx>]

On Mon, Jul 06, 2009 at 09:09:46PM +0400, Yury V. Zaytsev wrote:
> On Sun, 2009-07-05 at 03:04 -0700, Ben Jackson wrote:
> 
> > 7)  Something probably has to be done to allow the dictionaries to
> > be in a local path instead of always trying /usr/local/share/cuneiform
> > (applies to creating and loading).
> 
> I think that ~/.openocr/dicts is a good bet (the Cognitive guys are
> currently deprecating the use of trademarked "Cuneiform" in the project
> name).

What I really meant is that the internal file open routines take a filename
like "rec9.dat" and automatically add "/usr/local/share/" to the front.
So my program for creating user dictionaries calls CloseUserDictionary
to save it and it always tries to save it in /usr/local/share.  Even if
there is a leading /, or if you can't write to /usr/local/share.  Adding
a user path is a good idea for working around it, though.

> P.S. Did you actually reverse engineer the *.dat files?

Somewhat.  As I described in bug 388926 I know what's going on in the
rec9*.dat files.  The concept of "user dictionaries" already existed in
the code, though.  It just looks like there's no UI for it.  So I do know
a bit about what goes into those files (which I was calling '.voc' since
the code to manipulate them internally is voc_* for 'vocabulary').  What
my program actually does is call API functions to add words.  The rest
of the work was figuring out how to get from PUMA_* all the way down so
that you could specify --dictionary on the cuneiform command line.

-- 
Ben Jackson AD7GD
<ben@xxxxxxx>
http://www.ben.com/