|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | Fonts in large Type 1 families not recognized correctly | ||
|---|---|---|---|
| Product: | gsl | Reporter: | wshooper <wsh-openoffice> |
| Component: | code | Assignee: | AOO issues mailing list <issues> |
| Status: | CONFIRMED --- | QA Contact: | |
| Severity: | Trivial | ||
| Priority: | P3 | CC: | issues, niemayer |
| Version: | 641 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux, all | ||
| Issue Type: | ENHANCEMENT | Latest Confirmation in: | --- |
| Developer Difficulty: | --- | ||
| Issue Depends on: | 79878 | ||
| Issue Blocks: | |||
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. |
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.