Issue 5960 - Spellcheck will not catch errors with certain fonts
Summary: Spellcheck will not catch errors with certain fonts
Status: CLOSED FIXED
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: OOo 1.0.0
Hardware: PC Linux, all
: P3 Trivial with 1 vote (vote)
Target Milestone: ---
Assignee: ulf.stroehler
QA Contact: issues@sw
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-06-19 01:26 UTC by Unknown
Modified: 2013-08-07 14:41 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Unknown 2002-06-19 01:26:13 UTC
Installed OpenOffice.org 1.0 from clean tarball.  On both -net install and
single-user installs, using the default font Thorndale, the spellchecker will
miss word that are misspelled.  If the font is changed to a normal font, then
the spellchecker will work.  However, if you use the drop down box, and the font
has "!2CTev" and two other odd characters after it, anything in that font will
be missed by the spellchecker.

Further, in the -net installs, if you change the font then spellcheck twice,
OpenOffice.org will crash.

None of these problems appear in the spreadsheet spellcheck.  It works fine for
all fonts.

I know this sounds crazy, but on my test machine, I can replicate this over and
over and over.  It's driving me batty.  I'm having a user with a similar
problem.  Argh!
Comment 1 khendricks 2002-06-19 16:27:35 UTC
Hi, 
 
Yes, I have seen this exact same thing before I had a priner 
attached to my machine.  The problem is that when specific fonts do 
NOT exist on a system, the OOo code tries to use whatever graphics 
device is available to create it (typically it talks to the printer 
so that the screen in Writer can do real WYSIWYG and the printer and 
the screen font metrics and things are in sync. 
 
Sometimes (and I haven't figured out why yet), this "created" 
replacement font is created as a SYMBOL font (like zapf dignbats, 
etc) that the spellchecker is set up to ignore. 
 
 
Thorndale is the default but it does NOT exist on most OOo systems 
(it only comes with StarOffice). 
 
So you might try using spadmin to remove any fonts that do not 
actually exist on your system to prevent them from being used.  This 
is supposed to happen on startup by takling with the graphics device 
but for some reason this does not work (and never has as far as I 
can tell). 
 
IMHO, Thorndale should NOT be the default font under OpenOffice.org 
since it is practically guanranteed not to exist on any Linux / 
Windows box that does not have StarOffice already installed on it. 
 
Hope something here helps, 
 
Kevin 
 
 
  
Comment 2 Unknown 2002-06-19 16:52:53 UTC
Kevin,

That actually makes alot of sense.  The only thing that throws me is
why   all the fonts work in the spreadsheet, but not in the word
processor.  Perhaps the spreadsheet doesn't recognize symbol fonts, so
it doesn't treat them as symbol fonts?  I don't know.  Your answer
makes the most sense of anything I could come up with.  Thanks!
Comment 3 eric.savary 2003-01-31 11:38:54 UTC
ES->US: Any statement on this?
Comment 4 ulf.stroehler 2003-02-28 16:08:29 UTC
us->tl: if I remember correct you fixed this for beta, didn't you?
Comment 5 thomas.lange 2003-03-03 12:38:28 UTC
TL->HDU: To you to comment.
Comment 6 hdu@apache.org 2003-03-03 13:00:03 UTC
HDU: The "!2CTev" fonts have the "symbol attribute" set. For some 
reason these fonts are considered to be symbol fonts. Maybe they 
have a funny encoding mentioned in the related fonts.dir file. 
Please provide the fonts.dir of the directory where one of these 
fonts live that shouldn't behave as symbol fonts. 
 
The other problem might be that Thorndale falls back to a "random 
font that is early in the font list" is probably related to 
#107485#, which gets fixed in CWS VCL06. The reason behind this is 
in vcl/source/gdi/outdev3.cxx's ImplDevFontList::ImplClear() method. 
This method needs to get a line "bMatchData = FALSE;" 
 
Comment 7 khendricks 2003-03-24 18:32:30 UTC
Hi, 
 
Is this now fixed? 
 
Anyone know? 
 
Kevin 
 
Comment 8 hdu@apache.org 2003-07-10 15:14:33 UTC
There are two ways how this could have happened:
- #107485#, which is fixed since CWS VCL06.
- an unidentified encoding in a "fonts.dir" file
Since we haven't heard anything for four months on this second
possibility, we have to assume that everyone only encountered the
first problem.
Comment 9 hdu@apache.org 2003-07-10 15:15:26 UTC
HDU->US: Time to verify in a recent build and close...
Comment 10 ulf.stroehler 2003-11-06 15:41:31 UTC
@submitter: pls. verify in OOo 1.1 and comment. Thanks.
Comment 11 ulf.stroehler 2004-01-09 11:48:25 UTC
Changing resolutio to FIXED.
Comment 12 ulf.stroehler 2004-01-09 11:49:38 UTC
Fixed in OOo 1.1.
Closing issue.