Apache OpenOffice (AOO) Bugzilla – Issue 79878
OO.o can not select modern font faces conveniently
Last modified: 2017-05-20 10:44:53 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, http://dejavu.sf.net) 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)
Please have a look.
Created attachment 47030 [details] picture with following patch applied
Created attachment 47031 [details] this patch propogates the widthtypes into the attributes used to compare fonts to eachother
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 ?
good question, hdu will be able to answer that when he's back.
@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
The UI part should start from this : http://unifont.org/fontdialog/
I think the issues 2867 and my 43495 are duplicates of this issue.
@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?
Don't know if this helps, but OO.o on Windows does it right. Regards Klaus
@hdu Glad you like it Ed Trager has posted more recent material on the same subject there: http://www.unifont.org/TextLayout2007/ (the Fontima stuff)
Created attachment 48895 [details] proposed dialog in action
After some exchange on this thread: http://gsl.openoffice.org/servlets/BrowseList?list=dev&by=thread&from=1877392 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 Linux. 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).
Created attachment 48896 [details] proposed patch
Created attachment 48897 [details] A (very) small test-bed
Forgot CC myself...
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. /ralph
@beppec56 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.
@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): AGaramond-Italic.afm AGaramond-Italic.pfa AGaramond-ItalicOsF.afm AGaramond-ItalicOsF.pfa AGaramond-Regular.afm AGaramond-Regular.pfa AGaramond-RegularSC.afm AGaramond-RegularSC.pfa AGaramond-Semibold.afm AGaramond-Semibold.pfa AGaramond-SemiboldItalic.afm AGaramond-SemiboldItalic.pfa AGaramond-SemiboldItalicOsF.afm AGaramond-SemiboldItalicOsF.pfa AGaramond-SemiboldSC.afm AGaramond-SemiboldSC.pfa AGaramond-Titling.afm AGaramond-Titling.pfa 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
Thanks for the patch. I forward it to the responsible developer.
Philipp, I'm not sure if this is one for you or for hdu, but OTOH I'm sure you will find an agreement. :-)
@ralphie: I'm referring to the changes between http://www.openoffice.org/nonav/issues/showattachment.cgi/47030/widthtypes.png which is nice, even if the typeface column needs more work and http://www.openoffice.org/nonav/issues/showattachment.cgi/48895/dialog.png which is *not* nice as it breaks up modern fonts in sets of pseudo legacy fonts.
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.
@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 installed. @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.
@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
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 one). 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: http://www.w3.org/TR/css3-fonts/#font-styling (Web) http://blogs.msdn.com/text/attachment/2249036.ashx (Windows) http://fontconfig.org/fontconfig-user.html (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 by 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)
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.
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.
@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 Condensed Oblique Condensed Bold Condensed Bold Oblique Extralight Book Oblique Bold 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 http://blogs.msdn.com/text/attachment/2249036.ashx 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.
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.
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?
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 attributes
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.
*** Issue 87708 has been marked as a duplicate of this issue. ***
*** Issue 89380 has been marked as a duplicate of this issue. ***
In OOImpress DejaVu Sans troubles with unicode (?) See following attachements
In OOImpress DejaVu Sans troubles with unicode (?) See following attachments
Created attachment 54175 [details] screenshot showing the problem
Created attachment 54176 [details] file with trouble
*** Issue 42835 has been marked as a duplicate of this issue. ***
transfering the "depends on" issue 81913 from the duplicate issue 42835
*** Issue 26012 has been marked as a duplicate of this issue. ***
*** Issue 88796 has been marked as a duplicate of this issue. ***
*** Issue 45358 has been marked as a duplicate of this issue. ***
Please have a look on issue 87710 too.
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**) ). *) http://dejavu.sourceforge.net/wiki/index.php/Main_Page 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: http://dejavu.sourceforge.net/wiki/index.php/Main_Page 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) and OO should not list "condensed" as available font-style for DejaVu Sans (wich is a (new?) OO-bug)!!!
forgot cc
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.
Created attachment 55685 [details] Basic support for font stretch in sfx and above.
Created attachment 55686 [details] Import/export of font stretch to/from ODF.
Created attachment 55687 [details] Fix of VCL to really use font stretch for font selection.
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.
On http://bugs.freedesktop.org/show_bug.cgi?id=12735 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.
@meywer Ben states plainly in http://bugs.freedesktop.org/show_bug.cgi?id=12735 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.
Created attachment 56164 [details] Independent selection of Posture/Weight/Stretch in Format->Character dialog
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 well.
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...
> 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?
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 necessary.
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.
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: http://office.microsoft.com/ja-jp/2007/FX102141601041.aspx 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. http://www.akibatec.net/wabunfont/library/windowsos/windowsos.html Many font vendors offer fonts files for professional use. Motoya co., ltd. http://www.motoyafont.jp/font_sample.html Naming conventions VendorName FontFamilyName # #: number that denotes weight. The smaller, thinner; the bigger, thicker. Morisawa & Company Ltd. http://www.morisawa.co.jp/font/fontlist/ Naming conventions FontFamilyName [L｜R｜M｜B｜EB｜H｜EH｜U] e.g. http://www.morisawa.co.jp/font/fontlist/details/fontfamily001.html http://www.morisawa.co.jp/font/fontlist/details/fontfamily001_2.html http://www.morisawa.co.jp/font/fontlist/details/pdf/RyuminKL_Family.pdf DynaComware Corp. e.g. http://www.dynacw.co.jp/dynafont/fontface/pdf_data/sample_tt600w_v.pdf http://www.dynacw.co.jp/dynafont/fontface/pdf_data/sample_ot_p9.pdf Naming conventions VendorName FontFamilyName W# #: number that denotes weight. Useful web site that lists links for font vendors: http://www.akibatec.net/wabunfont/library.html Freely available fonts A web site listing freely available fonts: http://www.akibatec.net/wabunfont/freefont/freefont.html e.g. http://www.akibatec.net/wabunfont/freefont/pro1.html Naming conventions VendorName FontFamilyName W# #: number that denotes weight. http://www.akibatec.net/wabunfont/freefont/ama-d.html Major Linux distributions come with some Japanese fonts. Sazanami http://sourceforge.jp/projects/efont/ sazanami mincho and sazanami gothic solely have one font face. IPA http://ossipedia.ipa.go.jp/ipafont/ INFORMATION-TECHNOLOGY PROMOTION AGENCY, JAPAN releases freely 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.
@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...
->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.
From the last comments I conclude that 3.1 is too ambitious. Right?
->mba: Yes, definitely not 3.1
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. Regular Demi Bold Condensed 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)
*** Issue 82986 has been marked as a duplicate of this issue. ***
Created attachment 64639 [details] Font Style mockup - Font Features
Hello, 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. [1] http://www.openoffice.org/nonav/issues/showattachment.cgi/64639/mockupwithfeatures.png
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.
Created attachment 67527 [details] screenshot font selection
*** Issue 111891 has been marked as a duplicate of this issue. ***
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?
dtardon->nomnex: yes, it is
Created attachment 70853 [details] Fedora 14 currently ships some pre OO3.3, there I can select Dajavu Narrow...
Fedora 14, isn't it a Go-oo version (the OOo + Novell Patch)?
"Fedora 14, isn't it a Go-oo version (the OOo + Novell Patch)?", no, its basically to-be vanilla 3.3 (DEV330_mX)
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 http://www.gust.org.pl/projects/e-foundry/latin-modern/ ; 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).
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 (http://blogs.msdn.com/text/attachment/2249036.ashx). 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.
*** Issue 114158 has been marked as a duplicate of this issue. ***
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: dev@openoffice.apache.org Thanks! -Rob
Reset the assignee to the default "issues@openoffice.apache.org".