Issue 79878 - OO.o can not select modern font faces conveniently
Summary: OO.o can not select modern font faces conveniently
Alias: None
Product: ui
Classification: Code
Component: code (show other issues)
Version: OOo 2.2.1
Hardware: All All
: P3 Trivial with 20 votes (vote)
Target Milestone: 4.x
Assignee: AOO issues mailing list
QA Contact:
: 26012 42835 45358 82986 87708 88796 89380 111891 114158 (view as issue list)
Depends on: 80424
Blocks: 2867 81913 97765 123037 43495 82986 103417 111108
  Show dependency tree
Reported: 2007-07-22 14:08 UTC by nmailhot
Modified: 2017-05-20 10:44 UTC (History)
20 users (show)

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

picture with following patch applied (42.89 KB, image/png)
2007-07-24 13:19 UTC, caolanm
no flags Details
this patch propogates the widthtypes into the attributes used to compare fonts to eachother (678 bytes, patch)
2007-07-24 13:20 UTC, caolanm
no flags Details | Diff
proposed dialog in action (28.91 KB, patch)
2007-10-15 08:20 UTC, Giuseppe Castagno (aka beppec56)
no flags Details | Diff
proposed patch (6.95 KB, patch)
2007-10-15 08:22 UTC, Giuseppe Castagno (aka beppec56)
no flags Details | Diff
A (very) small test-bed (14.33 KB, application/vnd.oasis.opendocument.spreadsheet)
2007-10-15 08:23 UTC, Giuseppe Castagno (aka beppec56)
no flags Details
screenshot showing the problem (99.92 KB, image/png)
2008-06-02 16:07 UTC, meywer
no flags Details
file with trouble (14.09 KB, application/vnd.oasis.opendocument.presentation)
2008-06-02 16:08 UTC, meywer
no flags Details
Basic support for font stretch in sfx and above. (37.94 KB, patch)
2008-08-11 07:09 UTC, dtardon
no flags Details | Diff
Import/export of font stretch to/from ODF. (16.10 KB, text/plain)
2008-08-11 07:10 UTC, dtardon
no flags Details
Fix of VCL to really use font stretch for font selection. (2.61 KB, patch)
2008-08-11 07:13 UTC, dtardon
no flags Details | Diff
Testing file containing all possible values of font stretch. Unfortunately, DejaVu font contains but one alternative stretch (semi-condensed), so there is not much to see. (6.93 KB, application/vnd.oasis.opendocument.text)
2008-08-11 07:18 UTC, dtardon
no flags Details
Independent selection of Posture/Weight/Stretch in Format->Character dialog (115.60 KB, patch)
2008-09-03 08:24 UTC, dtardon
no flags Details | Diff
Font Style mockup - Font Features (45.58 KB, image/png)
2009-09-09 11:13 UTC, aynadamar
no flags Details
screenshot font selection (39.94 KB, image/png)
2010-02-02 14:47 UTC, Peter
no flags Details
Fedora 14 currently ships some pre OO3.3, there I can select Dajavu Narrow... (80.27 KB, image/png)
2010-07-28 07:45 UTC, fmms
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description nmailhot 2007-07-22 14:08:58 UTC
OO.o can not handle fonts with more than the 4 legacy styles (regular, bold,
italic, bold-italic) under Linux

