Dictionary Removal?

[berard]

I'm hoping this will be an easy one, but I've looked into this a bit over
the years, and have never been able to figure it out.

Our writing incorporates a medical spelling dictionary. This loads in
fine, and is specified in the dcf.

The problem is we also have some internal styles that are getting
overridden by the standard English dictionary. Specifically, our
organization chooses to use "ie" and "eg" without periods. (The English
dictionary corrects them to "i.e." and "e.g.")

I've also tried to explicitly add "ie" and "eg" to our custom dictionary,
but it doesn't seem to override.

Does anyone know of a way to remove these from the standard dictionary, or
some alternative?

- keith

[ClayHelberg]

Hi Keith--

Have you tried using "spell -reject i.e." to explicitly instruct Arbortext to treat "i.e." as a misspelled word?

--Clay

[berard]

I have not... I'm guessing I could add these to an acl script in EditInit?
I'll give it a shot.

- keith

[berard]

Just a quick followup:

Thanks Clay, yes, that did work as expected. I'm still guessing that this
affects the actual Arbortext installation, and once run, it won't be
overridden by subsequent patches. For our deployment, however, it still
does benefit from having this sent out in a patch for all users.

I tried adding it to a script in my init dir, but it wasn't able to use the
"spell" command prior to full initialization. I did put it in editinit,
and it seems to work fine. The only very minor concern is this is being
called every time a document is loaded, but it doesn't seem to be causing
any issue.

Thanks again,
keith

[ClayHelberg]

Glad it's working for you. FWIW, I think these entries get stored in aptspell.xml, in the Arbortext working directory (usually $userhome\AppData\Roaming\PTC\Arbortext\Editor). You can check there to make sure your editinit command isn't generating duplicate entries.

--Clay

[ClayHelberg]

Well, I just did a quick test, and alas, it does insert duplicate entries with repeated calls to the command. So every time you run editinit, you'll get some duplicate entries in aptspell.xml.

It looks like you can solve that issue by starting with

spell -delete i.e.

to remove all the old references, before inserting it (again). If you always do delete and then reject, you should be able to get just one entry in the custom dictionary for each term.

--Clay

[berard]

Great call... and yes, it is... back to the drawing board 🙂

<spellcache>
<acceptwords>
<word>ie</word>
<word>ie</word>
<word>ie</word>
<word>eg</word>
<word>eg</word>
<word>eg</word>
<word>eg</word>
<word>eg</word>
<word>eg</word>
<word>eg</word>
</acceptwords>
<rejectwords>
<word>i.e.</word>
<word>e.g.</word>
<word>i.e.</word>
<word>e.g.</word>
<word>e.g.</word>
<word>e.g.</word>
<word>e.g.</word>
<word>e.g.</word>
<word>e.g.</word>
<word>e.g.</word>
</rejectwords>
</spellcache>

[berard]

Oh, I guess I should have read your complete email before jumping into
it... I'll try delete now.

[berard]

Strange... delete seems to work if run in-session, but doesn't seem to
account for any old entries, so running the following in editinit doesn't
clear the existing entries if there from a prior session.

spell -delete e.g.
spell -delete eg
spell -reject e.g.
spell -accept eg

There might be something funky I could do on document close that I could
run delete at that time, but now I'm curious if I can put a version of the
aptspell.xml in my custom deploy somehow... hmm....

I liken the Arbortext API to peeling an onion, I'm sure I'll hit the core
at some point.

[ClayHelberg]

Hi Keith--

Hmm, that's odd. I didn't try running it from a script.

You might want to look into the APTSPLREJECT and APTSPLACCEPT environment variables, that might be the easiest way to achieve what you want. You should be able to put a couple of word lists (one for accept, one for reject) on a network share somewhere and have everyone pick them up.

--Clay

[lbisson-read1]

Have you tried putting aptspell.xml in the Arbortext-path\custom\dictionaries subdirectory?

From help: The custom\dictionaries path is automatically prepended to the dictionaries path at startup. Putting your user-defined dictionaries in the custom\dictionaries subdirectory makes them automatically available, avoiding manual steps to add them to the path.

[berard]

It doesn't seem to read the aptspell.xml from that directory. I can add in
custom dictionaries in there that are generated using userdict.exe and
specifying the dictionary in the Options tag of my DCF, but those entries
seem to be additive, and do not remove standard terms as the aptspell.xml
does.


On Wed, Feb 26, 2014 at 11:01 AM, Lisa Bisson-Read <
lbisson-read@terraxml.com> wrote:

> Have you tried putting aptspell.xml in the Arbortext-path
> \custom\dictionaries subdirectory?
>
> From help: The custom\dictionaries path is automatically prepended to
> the dictionaries path at startup. Putting your user-defined dictionaries in
> the custom\dictionaries subdirectory makes them automatically available,
> avoiding manual steps to add them to the path.
>

[LynnHales]

Why not just go into the aptspell.xml and make the changes you want?



Lynn

[berard]

Lynn,

