Issue 5884 - Fonts without o+r permission make OpenOffice malfunction
Summary: Fonts without o+r permission make OpenOffice malfunction
Status: CLOSED DUPLICATE of issue 1872
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 1.0.0
Hardware: PC Linux, all
: P3 Trivial (vote)
Target Milestone: OOo 2.0
Assignee: philipp.lohmann
QA Contact: issues@framework
URL:
Keywords:
: 5883 (view as issue list)
Depends on:
Blocks:
 
Reported: 2002-06-16 13:04 UTC by wine
Modified: 2003-04-02 11:01 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 wine 2002-06-16 13:04:17 UTC
L.S.,

If users don't have read-permission to fonts in the OpenOffice font directory,
OpenOffice crashes, hangs or has serious interface quircks.

Spadmin currenty doesn't (fully?) check font permissions and ownerships (issue
5883), but manually added fonts may have the same inconsistencies, so perhaps
OpenOffice should check on startup and ignore fonts with bad perms/owns while
alerting the user of this event.

Best Regards,

Maarten Wijnen
Comment 1 thorsten.martens 2002-08-01 10:08:20 UTC
TM->US: Don`t really know if this is your turn to have a look at. But
due to the fact that 5883 is a very common problem and that issue is
owned by sba, please have a look, thanks !
Comment 2 ulf.stroehler 2002-11-29 11:50:02 UTC
us: when the UI font has permissions 000, OOo starts without UI font.
Perhaps not the ideal behaviour.
Comment 3 ulf.stroehler 2002-11-29 12:11:16 UTC
*** Issue 5883 has been marked as a duplicate of this issue. ***
Comment 4 philipp.lohmann 2003-01-23 12:30:36 UTC
I won't built in a read check for every font on startup; that would
slow down office startup several seconds (depending on how many fonts
are on the system) and the startup is slow enough as it is. I will
build into spadmin a check of the fonts inside OOo.
Comment 5 philipp.lohmann 2003-04-02 11:00:52 UTC
the same issue is handled in issue 1872

*** This issue has been marked as a duplicate of 1872 ***
Comment 6 philipp.lohmann 2003-04-02 11:01:37 UTC
closing duplicate