This is a big problem as the font currently emerging as default for all
distributions (Dejavu Sans, provides many more variants :
- extralight
- condensed
- book
- condensed oblique
- oblique
- condensed bold
- bold
- condensed bold oblique
- bold oblique

Presented with such a font (that will be installed by default on most current
Linux distributions) OpenOffice fails miserably :
1. it will only show a style subset, and hide the others to users
2. its style selection is quite suboptimal (extralight, book, condensed oblique,
bold, bold oblique)
Comment 1 Olaf Felka 2007-07-22 15:31:24 UTC
Please have a look.
Comment 2 caolanm 2007-07-24 13:19:41 UTC
Created attachment 47030 [details]
picture with following patch applied
Comment 3 caolanm 2007-07-24 13:20:26 UTC
Created attachment 47031 [details]
this patch propogates the widthtypes into the attributes used to compare fonts to eachother
Comment 4 caolanm 2007-07-24 13:21:48 UTC
We seem to read the widthtypes, but we don't seem to pass it around much. I'm
unsure if this is intentional in vcl, or if it is an oversight. 

cmc->pl: Is there a reason we don't already set the WidthType like we do for the
Weight/Posture ?
Comment 5 philipp.lohmann 2007-07-25 13:06:33 UTC
good question, hdu will be able to answer that when he's back.
Comment 6 2007-08-07 14:45:06 UTC
@CMC: good catch! Thank you. For the specific WidthType problem I opened issue 80424 and applied your 
patch in CWS vcl82

OOo's code can handle all the other cases, but there is no UI to select them. E.g. the "bold" button only 
selects between two different weights even though many more are available. Making all available styles 
selectable in the UI is an interesting task for the UI team. The UI for font selection needs to be updated to 
todays requirements: 
- many font families consist of more than the four traditional styles
- on many systems there are hundreds or thousands of different font families and the current font listbox 
is a pain to work with in this situation
Comment 7 nmailhot 2007-08-11 10:15:04 UTC
The UI part should start from this :
Comment 8 ralphie 2007-08-11 13:31:06 UTC
I think the issues 2867 and my 43495 are duplicates of this issue.
Comment 9 2007-08-13 13:40:44 UTC
@ralphie: yes, issue 2867 and issue 43495 have the same root cause. Once a UI for this issue is specified 
and implemented they will be solved too. I updated the issue dependencies accordingly.

@nmailhot: Thank you for providing this very interesting link!

@requirements: While working on this issue please also have a look at issue 16032 (UI for OpenType 
features). Since the concepts of font styles and OpenType features are somewhat related maybe they can 
be seamlessly solved at once?

@mba: bh mentioned that you triage issues like this?
Comment 10 82obuu4j 2007-08-13 15:07:05 UTC
Don't know if this helps, but OO.o on Windows does it right.

Comment 11 nmailhot 2007-08-13 15:35:47 UTC
@hdu Glad you like it

Ed Trager has posted more recent material on the same subject there: (the Fontima stuff)
Comment 12 Giuseppe Castagno (aka beppec56) 2007-10-15 08:20:26 UTC
Created attachment 48895 [details]
proposed dialog in action
Comment 13 Giuseppe Castagno (aka beppec56) 2007-10-15 08:21:57 UTC
After some exchange on this thread:
I spent some time to dig into the way of font listing made by fontconfig, I
discovered IMHO that though fontconfig uses the TrueType font file data to give
the application a possibility to group the fonts by Preferred Family (for
preferred family grouping) and Preferred Subfamily (for preferred family
grouping), OOo UI is not ready for that at the moment, so aren't some of the
oldest TrueType fonts still around today (among them some proprietary I bought
for professional reason).

My proposal, at least for the time being, is that we stick with the current UI
with the four available standard styles usable and use the grouping provided by
the font designer (see the previously attached screenshot).

The patch I'm going to attach is addressing this issue in Linux platforms that
use fontconfig.
The patch is m233 based, but I applied it without problem to 2.3.0.
What happens when fontconfig is not used is to be checked.

I'll attach a Calc test file I used to check for DejaVu fonts in both Linux and
Windows platforms, just to see if the font naming was consistent between the two.

I checked with the proprietary fonts I have and all of them are now visible on

To obtain the correct style name a small correction to the TrueType name table
discovery procedure was needed (fontmanager.cxx). Please check if the string
conversion is all right, especially the returned value for Apple in sfc.cxx
(where the TT font file is scanned for names).
This little change has a side effect, though: the name of the font style are not
localized, since they are taken from the font file.

I added some comments where the relevant names are read from TT file, for posterity.

Before starting OOo with the patch applied, the font cache file <user private
configuration directory>/user/psprint/pspfontcache must be deleted (or check for
a way to do it).
Comment 14 Giuseppe Castagno (aka beppec56) 2007-10-15 08:22:59 UTC
Created attachment 48896 [details]
proposed patch
Comment 15 Giuseppe Castagno (aka beppec56) 2007-10-15 08:23:53 UTC
Created attachment 48897 [details]
A (very) small test-bed
Comment 16 Giuseppe Castagno (aka beppec56) 2007-10-15 08:24:30 UTC
Forgot CC myself...
Comment 17 ralphie 2007-10-15 08:57:13 UTC
Thanks a lot for your work, Guiseppe(?)! I am really looking forward to this!

Do you need a large PostScript Family for testing? I've got Adobe Garamond and
others withmany "strange" styles, would that help? I can't upload it, but if you
want, I think I can mail it to you for testing.

Also one observation on the dialog: The sentence on the bottom 
"The same font will be used on both your printer and your screen." is
rather redundant nowadays. I think a warning when this is not the case
would be more helpful, with a cleaner dialog in the "normal" case, i.e. 
one with this sentence removed.

Comment 18 nmailhot 2007-10-15 08:58:42 UTC

Please do not make modern clean fonts like dejavu behave like the old
proprietary fonts you bought. Your old fonts should be supported but not at the
cost of dumbing down support for new fonts.

GTK apps already have a font dialog that supports more than the four standard
legacy styles. Consistency with the desktop platform on Linux systems should be
preferred over consistency with another platform like windows. Especially when
one does things right technically and the other - not.

FYI Dejavu is being adopted as the default font by all major Linux distribution,
so any quirks in its support will be highly visible.

Your patch is a step backwards from the nice fix in issue #79878. The OO.o UI
should be made better, but better is not pretending than modern fonts are legacy
fonts, better is making style selection for modern fonts easier.
Comment 19 ralphie 2007-10-15 09:06:16 UTC
@nmailhot: I think you refer to the wrong issue! 

The more I think about it, the more I wonder what this patch will do to 
my Adobe Garamond, and mine is not even complete (the expert fonts with
rare ligatures and extra glyphs are missing): 


fc-list gives me the following:

client21% fc-list | grep Garam | sort
Adobe Garamond:style=Italic
Adobe Garamond:style=Italic Oldstyle Figures
Adobe Garamond:style=Regular
Adobe Garamond:style=Semibold
Adobe Garamond:style=Semibold Italic
Adobe Garamond:style=Semibold Italic Oldstyle Figures
Adobe Garamond:style=Semibold Small Caps & Oldstyle Figures
Adobe Garamond:style=Small Caps & Oldstyle Figures
Adobe Garamond:style=Titling Capitals
Comment 20 Mathias_Bauer 2007-10-15 09:09:16 UTC
Thanks for the patch. I forward it to the responsible developer.
Comment 21 Mathias_Bauer 2007-10-15 09:10:06 UTC
Philipp, I'm not sure if this is one for you or for hdu, but OTOH I'm sure you
will find an agreement. :-)
Comment 22 nmailhot 2007-10-15 09:16:10 UTC

