Bug Hunting Session
Bug 65380 - Type 1 font does not show correctly
Summary: Type 1 font does not show correctly
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
Reported: 2013-06-04 23:54 UTC by qqqqmv
Modified: 2016-11-12 00:09 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Specific font (680.00 KB, application/x-tar)
2013-06-04 23:54 UTC, qqqqmv
Sample document which illustrates problem GARAMOND font (14.37 KB, application/vnd.oasis.opendocument.text)
2013-11-10 12:38 UTC, qqqqmv
behaviour in LO 3.6 (119.50 KB, image/x-xcf)
2013-11-10 12:38 UTC, qqqqmv
behaviour in LO 4.0.3 (139.04 KB, image/x-xcf)
2013-11-10 12:39 UTC, qqqqmv
ZIP containing screenshot showing display under various LO versions. (189.88 KB, application/zip)
2013-11-11 10:00 UTC, Owen Genat (retired)

Note You need to log in before you can comment on or make changes to this bug.
Description qqqqmv 2013-06-04 23:54:49 UTC
Created attachment 80312 [details]
Specific font

In LibreOffice the Adobe Garamond (Type 1) is not shown correctly (Caps aren't shown correctly - more like uppercase and strange signs). (Libreoffice Version (Build ID: 0eaa50a932c8f2199a615e1eb30f7ac74279539)

In Font Manager the whole font series Adobe Garamond (Type 1) is shown correctly. In Libreoffice LibreOffice Build ID: 350m1(Build:2) aswell.

I noticed that I can select the non-expert series of the font in libreoffice vs the expert series of the Garamond font in this when selecting styles and formatting - font.

Iḿ using Linux Mint 13 Maya, Linux 3.2.0-23-generic (x86_64) Compiled	#36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012
Comment 1 Owen Genat (retired) 2013-07-21 06:08:50 UTC
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.
Comment 2 retired 2013-11-08 22:40:58 UTC
Did you already try if this is still valid with the latest stable release of LO?
Comment 3 Joel Madero 2013-11-08 23:23:45 UTC
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 :)
Comment 4 qqqqmv 2013-11-10 12:38:04 UTC
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.
Comment 5 qqqqmv 2013-11-10 12:38:39 UTC
Created attachment 88979 [details]
behaviour in LO 3.6
Comment 6 qqqqmv 2013-11-10 12:39:16 UTC
Created attachment 88980 [details]
behaviour in LO 4.0.3
Comment 7 Owen Genat (retired) 2013-11-11 10:00:49 UTC
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.
Comment 8 retired 2013-11-12 08:59:25 UTC
Without having tested from comment #7 and Owen's extensive testing, setting this to NEW.
Comment 9 QA Administrators 2016-02-21 08:34:21 UTC Comment hidden (obsolete)
Comment 10 Khaled Hosny 2016-11-12 00:09:06 UTC
We are dropping support for Type 1 fonts in 5.3.