Bug 53110 - Faulty monospace rendering on Courier and Monaco fonts
Summary: Faulty monospace rendering on Courier and Monaco fonts
Status: RESOLVED DUPLICATE of bug 42856
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.5.5.3 release
Hardware: PowerPC macOS (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-04 03:47 UTC by dcdevoto
Modified: 2012-08-21 09:41 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Monospace error illustration (18.87 KB, image/png)
2012-08-04 03:47 UTC, dcdevoto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description dcdevoto 2012-08-04 03:47:12 UTC
Created attachment 65107 [details]
Monospace error illustration

Hi, 

When lower case "f" is followed by lower case "i" in Courier and Monaco fonts, the letter spacing is messed up and not monospace.  In the attached screenshot, the first two lines are correctly rendered monospace fonts, Andale Mono and Courier New, the next two lines are Monaco and Courier (notice the "f" followed by "i" in "LibreOffice," and the second group of four lines shows the same order, only in italics.  As you can see, there is no such spacing error when the fonts are italicized, only in regular.

Thanks,

Dan
Comment 1 Roman Eisele 2012-08-18 17:03:11 UTC
Thank you very much for your bug report!

This issue is more or less a duplicate of bug 42856.

However, bug 42856 is marked as RESOLVED/WORKSFORME, because I can’t no longer reproduce it with LibreOffice 3.5.6 or LibreOffice 3.6.0 on MacOS X 10.6.8 (Intel). It is interesting that you can still reproduce it (given the fact that your report is a very recent one!).


Therefore, to help us to find out what makes the difference, please answer some questions:
1)  Could you please mention the MacOS X version you use? It is possible that the MacOS X version is important here, because Monaco and Courier are system fonts which change with each System revision.
2)  Also, could you please open the folder System/Library/Fonts on your system hard drive, search for the font files "Courier" and "Monaco", select them, press Command + I, and mention for both fonts
   (a) the file type/kind (i.e., "TrueType font" or "Datafork TrueType font"
       etc.);
   (b) the file version (e.g., "5.1b2").
Both file type and file version should be listed in the Information window which appears when you select a font file and press Command + I.

To answer to these questions, please return to the present website
   https://bugs.freedesktop.org/show_bug.cgi?id=53110
and click "Add Comment"; don’t use your e-mail client to answer.

Thank you very much in advance!


Meanwhile please be aware that combination of f and i (fi) visible on your screenshot with Monaco and Courier is just a so-called ligature (see
   http://en.wikipedia.org/wiki/Typographic_ligature
) and not an error, because the fi ligature (both letters together) should take exactly the width of a normal letter in a monospaced font, so that the letter spacing should NOT be messed up. You can proof this if you type the two lines:

|office|
|ofxce|

Now fi in the first line should take exactly the same space as the single 'x' in the 2nd line, and the two bars (|) at the end of the lines should be at the same horizontal position (at least, it *should* be this way if LibreOffice handles the fonts correctly ;-).

If this is the case, there should not be a big problem with the ligatures, because they should not mess up the monospace letter spacing.

There is, of course, a minor problem, namely the little inconsistency that LibreOffice uses automatic ligatures with Courier and Monaco, but not with Andale Mono, Courier New, and the pseudo-italicized versions ... (cf. my comment
   https://bugs.freedesktop.org/show_bug.cgi?id=42856#c9
about possible reasons for this inconsistency). But IMHO this is a minor problem, as long as the width of the ligatures is correctly equal to the width of an ordinary character.
Comment 2 dcdevoto 2012-08-18 23:58:13 UTC
Hi,

I updated to 3.6.0 and still found the same problem.  My OS X version is 10.4.11 (PPC).  The Courier and Monaco fonts are Datafork Truetupe fonts and both their versions are 5.1d1e1.

The reason I brought this up is when I open a hundred page long screenplay as an .rtf in Courier, there are a handful of lines in the text that are shortened by a space, and when there is no carriage return in paragraphs, occasionally a paragraph will be one line shorter.  Occasional pages that are one line shorter mess up the page numbering where a page number intended for the next page is now at the bottom of its previous page.  This is all fixable by switching to Courier New, but I thought it was odd that Courier and Monaco displayed this way in LibreOffice when I hadn't experienced this in other word processors.
Comment 3 Roman Eisele 2012-08-20 14:20:51 UTC
Hello dcdevoto,

thank you very much for your fast answer!

I will continue to comment on this issue soon. Just doing some research before, maybe I will find out something of interest about the reasons of this bug ...
Comment 4 Roman Eisele 2012-08-21 09:41:10 UTC
(In reply to comment #2)
> I updated to 3.6.0 and still found the same problem.

Thank you very much for testing this! I conclude from your results,
(a) that the present issue is really a duplicate of bug 42856, 
(b) that bug 42856 is not fixed in 3.6.x, as I had assumed.

Therefore I will mark the present bug report as a duplicate of bug 42856 AND reopen the latter and leave an additional comment there. Also all further discussion should be continued on the report page for that bug.

> The reason I brought this up is when I open a hundred page long screenplay as
> an .rtf in Courier, there are a handful of lines in the text that are shortened
> by a space, and when there is no carriage return in paragraphs, occasionally a
> paragraph will be one line shorter.  Occasional pages that are one line shorter
> mess up the page numbering where a page number intended for the next page is
> now at the bottom of its previous page.

This is a very good reasoning for the importance of this bug; thank you for it!
Comment 5 Roman Eisele 2012-08-21 09:41:40 UTC

*** This bug has been marked as a duplicate of bug 42856 ***