I'm referring to the changes between

which is nice, even if the typeface column needs more work and

which is *not* nice as it breaks up modern fonts in sets of pseudo legacy fonts.
Comment 23 philipp.lohmann 2007-10-15 09:53:39 UTC
pl->mba: sorry, but the tenor seems to be not to apply beppec56's patch, but
instead improve the font selection dialog (which would be a task for os ?).
Caolan's patch is already integrated with issue 80424 to 680m231; which at least
should now make every substyle available to the user. For the grouping of fonts
(which apparently could be done with fontconfig) we'd need new interfaces
however and there is no idea how to implement such on other platforms.
Comment 24 Giuseppe Castagno (aka beppec56) 2007-10-15 10:16:09 UTC
@ralphie: the patch I worked out works for TrueType only, I'm not sure of what
happens with Type1 fonts you mentioned in desc20 above, I have very few of them

@nmailhot: as I said in desc14 above:
My proposal, at least for the time being, is that we stick with the current UI
with the four available standard styles usable and use the grouping provided by
the font designer (see the previously attached screenshot).
I agree with you the solution you proposed in desc8 above is better, but I
needed a temporary solution for myself, so I though I shared it.
What I think correct would be to use the patch in desc15 to temporarily use what
is on the platform, at the same time start to think about a fitting UI.
Comment 25 nmailhot 2007-10-15 10:30:43 UTC
@beppec56 desc8 would be nice, but what I'm saying is that from my point of view
your patch is a regression compared to already-merged desc7
Comment 26 nmailhot 2008-03-07 12:42:39 UTC
I'm going to try to reword and summarise the problem in this comment.

