• State Verified Answer
  • Replies 8 replies
  • Subscribers 101 subscribers
  • Views 4796 views
  • Users 0 members are here
Options
Related

Custom dictionaries

Chris Leggett

OK this is complex and I need to understand the exact procedures and process.

1. If your job ticket has "Algorithm" a "Main Dict" and a "Cust Dict" I need to understand what decides which is used. In the manual it says:

A Hyphenation Exception dictionary stores words only if they have hyphenation breakpoints specified
and the hyphenation is different than that specified by the Main dictionary or algorithm. If you do not want
the word to hyphenate, you enter a slash after the word and before the hard return.

However later on, when talking about the trialing slash it says: 

This character forces each word to be added to the Custom dictionary even
when its hyphenation exactly matches the hyphenation found in the Main dictionary.

So i deduce that if I enter a word with the same hyphenation points as the Algorithm or Main Dict then it just ignores it (does not store it in the custom dict) and uses the Algorithm or Main Dict. However if I put a slash at the end of the word in my Custom Dict then it will use that regardless if it is the same or not. If I do not want a word to hyphenate at all then I must put a slash at the end of the word. Is this correct?

So lets say the main dict has abc$def$gh but in my custom dict I put abcd$efgh will it always use the custom dict even if there is no slash or, as a matter of course should I put abcd$efgh/ to make sure it always uses my preferred option?

2. The manual also says:

If you enter the word in all lowercase (think) it will work with each of the following different words:
think
think.
Think
Think.
THINK
THINK.

The next silly question is what happens with nouns that sometimes have and apostrophe s at the end of the word - is this catered for as above or is it required to add a separate entry for say Mon$day and Mon$day's?

3. Has anyone seen an instance where the above rule does not cater for the cap initial letter?

Don't like to make them too easy folks!

PS XPP 8.4.1 in XML using item formats.
Rate translation
×
Suggest better translation
×
  • 0

    Hi Chris,

    I think I can answer at least some of your questions definitively and comment somewhat on others.

    First thing I want to say though, is that with the very old XPP 8.4.1 release you reference you may run into "bugs" (such as with handling of words with an apostrophe and words with initial caps) that have since been fixed. Problems got introduced along the way as we converted XPP to Unicode and then also the third-party Proximity hyphenation package that XPP uses had some fundamental changes in it (which introduced some bugs as well). So take that into account with my responses.

    1. Yes, there are basically two reasons for using a trailing slash in a dictionary word list.

    The most common case is when you want to prevent a word from hyphenating at all (and not use any Main dictionary nor Algorithm hyphenation points) - you enter the word in your source dictionary word list with no hyphenation points and a trailing slash. Of course, that won't do anything unless you then specify to use the Custom dictionary that you build from that list. For hyphenation, words are always looked up first in the Custom dictionary (if specified), next the Main dictionary, and last the Algorithm is used.

    The second case is for the more unusual situation in which the user is building their own "main" dictionary, i.e. in the JT the user specifies the name of a Custom dictionary in the Main Dict field (which obviously needs to be named differently than the name of the delivered Main dictionary). Yes, XPP allows you to do that. However, when doing Build Hyph the utility does not know that you are going to do that so it is always comparing the specified hyphenation points in the source word list with the Main Dict and Algorithm results (for the specified language) - and dropping/ignoring words with the same hyphenation. So, in that case the words in the source dictionary list will typically all have trailing slashes entered on them to make sure to "force" them into that Custom dictionary that's going to be used as a "main" dictionary.

    Chris Leggett said:
    However if I put a slash at the end of the word in my Custom Dict then it will use that regardless if it is the same or not.

    You have to separate in your mind the process of creating the Custom dictionary versus the process of using the Custom dictionary for hyphenation. The trailing slash is only relevant to the creating (or building) of a Custom dictionary as to whether words (with or without hyphenation points) are forced into the dictionary. Later during composition, the "lookup rules" (according to what is specified in the JT fields) determine what dictionary entries get found and get used.

    2. As far as words with apostrophes, I suggest that you try some tests to see what you get (but with the caveat I mentioned up front about "bugs" that have since been fixed - and some of them somewhat recently). From a quick look at the Proximity code, I see somewhat obvious "apostrophe handling" for only some languages (English, French, Italian). I'd have to dig deeper to see what exactly that means, but trying some tests is probably a better/faster approach.

    3. Specifically, the apostrophe stuff may or may not play well (automatically) with the initial cap and all caps cases - I just don't remember. Or that might be one of the "bugs" that was fixed.
  • 0 in reply to Jonathan Dagresta

    Thanks Jonathan - I think that helps a lot - and explains some of what we are actually seeing as opposed to what we expected to see (especially with the apostrophes). Is there a patch for 8.4.1 which addresses the dictionary "bugs"? If so I would be interested in having that and seeing if the result we are seeing change. Your answers to 1. above make absolute sense and confirm what I expected (had not thought of using an exception dictionary as the prime dictionary - sounds as if that is asking for trouble).
  • 0 in reply to Chris Leggett

    As far as fixes and patches for XPP 8.4 that might be available, you'll have to contact Support. I no longer have access to any of that information for such an old release.

    Looking through my very brief notes on some of the issues I've worked on, I see now that some of the "bugs" I mentioned were opened specifically against Spell Check and so might or might not be relevant to your hyphenation use case (only some code is shared between hyphenation and spell check).

    If you still think you're seeing bugs, then definitely you'll need to open a ticket with Support. Just know that right now we're only providing (new) patch support for XPP 9.3 and later (and once XPP 9.6 is released later this year there will only be patch support for XPP 9.4 and later).
  • 0 in reply to Chris Leggett

    Ah, okay. I don't see anything relevant for patches for 9.4.1 (or later).
  • 0

    Note: In case anyone is interested a bug was just identified (via a customer ticket) with the hyphenation of apostrophized words.

    If you have "mon$day" entered in your custom dictionary then for the English/French/Italian languages it is supposed to handle giving the custom hyphenation for apostrophized words like "Monday's" w/o having to also separately enter "mon$day's" in the custom dictionary.

    We've discovered that this is not working correctly, if the case of the apostrophized word being hyphenated (from the XPP page) does not match the case of the “base” word as it was entered in the custom dictionary. 

    So, if the custom dictionary has the base word entered as “mon$day” and the apostrophized word being hyphenated is “Monday’s” or “MONDAY’S”, then the hyphenation goes bad (and for this example, the word could get hyphenated as "Mo-nday's"). If the custom dictionary has the base word entered as “Mon$day” and the apostrophized word being hyphenated is “monday’s” or “MONDAY’S”, then the hyphenation goes bad (in the same way).
  • 0 in reply to Jonathan Dagresta

    Hurraaaay - not that there is a bug, but that I am not going mad! This was really baffling us. Thanks for the update - looking forward to downloading a patch and testing!
  • +1

    Update: This bug has now been fixed. Reference is CRQ-24962 if you need to request a hot fix.