cf upstream bug
I wonder if the problem is the dialog deciding not to show them, of if we are
mangling multiple styles together.
The bottom-most layer is finding them all, and knows they are all Deja Vu Sans,
e.g. see vim ~/.openoffice.org2/user/psprint/pspfontcache so we have it right at
the bottom, we're loosing it somewhere between font detection and UI.
FontStyleBox::Fill in svtools/source/control/ctrlbox.cxx is a good place to
start looking at this.
IIRC fonts have two style fields : a legacy one with the 4 legacy styles and a
new one with more possibilities. Somewhere in OO.o code the fonts must be
accessed through the legacy field, which puts all bold variants together, all
italic variants together, etc.
That it shows 5 styles not 4 is probably because extralight is not sharing the
same font name as the other variants.
sent a proposed patch upstream and added it to fedora cvs, will be in next build.
but I will pull it if there is some unknown side-effect that I'm currently
unaware of that is a reason why we don't already do this.
openoffice.org-2.2.1-18.1.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
Done in rawhide as 2.2.1-18.8.fc8, e.g. DejaVu LGC Sans shows a stack of 9
Unfortunately it doesn't work altogether. If you select Condensed (or variants
of Condensed like Condensed Bold) you get the normal Book version instead of the
expected Condensed one. Strangely enough ExtraLight gives you what you would expect.
This also applies to the font selected via GNOME's control center. If you
selected DejaVu LGC Sans Condensed for the UI then OO.o will use DejaVu LGC Sans
Book for its UI. If you selected DejaVu LGC Sans ExtraLight then OO.o will use it.
The upstream issue covers this topic and related subproblems, various other bits
of OOo need to change their assumptions, a larger scale task than I can
undertake on my own.