1. When software was young fonts were sparse and their format limitative. One
typically had different font files and names per encoding and variant of the
same font, and all those files exposed different font family names. Applications
manipulating formatted text just had to expose a raw font family list to users,
and make minimal effort to regroup the most frequent variants/faces (regular,
bold, bold italic, italic) together. Font users browsed the raw font name list
and selected the right font file directly. Everyone knew the Microsoft font list
(for example, use Aral Black for an heavy font, use Arial Narrow for a condensed

2. Strong demand from artists led to creation of more complex fonts and font
formats. Modern fonts are no longer limited encoding-wise, faces are no longer
limited to regular, bold, bold italic, italic, and more critically they're no
longer exposed under different font names. All the faces declare the same font
name, and software is expected to provide users ways to select the face they want.

3. Those complex fonts were at first limited to expensive font collections, but
are now being commodized (indeed OO.o now ships DejaVu, which is a complex font)

4. After the success of its "core fonts for the web" initiative Microsoft
decided to use its new fonts as a commercial argument. So they're no longer
freely distributed, and alternatives to Windows, IE and Office need to propose
their own font offering. Since font names are protected, that means exposing
users to new font lists, where the workarounds they learnt in 1. no longer apply.

It is therefore becoming critical to revamp the font selection UI so :
1. it can expose to users all the faces of the complex fonts which are now
getting widely distributed
2. it can help them browse non-Microsoft font libraries, so they don't run back
to Microsoft products just because they can't manage anything but the commercial
fonts it bundles with its offerings

Fortunately the technical analysis has already been done as part of W3C OpenType
and probably other specifications. Selecting the right face inside a font family
depends on three parameters:
1. font slant (font-style, FontStyle): normal, italic, oblique...
2. font weight (font-weight, FontWeight): normal, bold, light...
3. font stretch (font-stretch, FontStretch): normal, condensed, expanded...

This classification is adopted by every major actor: (Web) (Windows) (Unix/Linux)

A reasonably universal and future-proof UI would therefore replace the current
font selection methods of
1. font family list + font variant list
2. font family list + bold and italic toggle
3. font family list + slant list + weight list + stretch list selectors

(ie treat slant, weight & stretch as selection axes like is already done for size)
Comment 27 Mathias_Bauer 2008-03-07 14:52:12 UTC
Philipp, Herbert, could you please comment on how we shall move forward with
this issue? It seems that at least no one denied that we have a problem here.

If we needed new interfaces, UI etc. I think it's time to decide whether we want
to do that and in which time frame. If something needs to be evaluated, planned,
decided etc. we should find out who is able to do that. I feel a little bit lost
here as font handling is not my area of expertise so I would really appreciate
if we could find a suitable owner for this issue.
Comment 28 2008-03-07 15:33:01 UTC
There currently is only one way to choose any of the available font styles: select the style field in the 
Format->Character dialog.

Unfortunately even this method fails as the code for the Format->Character dialog seems to be written 
with the assumption that there are only bold and italic can be switched on or off. The code for this 
dialog (svx/source/dialog/chardlg.cxx) also does some wild translation/tunneling of the font styles 
(into "posture items") whereas a more naive approach (to manage the styles by keeping the style names 
as they were provided by VCL) would have been more successful...

@mba: I suggest to first fix/extend the Format->Character dialog and adjust the users of this dialogs 
resulting posture items to handle arbitrary styles. When this is done I suggest to extend the UI so that 
selecting different styles is more intuitive than starting the dialog.
Comment 29 nmailhot 2008-03-07 18:55:56 UTC
@hdu: since font families are getting more complex, but the face number is still
somewhat limited, a short-term solution would indeed be to drop all the face
filtering OO.o does and drop the face list as reported by the system in the
Format->Character dialog.

Then you only need to agree on the sorting of this raw face list. A good
strategy would IMHO to sort faces by stretch, then weight, then slant, then name
(if the previous 3 parameters are not sufficient)

For a reasonably complex and common font family such as Dejavu Sans, you'd get
the following face list:

Condensed Oblique
Condensed Bold
Condensed Bold Oblique
Bold Oblique

with nice normal/italic/bold/bold-italic clusters as expected by users.

Of course mid-term face number may grow enough using an unique face list may not
be sufficient

The Microsoft paper proposes
filtering strategies if you do not want to expose raw font family/faces in the
dialog but want to rework what the fonts report.
Comment 30 caolanm 2008-03-10 18:22:59 UTC
My own (wild?) assumption is that we'd have to map the condensed etc. values
from the dialog to the existing vcl FontWidth enum, then add a new svx SfxItem
for this type of FontWidth, then fiddle the apps to be aware of that new item
and use it when requesting fonts from vcl so as to get the intended font.

Then it looks to me that we'd have to import and export the font width into our
format along the lines of how the referenced-by-our-spec svg format does it,
i.e. font-stretch of one of normal, ultra-condensed, extra-condensed, condensed,
semi-condensed, semi-expanded, expanded, extra-expanded, ultra-expanded values

What bothers me is that while there is one direct reference to svg:font-stretch
in the spec (there's is no mention that I can see in our actual code to
save/load this yet, so no hidden support for svg:font-stretch?) there's the
issue that there's no equivalent asian/complex variants, e.g. our file format
has fo:font-weight, fo:font-weight-asian + fo:font-weight-complex and
fo:font-pitch, fo:font-pitch-asian, fo:font-pitch-complex. And I assume that
font-stretch/font-width would have to follow that pattern.

I think we might need to ask the xml people where this fits into how fonts are
supposed to be described by our format to avoid any gotchas there.
Comment 31 2008-03-11 17:20:07 UTC
Yes, adding a new SfxItem for FontWidth and following up this change by adjusting the applications and in 
the format would solve most of the problems.

There might be (and there certainly will be) other stylistic differences in the same font family that cannot 
be expressed by the three stylistic attributes weight/slant/width. When the most urgent issue of handling 
different width styles is being addressed this should be considered, so we don't end up again with a too 
limited solution.

@cmc: do you agree that solving the current problem is in sfx and above layers?
Comment 32 nmailhot 2008-03-11 17:29:38 UTC
There are other differences but the problem is no one managed to define a
consistent classification of those other differences yet. This is why the MS
paper talks of WWS fonts and refuses to try to do automated processing of other
Comment 33 caolanm 2008-03-11 17:35:51 UTC
yeah, that's the way it looks to me anyway, whack in a new SfxItem e.g.
SfxFontStretchItem for shuttling the info about the place and clarify the
situation wrt. existing fo:font-whatever-[asian|complex] properties and the file
format's brief mention of svg:font-stretch for how it should be stored.
Comment 34 michael.ruess 2008-04-02 09:08:10 UTC
*** Issue 87708 has been marked as a duplicate of this issue. ***
Comment 35 michael.ruess 2008-05-13 11:57:47 UTC
*** Issue 89380 has been marked as a duplicate of this issue. ***
Comment 36 meywer 2008-06-02 16:04:59 UTC
In OOImpress DejaVu Sans troubles with unicode (?)
See following attachements

Comment 37 meywer 2008-06-02 16:05:10 UTC
In OOImpress DejaVu Sans troubles with unicode (?)
See following attachments

Comment 38 meywer 2008-06-02 16:07:15 UTC
Created attachment 54175 [details]
screenshot showing the problem
Comment 39 meywer 2008-06-02 16:08:35 UTC
Created attachment 54176 [details]
file with trouble
Comment 40 2008-06-05 14:56:36 UTC
*** Issue 42835 has been marked as a duplicate of this issue. ***
Comment 41 2008-06-05 15:00:05 UTC
transfering the "depends on" issue 81913 from the duplicate issue 42835
Comment 42 2008-06-05 15:16:11 UTC
*** Issue 26012 has been marked as a duplicate of this issue. ***
Comment 43 2008-06-05 15:29:04 UTC
*** Issue 88796 has been marked as a duplicate of this issue. ***
Comment 44 lohmaier 2008-07-16 23:34:03 UTC
*** Issue 45358 has been marked as a duplicate of this issue. ***
Comment 45 meywer 2008-08-09 12:04:34 UTC
Please have a look on issue 87710 too.
Comment 46 meywer 2008-08-09 12:22:57 UTC
In addition I want to remember (from issue 87708), that there is a problem using
older templates, which include DejaVu Sans Condensed as font, since now OO
doesn't know this font any more*), but gives the possibility to choose DejaVu
Sans and the font style "condensed" (which unfortunately at the moment doesn't
difer from style "book" (and also condesed bold = bold and so on) which is a bug
too I guess**) ).