The main issue is that we have a couple dozen authors located across 5
timezones all with varying schedules. Prior to the customized install, we
used to send out manual "patches" but found that not everyone was
installing them. Having Arbortext automatically get its latest custom.zip
on startup has been a great solution to this problem.

The other thing is this just adds to the list of things that would need to
be done when someone gets a new computer. Just seems like there should be
a way I can get it set as part of the normal custom deployment.

But yes, certainly an option. At the moment, I've sent instructions to at
least our copy-editors to manually enter the "spell -approve/reject"
entries manually on the command line.

- keith

[LynnHales]

If you are sending out a 'custom.zip' file add the spell file to the zip.
The custom changes to spell seems to be something one time. Not saying
individual users may not be adding, but this would be a baseline to work
from .

Just my two cents.

Now if everyone has access to a common network location, you could place the
custom spell file there and then somehow enforce having the users set that
path.



Lynn

[berard]

Could you elaborate on this? What file, and where in the zip?

aptspell.xml in custom\dictionaries does not seem to work
adding items to a custom dictionary using userdict.exe does not remove bad
suggestions from the "standard" dictionary
adding "spell -accept/-reject" to a script adds multiple entries to the
main aptspell.xml

Are you thinking of some other option?

(Also, common network location is not always available, as users may not be
online (eg: travel on a plane))

- keith

[LynnHales]

You mentioned sending out a 'custom.zip' file. I was thinking if you did
send out such a file you could add the spell file to this distribution.

Editing the spell XML file could be done in Epic (or an ASCII editor if
you're really into the dirt).

You might experiment with manually changing the spell.xml with a combination
of 'spell -reject' in a script.

Given the excessive number of unique words in the US DOD, I don't even try
to use the custom dictionary. I'm just thinking out loud.



Lynn

[BrianJ]

Don't know if my setup is helpful to you or not, but here it is.

We have the aptspell.xml set by the environment variable to be in our
custom/appdata directory. That way it is in the custom directory that
gets set on each user's machine when they start Editor. Editor starts
from a batch file that sets the environment variables we need. It also
updates any of the files in the custom directory that have changed.

The aptspell.xml file only has rejected words, not accepted words. We
have a custom user dictionary file in the custom/dictionaries directory,
that provides for words that Editor by default marks as misspelled but
are correct for the client (a state legislature). The words in this file
are maintained using a java GUI application (that ultimately wraps ACL
to actually manage the lists) I created to view, add and delete the
words. Normal users don't have the ability to manage this list, nor do
they have the ability to add words using the spell command, as we
aliased the command and customized the Spell dialog box to allow them to
request a word be added to the accept list. So calling it a user
dictionary file isn't really accurate, since it's the same list for all
users.

If I remember right, you were looking to have "ie" and "eg" to not be
marked as misspelled, and for "i.e." and "e.g." to be marked that way.
In our case, we would add "i.e." and "e.g." to the reject list in the
aptspell.xml file, and add "ie" and "eg" to the user dictionary file.

One thing to note about the rejected words list, using a kind of funny
example from the real world; we had a need for the word "pubic" to be
marked as misspelled since, despite being a real word, it was often
being typed in mistakenly for "public" (again, state legislature here,
so that was a commonly needed word). We needed to account for pubic,
Pubic, and PUBIC, making sure they were all marked as misspelled. I
found the only way to correctly do that was to have them in the rejected
word list in exactly that order (pubic, Pubic, and PUBIC).

Hope that helps,



Brian Jensen
bjensen@bluelid.com

[berard]

Yeah, our custom dictionary has about 390k medical words in it, so I prefer
not to mess with it directly either, but it does load fast and works great
once compiled by userdict.

As for custom... I was referring mainly to Arbortext's ability to
automatically download the custom directory on load. This is setup by
creating a custom Arbortext installer, or by modifying the deploy.xml
located in lib.
<deploy resource="&lt;br"/>

This installs custom into some weird folder:
<userdir>\AppData\Local\PTC\Arbortext\Editor\.aptcache\zc\1 (or 2, as you
switch between patches)

Worth looking at if you ever need that sort of thing for code deployments.

[berard]

Ooh, yes, I think I'll play with this a bit.

We currently use an env variable set in siteprefs.xml to point to the
license file:
<environmentvariables><variable name="PTC_D_LICENSE_FILE"&lt;br"/>value="c:\ptc\license.dat"/></environmentvariables>

I'm not certain if this will directly help me with our custom deploy, as
it's in an ever-changing directory of Arbortext's choosing:
<userdir>\AppData\Local\PTC\Arbortext\Editor\.aptcache\zc\1 or 2

But it might just default to custom being the relative path, so it's a
whole new avenue to explore.

To your point of adding "ie" and "eg" to the dictionary... I think that's
also a good idea, since that might also help with suggested replacement.

Thanks, I'll let you know how it goes.

(On a side note, I have a strong feeling that for our work, PUBIC is
probably more common/desirable than PUBLIC in most case, ha!)

- keith