Hi,

The support for spellchecking words with numbers is not 
complete in any way. I do not recommend you use that feature 
except as final proofing.  The problem is that valid numbers
can be represented in so many different ways that it is actually 
very hard to exhaustively handle numbers correctly by anything 
other than ignoring them.

For example:  The following are all valid depending on your locale:

$1,000,000.00 (insert all currency markers either at the beginning or end)
69.45%
0000254
10,00,00.0000
7245,67  (differnt radix)
+1.758E-52
-1.758e+104
10+i45  (complex numbers using i or sometimes j or ... )
-945 + j78 

And add to this list all of the possible time and date formats!

Of course you then have to worry about all combinations of those as well.

The key is that these are all pure numbers as well but they come out 
as mixed text.

So I have thought about this but since there are an infinite number 
of numbers and many many "valid" formats to fit them in, it is really
hard to separate out valid numbers from other numbers and mixed text.

If you would like to contribute a patch to add this feature and somehow
properly  identify all possible valid numbers that would work for 
multiple locales, encoding, radii, currency symbols, etc I would of course
be willing to include it.

But short of that, The only solution I can think of would be to ignore
any word made up purely of:

0-9,:./-+%$ (and all of the other currency markers) 

But then what about nonsense like: 999$./45%,87---++38$

So either I only recognize integers without currency or date or time 
indications, or I must allow more and then at what point do I cut off.

So right now, I do not recomend using spell check words with numbers
all of the time and instead, turn it on at the end during proofing 
and ignore all of the correct numbers that are underlined and look
for incorrect words.

That seems like the safest thing to do.

Kevin

I see the dilemma, I'll get back to you if I come up with anything 
useful.

How about using the function that OOo Calc uses to identify numbers?
That identifies many of your examples, except for complex and 
different radixes.

Hexadecimal numbers should flag incorrect anyway, ACDB is valid hex, 
but is probably a mistake. And (at least in NZ locale) commas are 
treated as delimiters so 7245,67 would be treated as two plain 
numbers.

But I do see your point, and there's definitely no rush to solve the 
issue :) thanks

Hi, 
 
I think this would be a good project for 1.1.1 and on towards 2.0 for lingucomponent. 
 
So I am setting that target. 
 
Thanks gain for your bug report. 
 
Kevin 
 
 

Hi,

FYI: targeting a solution for this to the 1.1.X series of builds (hopefully).

Thanks,

Kevin

Hi,

A fix for this is too late for 1.1.1 but should defeintely be available for a 1.2 or 
however we do pre-2.0 releases.

Thanks.

Kevin

Changing this to "started"

Kevin

*** Issue 76019 has been marked as a duplicate of this issue. ***