*) says, the font still
exists. Seems that OO (or some part of linux) just doesn't recognise it. On the
other hand it would be very strange having a font "DejaVu Sans Condensed" and a
font "DejaVu Sans" with the style "condensed".**)

**) And right: says,
there is no style condensed(!) (In contradiction to the primary description of
this issue(!))

So OO (or linux?) should recognize DejaVu Sans Condensed as font (which maybe is
a problem of linux, not of OO) 
OO should not list "condensed" as available font-style for DejaVu Sans (wich is
a (new?) OO-bug)!!!

Comment 47 meywer 2008-08-09 12:26:43 UTC
forgot cc
Comment 48 dtardon 2008-08-11 07:07:30 UTC
I have been working on this problem and have managed to get basic support for
font stretch to oowriter + ODF. I've used fo:font-stretch for saving it (I know
ODF doesn't include fo:font-stretch, but I think we can take care of that
later). It's not yet possible to set it from inside of the app, however; you
have to use a hand-modified ODF input file.
Comment 49 dtardon 2008-08-11 07:09:06 UTC
Created attachment 55685 [details]
Basic support for font stretch in sfx and above.
Comment 50 dtardon 2008-08-11 07:10:27 UTC
Created attachment 55686 [details]
Import/export of font stretch to/from ODF.
Comment 51 dtardon 2008-08-11 07:13:17 UTC
Created attachment 55687 [details]
Fix of VCL to really use font stretch for font selection.
Comment 52 dtardon 2008-08-11 07:18:49 UTC
Created attachment 55688 [details]
Testing file containing all possible values of font stretch. Unfortunately, DejaVu font contains but one alternative stretch (semi-condensed), so there is not much to see.
Comment 53 meywer 2008-08-13 20:58:27 UTC
On I read now, that Condensed
is both, a font-family itself and a style in the not-condesed font-family.

So OO should make it available as both too. (Because of older documents using it
as font and because of logic.)

