Created attachment 80312 [details]
In LibreOffice the Adobe Garamond (Type 1) is not shown correctly (Caps aren't shown correctly - more like uppercase and strange signs). (Libreoffice Version 126.96.36.199 (Build ID: 0eaa50a932c8f2199a615e1eb30f7ac74279539)
In Font Manager the whole font series Adobe Garamond (Type 1) is shown correctly. In Libreoffice LibreOffice 188.8.131.52 Build ID: 350m1(Build:2) aswell.
I noticed that I can select the non-expert series of the font in libreoffice 184.108.40.206 vs the expert series of the Garamond font in 220.127.116.11. 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
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 v18.104.22.168 (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 22.214.171.124 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:
- v126.96.36.199 OOO330m19 (Build:401)
- v188.8.131.52 OOO340m1 (Build:602)
- v184.108.40.206 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
- v220.127.116.11 Build ID: e183d5b
- v18.104.22.168 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24
- v22.214.171.124 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 v126.96.36.199 exhibit problems in display of the text set in Adobe Garamond. Both v188.8.131.52 and v184.108.40.206 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 v220.127.116.11, v18.104.22.168, and v22.214.171.124 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.
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present on a currently supported version of LibreOffice
(5.0.5 or 5.1.0) https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the version of LibreOffice and
your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave
a short comment that includes your version of LibreOffice and Operating System
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)
2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword
Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for your help!
-- The LibreOffice QA Team This NEW Message was generated on: 2016-02-21
We are dropping support for Type 1 fonts in 5.3.