Apache OpenOffice (AOO) Bugzilla – Issue 19614
OO's libfreetype leads to mis-aligned columns
Last modified: 2008-09-19 12:21:07 UTC
Each digit (0-9) in a font have the same width. Unfortunately this is not the case, when OO's spread-sheet application displays numbers on the screen. Find attached two screen shots, one with OO's own libfreetype and the other one with my locale version 2.1.4 one. In the latter, all columns are properly aligned.
Created attachment 9345 [details] rendered with OO's libfreetype
Created attachment 9346 [details] rendered with version 2.1.4
Hi Niklas, is it yours ? If not re-assign it to the responsible developer. Frank
Doesn't sound like a spreadsheet specific problem.
I cannot recreate this yet. Can you please attach the Calc document or even better a small excerpt. Also PDF export of this document would be very interesting.
Created attachment 9741 [details] Spreadsheet example
Created attachment 9742 [details] internally generated PDF
In the PDF everything is perfectly aligned, isn't it? Was it created with OOo's libfreetype or the system's libfreetype?
HDU->FST: Please help me to recreate the problem. The "misalignment of dots and commas" you saw were an optical illusion, because a dot next to a column of e.g. '7' looks differently aligned from a dot next to an '8'.
Hi Peter, please try it again with the currently available OOo1.1 Final. If the problem persist, please attach both used libfreetype's and give us a description of your system, e.g. what Distribution do you use and which X-Server and Graphics adapter. Frank
No response from User ao I assume the problem doesn't exist any longer. Frank
closed worksforme
Sorry for responding so lately. The problem persists in OO 1.1 - Libfreetype is that of OO (checked with lsof) - XFree86 4.2.0, 1280x1024, 24 bit Release Date: 23 January 2002 - SuSE 7.3, Kernel 2.4.16 - Matrox MGA G200 AGP rev 3
Created attachment 10637 [details] screenshot of OO spreadsheet
Hi Herbert, please have a look. Frank
It seems freetype's autohinter calculates the widths slightly differently. It doesn't have much of a chance to match it exactly to the pixel, if it doesn't have a special heuristic like: "If the digits have the same design width keep their width in sync when autohinting" I'm considering to develop a patch for this enhancement.
Do you really think it is necessary to develope a patch? I mean you can simply use recent freetype2 lib. It works for me with 2.1.4 and even with 2.1.5 and 2.1.5-dc for quite some time.
We are using 2.1.4! The difference may be that OOo ships with the autohinter version. Please what the two different libraries report for "objdump -T ????/libfreetype.so.6 | fgrep TT_RunIns"
objdump reports 00049ff0 g DF .text 00000fb6 Base TT_RunIns on my 2.1.5-dc and nothing on OO's libfreetype. I've compiled libfreetype (2.1.4, wich works OK) with #define TT_CONFIG_OPTION_BYTECODE_INTERPRETER (in ftoption.h) (In 2.1.5-dc there is are additional defines: #define FT_CONFIG_FORCE_AUTOHINT #define FT_CONFIG_SMOOTH_HINTING )
That is what I assumed. When you read the comments in the neighborhood of the freetype configuration patch you just mentioned, you'll understand why we don't do the same. As I said, the most promising solution is to use the heuristic I proposed in freetype's autohinter.
according to the announcement on releases (http://www.openoffice.org/servlets/ReadMsg?list=releases&msgNo=7503) this issue will be re-targeted to OOo Later.
With the change for issue 52026 this is no longer a problem. *** This issue has been marked as a duplicate of 52026 ***
Closing resolved issue.