And if it shows it as style ("typeface") in format - character (as it does
already), it should not use the book-style instead of the condensed-style (as it
does for now), when I set the condensed style.
Comment 54 nmailhot 2008-08-16 08:37:05 UTC
@meywer Ben states plainly in
that having Condensed a font family is a legacy deprecated property for systems
that can not parse modern font attribute. It's not intended to be used by
anything remotely current.

Linux core font libraries have been switched to the modern behaviour after a
grace period some time ago. Going back to the previous behaviour or activating
both at once would be a regression.  (and BTW opentype specs were written by
entities like MS so trying to fight the tide would result in major compatibility
problems in a few years)

The problems occur at the OO.o level, which is still being updated to take font
format changes into account. If you want to complain, complain this update is
taking too long, do not ask to remove what progress has already been made by the
fine developpers.
Comment 55 dtardon 2008-09-03 08:24:40 UTC
Created attachment 56164 [details]
Independent selection of Posture/Weight/Stretch in Format->Character dialog
Comment 56 dtardon 2008-09-03 08:52:50 UTC
Some comments to the previous patch: It is a first try, only to get it working;
it should be fully working, though. It's for West lang. group only--if you have
enabled Asian or CTL lang. groups, you will see nothing new...

I've used list-boxes for the new controls (Posture/Weight/Stretch); they are
refilled after each change of Font Family, where each of them gets assigned all
values of the particular attribute that Family contains. That implies it's
possible to select combination which has no real counterpart in font file. There
are two another ways to solve the filling and the chosen one is somewhere
between them:
1. The controls contains always all possible values for each of them (i.e.
Normal/Italic/Oblique for Posture).
2. The controls are updated on change in any of them to reflect only allowed
combinations--this would be no change to current state.

Oh, and to apply the patch requires all my previous patches have been applied as
Comment 57 dtardon 2008-09-03 09:01:26 UTC
A question to anyone acquainted with Asian/CTL fonts: Is there anything as
font-stretch in use in these fonts? If there is, then there is a need for
specific SIDs, controls and XML attributes for them as well. I haven't found any
positive evidence of it, but maybe someone knows better...
Comment 58 2008-09-03 09:48:12 UTC
> Is there anything as font-stretch in use in these [CJK-]fonts?

Many CJK fonts come in two variants: monospaced and proportional
Calling this attribute "font-stretch" is a bit of a stretch though... in this case the other commonly terms 
"proportion" or pitch" are more appropriate

@tora/@khirano: are you aware of any CJK font families that have other pitch-variants than monospaced 
or proportional, e.g. condensed or expanded?
Comment 59 Mathias_Bauer 2008-09-03 11:18:19 UTC
Wow! I was on vacation for three weeks and when I came back I saw a huge patch
attached. Great. :-) Thanks for the patch.

It will take some time to review it, I hope we can do this in the 3.1 time
frame, at least we will try.

Oliver, please take over. I'm sure that Herbert can help with the VCL part if
Comment 60 benlaenen 2008-09-03 12:10:36 UTC
btw, since you only seem to speak about font stretch and weight, don't forget 
there are other possibilities. Many Adobe fonts have an "outline" style for 
example, or have "text", "caption" and "subhead" styles. And there are other 
possibilities. That means two or more styles in the same family with the same 
weight, stretch and slant.

Also, please don't magically change the style names, so keep the original 
names as defined in the font, and not some interpreted version from the 
numbers in the font which will confuse people and will give problems in the 
case above.
Comment 61 tora3 2008-09-03 21:32:52 UTC
tora->hdu: Thank you for giving us a chance to comment some. 

In sum, Japanese fonts, in general, do not use terms such as condense 
or oblique. They uses wight, instead. 

Microsoft Office Japanese uses traditional font faces: 
 regular, bold, italic, and bold italic. 

Professional users from such as publishing use lots of fonts which 
are normally decorated with weight. For such users, artificial bold 
seems not a choice. They simply uses heavier wight of fonts, instead. 

Either italic or italic bold is probably not applied for Japanese 
characters and is not typically used for publishing. Both italic 
and italic bold are normally applied for Western letters. 

For historical reasons, Japanese often uses both Japanese characters 
and Western letters in a single document. 

For Japanese, many fonts are available: 
 - Fonts embedded in Windows 
 - Fonts released by font vendors, for professional use
 - Freely available fonts

