Am 30.08.2010 um 14:42 schrieb Jürgen Spitzmüller:
> Also sprach Stephan Witt:
>> Am 30.08.2010 um 13:07 schrieb Jürgen Spitzmüller:
>>> Stephan Witt wrote:
>>>> I removed one FIXME which is outdated and one that might be still valid.
>>>> Perhaps I should have mentioned this, but I don't think that this should
>>>> be customizable.
>>>
>>> I think it should. This is a common customization option for
>>> spellcheckers (you can customize whether to check words with digits or
>>> not, amongst others, in Ooo and MS Word).
>>
>> Interestingly.
>> The comment claims that hunspell (used by Ooo AFAIK) ignores words with
>> digits...
>
> ..."by default". Which means you can change that behaviour, I suppose.
Maybe. By studying the hunspell.hxx file I couldn't learn how...
I found no argument to the spell() function and no option setter function.
Perhaps it is left as an exercise to the open-source community. :-)
>
>> But I have no problem to let the FIXME survive.
>>
>> Nevertheless I'd see a problem to implement it. Since different spell
>> checker engines behave differently here. Apples engine ignores these words
>> too.
>
> Why? We have different spelling engines. These will need to take care if/how
> the respective speller's setting will have to be changed.
>
>> BTW, the word LyX is correct for apples spell checker :-)
>
> by default? :-)
Yes. I think it ignores all words with mixed case by default.
>
>>> Rather than searching for specific special char insets, I'd rather check
>>> for inset->isLetter(). That's what the spellchecker in branch does (via
>>> the now obviosuly ditched function Paragraph::isLetter).
>>
>> Aha, thanks. I realized that it's as simple as this:
>> If a char at pos is not a word-separator but an inset then is has to be
>> handled like soft-hyphen et. al.
>>
>> So it is like that:
>>
>> while (last < to && !owner_->isWordSeparator(last)) {
>> if (owner_->getInset(last)) {
>> // do something about soft-hyphens or ligature-breaks
>> }
>> ++last;
>> }
>
> Hm. I'm not sure. Anyway, if isLetter is not the correct attribute (I'm not
> sure about that myself, but I know that JMarc knows), we should create an
> appropriate inset/character attribute for the given purpose.
I'd like to hear JMarcs opinion and suggestions, too. Don't know how long he is
off...
Stephan
