I am not entirely convinced that this is a bug as the old Adobe "Expert" series fonts were terrible. As the original description indicates it is only the adjunct expert variant of each font (i.e., the attached font files that contain an "x" in their name) that cause a problem. The standard versions appear to work OK under Crunchbang 11 running TDF/LO v4.0.4.2 (Build ID: 9e9821abd0ffdbc09cd8c52eaa574fa09eb08f2). 

These adjunct fonts attempt to provide additional characters (e.g., ligatures, fractions, small capitals, super/sub-script numerals, and other miscellaneous marks) that do not exist in the standard version of each font. They do this by placing these additional characters in the usual position of standard characters e.g., in the the Regular Expert font (padr8x.pfb) you can find an uncoded "asuperior" character in the usual position of Latin Capital Letter A (U+0041), Latin Small Ligature ff (U+fb00) in the usual position of Latin Capital Letter V (U+0056), and so on. This is generally regarded as bad practice, except in some edge cases. Usually the Private Use Area is where non-Unicode characters should be placed and many of these characters have an appropriate Unicode codepoint (that is not being used).

The newer Adobe Pro series of fonts effectively supercedes these old "Expert" fonts and in the process, not only vastly extends the available character set, but also markedly cleans up this type of mess. By way of example the Adobe Garamond Pro Regular (OTF) font contains more than twice the number of characters and does not suffer this problem. I am not certain this problem is Type 1 specific so much as a matter of LO not supporting a bad, old font. Whether LO should be catering for this particular situation I will leave to the developers to consider.

Did you already try if this is still valid with the latest 4.1.3.2 stable release of LO?

Before we can do anything we need explicit steps of what to do to see the problem. Please provide a very simple test document that shows the problem, give explicit steps of what we should type to see the problem (you just say "Caps aren't shown correctly", not nearly enough for me to easily and efficiently diagnose). 


Once you do these two things mark the bug as UNCONFIRMED and we'll go from there.


Thanks for helping make LibreOffice better for everyone :)

Created attachment 88978 [details]
Sample document which illustrates problem GARAMOND font

I added a sample document which can be opened in LibreOffice 3.6 and 4.0.3 illustrating the difference in showing characters. I hope this will help reproducing the problem.

I will also attach two screenprints (LO 3.6 vs LO 4.0.3)


I did not check later versions of libreoffice - maybe the problem automatically solved...

If you can not reproduce, in my opinion this bug doesn't need any priority. Lots of alternatives exists. I just wanted to make sure there is no structural problem under the hood.

Created attachment 88979 [details]
behaviour in LO 3.6

Created attachment 88980 [details]
behaviour in LO 4.0.3

Created attachment 89006 [details]
ZIP containing screenshot showing display under various LO versions.

This probably constitutes confirmation, in that I am seeing the same on-screen appearance indicated in the screenshot provided in comment #6. This problem however is possibly more complex and likely older than currently indicated. I have tested the file provided in comment #4 by opening it on a single computer under Crunchbang 11 x86_64 linux running these versions of LO:

- v3.3.4.1 OOO330m19 (Build:401)
- v3.4.6.2 OOO340m1 (Build:602)
- v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
- v3.6.7.2 Build ID: e183d5b
- v4.0.6.2 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24
- v4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a

Screenshots of the results are attached and differ from that indicated in the description and comments 4 and 5. All versions of LO apart from v3.3.4.1 exhibit problems in display of the text set in Adobe Garamond. Both v3.3.4.1 and v4.1.3.2 exhibit the same line height metric, so there has evidently been an improvement in this area in the latest release. The mis-interpretation of glyphs across all later versions seems identical, with the exception that certain uppercase glyphs (FGHJKPQU) are no longer represented using a rectangle outline under v4.x.

It is worth noting that if Adobe Garamond Pro fonts (refer comment #1) are installed on the same system, the Pro series fonts will cause the text to display as expected (regardless of whether the provided Adobe Garamond Expert series fonts are installed or not). It would therefore seem important any testing be done on a system where the ONLY Garamond fonts are those provided in the description. 

To add to what I stated in comment #1, if only the Regular font (padr8a.pfb) is installed then all versions tested here display the example document as expected. If the Regular and Regular Expert fonts (padr8a.pfb, padr8x.pfb) are installed then only v3.3.4.1, v4.0.6.2, and v4.1.3.2 display the text as expected. The same pattern occurs for the Bold+Expert, BoldItalic+Expert, RegularItalic+Expert, SemiBold+Expert, and SemiBoldItalic+Expert combinations with varying degrees of glyph mis-interpretation. I have not exhaustively tested every possible combination for all the provided fonts, and this would seem unnecessary. 

The good news is that there appears to be some mild improvement under the v4.x series.

Without having tested from comment #7 and Owen's extensive testing, setting this to NEW.

We are dropping support for Type 1 fonts in 5.3.