Fonts samples embedded in Windows Japanese and 2007 Microsoft Office 
System Japanese. Snapshots are available in the following web page:

   The first 5 fonts (MS UI Gothic to MS Pxx) in the web page are 
   the fundamental fonts of Windows Japanese that are available 
   from Windows 9x to Vista. 
   Their font names begin with two letters 'MS.'

   The rests are the fonts that are accompanied with the Office System.
   Their font names begin with two letters 'HG.'

  Naming conventions 
   MS [P]FontFamilyName
    none: Monotype (fixed width)
       P: Western proportional letter and Asian proportional character

   HG[P|S] FontFamilyName
    HG: The font vendor seems to add this two letters at the beginning
    none: Monotype (fixed width)
       P: Western proportional letter and Asian proportional character
       S: Western proportional letter and Asian monotype character

  Bold and Italic
   It seems that Windows is capable of rendering artificial bold and/or 
   italic glyph. 

  For font family メイリオ embedded in Windows Vista Japanese is ClearType 
  and probably has four font faces.

Many font vendors offer fonts files for professional use.

 Motoya co., ltd.

   Naming conventions 
    VendorName FontFamilyName # 
      #: number that denotes weight. 
         The smaller, thinner; the bigger, thicker. 

 Morisawa & Company Ltd.

   Naming conventions 
    FontFamilyName [L|R|M|B|EB|H|EH|U]

 DynaComware Corp.
   Naming conventions 
    VendorName FontFamilyName W#
      #: number that denotes weight. 

 Useful web site that lists links for font vendors:

Freely available fonts

 A web site listing freely available fonts:

       Naming conventions 
        VendorName FontFamilyName W#
         #: number that denotes weight.

 Major Linux distributions come with some Japanese fonts. 
   sazanami mincho and sazanami gothic solely have one font face. 

  available fonts called IPA fonts, (not International Phonetic 
  Alphabet), that resemble the fundamental five fonts of Windows 
  Japanese. The fonts have been widely spread among Linux users. 
Comment 62 2008-09-04 15:09:14 UTC
@tora: thank you for the detailed insight into the CJK aspect of this problem!

@dtardon: while you are reworking this please consider tora's input too. Especially the common case 
that some CJK font families are only distinguished by their weight (e.g. "Mincho W6" vs. "Mincho W8") is 
bound to cause similar problems like the ones nmailhot and benlaenen mentioned (older font families 
that had e.g. "condensed" or "outline" in the family name instead of the style name). My personal 
preference would be if these family variants were merged into one family and the style attributes could 
do the rest.

As far as I'm concerned I'd be happy with every change
- which doesn't introduce unsolvable regressions
- which allows simple backwards compatibility with existing documents
- which allows simple interoperability with other common document formats
- plays nicely with existing libraries (e.g. fontconfig) 
- which goes into the direction Nicolas mentioned in e.g. desc27
- which keeps the style name exactly as defined by the font itself (except localized strings of course)

That's a big order though. Is it too big? Or should we continue to "just" fix the obvious issues with the 
pitch attribute first and ignore the related issues for now? Solving the problems with pitch would go a 
long way already...
Comment 63 Oliver Specht 2008-09-09 14:50:28 UTC
->dtardon: Regarding your last patch (from Wed Sep 3 07:24:00 +0000 2008) 
I wouldn't separate the font styles into three ListBoxes as this enables to
select combinations that are not supported by the font. It would be better to
keep the single font style box that contains all the available combinations.

Additionally, we need a volunteer to take care for the file format extension. 
Comment 64 Mathias_Bauer 2008-11-05 13:10:54 UTC
From the last comments I conclude that 3.1 is too ambitious. Right?
Comment 65 Oliver Specht 2008-11-05 13:30:34 UTC
->mba: Yes, definitely not 3.1
Comment 66 sergiozambrano 2009-06-06 15:41:05 UTC
After MANY tests editing all the font names below for a custom font, it seems
OOo doesn't handle more than 4 styles, even when shown in typeface list. 

Condensed Bold

When you remove some, others work. When you get the names showing up, fonts over
4 look the same. Bottom line: only 4 typefaces work properly and the rest are
duplicated in name or shape.

OSX 10.5.7
OpenOffice 3.1 (build 9399)
Comment 67 Oliver Specht 2009-07-02 09:16:08 UTC
*** Issue 82986 has been marked as a duplicate of this issue. ***
Comment 68 aynadamar 2009-09-09 11:13:06 UTC
Created attachment 64639 [details]
Font Style mockup - Font Features
Comment 69 aynadamar 2009-09-09 11:17:46 UTC

This [1] mockup for UI shows an easy way to add OTF features to character style.

In the features list, you could select some of the features with Ctrl key (as in
any multiple selection).

On mouse over, it could show a pop-up with a few info about what "aalt" (for
example) means.

