Apache OpenOffice (AOO) Bugzilla – Issue 2867
Fonts in large Type 1 families not recognized correctly
Last modified: 2013-02-07 22:32:39 UTC
Certain families of Type 1 fonts contain many different styles, each represented as a separate font program (i.e., .pfa file). OpenOffice should let me select any of these styles, particularly since I've already identified each of them to X (according to the X Logical Font Description conventions), but it doesn't. Even the styles which are listed aren't always correct. For example, consider the ITC Garamond family, which Adobe has digitized into sixteen different fonts, one for each combination of: * Four weights: Light, book, bold, and ultra * Two widths: Regular and condensed, and * Two styles: Roman and italic OpenOffice build 641 only allows me to choose six of these sixteen varieties, and _gets two of them wrong_. As listed in the "Typeface" widget of the "Character" dialog box: "Light" (maps to Garamond-Light) "Light Italic" (maps to Garamond-LightItalic) "Regular" (maps to Garamond-Ultra -- wrong, should map to Garamond-Book) "Italic" (maps to Garamond-UltraItalic -- wrong, should map to Garamond-BookItalic) "Bold" (maps to Garamond-Bold) "Bold Italic" (maps to Garamond-BoldItalic) Notice that there's no way to select the Book weight, nor any way to get the condensed widths (which really are, in many font families, different from "squeezed" versions of the regular-width fonts). Here's a listing of the PostScript font names and the corresponding XLFD names (from fonts.dir): Garamond-Light -adobe-itc garamond-light-r-normal--0-0-0-0-p-0-iso8859-1 Garamond-LightItalic -adobe-itc garamond-light-i-normal--0-0-0-0-p-0-iso8859-1 Garamond-Book -adobe-itc garamond-book-r-normal--0-0-0-0-p-0-iso8859-1 Garamond-BookItalic -adobe-itc garamond-book-i-normal--0-0-0-0-p-0-iso8859-1 Garamond-Bold -adobe-itc garamond-bold-r-normal--0-0-0-0-p-0-iso8859-1 Garamond-BoldItalic -adobe-itc garamond-bold-i-normal--0-0-0-0-p-0-iso8859-1 Garamond-Ultra -adobe-itc garamond-ultra-r-normal--0-0-0-0-p-0-iso8859-1 Garamond-UltraItalic -adobe-itc garamond-ultra-i-normal--0-0-0-0-p-0-iso8859-1 Garamond-LightCondensed -adobe-itc garamond-light-r-condensed--0-0-0-0-p-0-iso8859-1 Garamond-LightCondensedItalic -adobe-itc garamond-light-i-condensed--0-0-0-0-p-0-iso8859-1 Garamond-BookCondensed -adobe-itc garamond-book-r-condensed--0-0-0-0-p-0-iso8859-1 Garamond-BookCondensedItalic -adobe-itc garamond-book-i-condensed--0-0-0-0-p-0-iso8859-1 Garamond-BoldCondensed -adobe-itc garamond-bold-r-condensed--0-0-0-0-p-0-iso8859-1 Garamond-BoldCondensedItalic -adobe-itc garamond-bold-i-condensed--0-0-0-0-p-0-iso8859-1 Garamond-UltraCondensed -adobe-itc garamond-ultra-r-condensed--0-0-0-0-p-0-iso8859-1 Garamond-UltraCondensedItalic -adobe-itc garamond-ultra-i-condensed--0-0-0-0-p-0-iso8859-1 Ideally, given a properly prepared Fontmap and fonts.dir file, and provided the font and AFM files are installed, OpenOffice should be able to correctly recognize and use every font in every family in, say, the the Adobe Font Folio product (every Adobe font on CD-ROM) and offer users the ability to select any of them. This also means handling small-caps and other unusual versions, which XLFD says should be identified in the "adstyl" field but are otherwise indistinguishable. A sample broken case for this is Adobe Jenson, which has three different "medium-r-normal" versions: AJenson-Regular -adobe-adobe jenson-medium-r-normal--0-0-0-0-p-0-iso8859-1 AJenson-RegularDisplay -adobe-adobe jenson-medium-r-normal-display-0-0-0-0-p-0-iso8859-1 AJenson-RegularSC -adobe-adobe jenson-medium-r-normal-smallcaps-0-0-0-0-p-0-iso8859-1 Right now, OpenOffice only lists the -RegularSC version, but calls it "Regular". The real -Regular version is ignored. (One program that actually gets all of this right UI-wise is the GIMP.) If it matters, I'm using Red Hat 7.2 without the font server.
besides the book-light clash this works as designed: The addstyle name is usually not taken into account. Anyway William has a point here that the presentation of typefaces is very limited. I would be glad if you could evaluate the gimp as this feature is concerned and come up with a RFE. The gimp has a high reputation so it is surely worth a look.
Reassigened to Bettina.
I think this issue is more severe than it seems from the descriptions here: OO is not only unable to make certain font styles available to the user, but in fact confuses font styles in a way that makes certain well-known fonts unusable under certain conditions. Example: Import the original Adobe Type 1 font "Helvetica" from spadmin. Works fine. Now also import the original Adobe Type 1 font derivative "Helvetica-Fraction" - a special variant that is only meant to create good looking fraction numbers, such as "3/17". Now you cannot choose the "-Fraction" variant, but that is the minor part of the problem. If you're unlucky, depending on the order the fonts appear in your share/psprint/pspfontcache file (as "File:XXXX.pfb ... etc.), you're now unable to use the ordinary "Helvetica" font, because OO confuses the "Helvetica-Fraction" variant with it. If you print a document that shall contain Helvetica letters, you can see the wrongly chosen font when you look through the resulting .ps file. I think the only solution is to teach OO to treat whatever "font-style" may appear that is not known to OO as a different font familily. Of course you could also teach OO about all existing variants, but there are far too many and maybe unknown ones ("-Display", "PhoneticalAlternate", "-UltraHeavy" etc.).
This looks more like a fontconfig/freetype2 issue (if OO is using fontconfig). Almost all freetype2-based apps I've used give wrong results for lots of Type 1 fonts (esp. commercial fonts).
I'm glad to see this issue is well-documented. I was thinking I would have explain it in depth. Pniemayer states: > I think the only solution is to teach OO to treat whatever > "font-style" may appear that is not known to OO as a different font > familily. I disagree that this is the *only* solution, though it might be a good one. An alternative might be to keep the fonts in the same family, but provide, probably in the Format -> Character dialog, a selection list of "Additional variants"--since there is no universal scheme for classifying unusual font variants, and different vendors may use different terms for the same thing or vice versa, the list should probably just give the PostScript name for each font, with no attempt to interpret that name. I suspect this approach might be easier to implement and less error-prone than automatically creating new families. As others have argued, I believe that OpenOffice (or freetype, or whatever software component is responsible) needs to be more sophisticated in recognizing font variants, so that the "normal" typefaces will be used by default in most cases, and that users should have access to all installed variants when creating documents. On the other hand, I doubt that these measures will be sufficient for all cases. There should also be an "advanced font management" interface that allows users to manipulate font classifications when OpenOffice is unable to do the right thing automatically.
Reasigedn to the owner requirements.