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 <[email protected]> http://www.ben.com/ _______________________________________________ Mailing list: https://launchpad.net/~cuneiform Post to : [email protected] Unsubscribe : https://launchpad.net/~cuneiform More help : https://help.launchpad.net/ListHelp