Another way could be adding a new tab called "Font Features". With this option,
it could be possible to expand in a future (if ATT Typographic Features'd be added).

In the mockup, it shows OTF so if ATT is added, it could show ATT instead of OTF.

Sorry for being so weird explaining myself... it's a problem I also have in my
native language.

Comment 70 Peter 2010-02-02 14:44:16 UTC
Is there any progress underway? I'm currently testing 3.2RC4/Linux with
OpenTypeFonts and OO is not able to handle i.e. the "Futura" family (and others
with Condensed or Extra Bold styles) gracefully.
Comment 71 Peter 2010-02-02 14:47:02 UTC
Created attachment 67527 [details]
screenshot font selection
Comment 72 2010-06-21 14:19:02 UTC
*** Issue 111891 has been marked as a duplicate of this issue. ***
Comment 73 nomnex 2010-07-28 01:34:38 UTC
OOo 3.2.1, the default DejaVu font has a Condensed variant. I appears in the OOo
font selection (book, bold, condensed, etc.) but it has no effect on the text.

it is related to this bug?

Comment 74 dtardon 2010-07-28 05:31:07 UTC
dtardon->nomnex: yes, it is
Comment 75 fmms 2010-07-28 07:45:36 UTC
Created attachment 70853 [details]
Fedora 14 currently ships some pre OO3.3, there I can select Dajavu Narrow...
Comment 76 nomnex 2010-07-28 07:57:44 UTC
Fedora 14, isn't it a Go-oo version (the OOo + Novell Patch)?
Comment 77 caolanm 2010-07-28 08:41:09 UTC
"Fedora 14, isn't it a Go-oo version (the OOo + Novell Patch)?", no, its
basically to-be vanilla 3.3 (DEV330_mX)
Comment 78 nathank 2010-08-17 01:51:57 UTC
Besides DejaVu's Condensed variants and ralphie's Adobe Garamond expert sets, 
perhaps another set of fonts useful for testing are the Latin Modern fonts.  (See ; package lmodern on my 
Debian system.)  For instance, here are the variants of the Latin Modern font 
"LMRoman10" and whether they are listed in the "Typeface" list in the Character 
dialog box in my OO 2.4 system:

            LMRoman10          listed in      correctly
font file   variant          OO font list?    displayed?
lmr10       (roman)                N             -
lmri10      italic                 Y             Y
lmro10      oblique                N             -
lmu10       unslanted              N             -
lmcsc10     smallcaps              Y             Y
lmcsco10    smallcaps oblique      Y             Y
lmdunh10    dunhill                N             -
lmduno10    dunhill oblique        N             -
lmb10       demi                   Y             Y
lmbo10      demi oblique           Y             Y
lmbx10      bold                   Y             Y
lmbxi10     bold italic            Y             Y
lmbxo10     bold oblique           Y             Y

Interestingly, all the variants which OO lists are handled correctly, whereas the 
DejaVu Condensed variants are listed but not handled correctly (the non-condensed 
versions are used, as nomnex notes).
Comment 79 nmailhot 2010-08-17 06:04:42 UTC
TEX fonts are a world in themselves and should not be taken as example of "good"
fonts. TEX usually selects fonts by filename (in TEX macros) when other apps
select fonts by the font name and font face exported in font metadata. As a
result the font name and face exported by TEX fonts are too often a mess that
does not conform to existing font standards (since TEX itself does not use them,
except for very modern TEX engine which have low penetration so far).

The Latin Modern example you give is typical: your table references the filename
(which should be irrelevant, and besides is a human-unfriendly abbreviation that
only makes sense for people that type it instead of selecting it in gui lists),
and the faces listed do not conform to WWS
( Standard CSS operators
like bold-er can not work with a face such as "dunhill". (and I've seen much
worse while auditing texlive 2007, for example standard face composants such as
italic split between font family name and font family variant, which had clearly
been generated through a stupid format convertor without ever checking the
result outside of TEX)

While it would be good to accommodate TEX fonts, the priority should be to
accommodate fonts that conform to specs written to help typical GUI apps. If the
TEX world wants its fonts to be used outside of TEX, it has lots of cleaning up
to do.

Comment 80 dtardon 2010-08-31 08:28:48 UTC
*** Issue 114158 has been marked as a duplicate of this issue. ***
Comment 81 Rob Weir 2013-03-11 15:05:11 UTC
I'm adding this comment to all open issues with Issue Type == PATCH.  We have 220 such issues, many of them quite old.  I apologize for that.  

We need your help in prioritizing which patches should be integrated into our next release, Apache OpenOffice 4.0.

If you have submitted a patch and think it is applicable for AOO 4.0, please respond with a comment to let us know.

On the other hand, if the patch is no longer relevant, please let us know that as well.

If you have any general questions or want to discuss this further, please send a note to our dev mailing list:


Comment 82 Marcus 2017-05-20 10:44:53 UTC
Reset the assignee to the default "".