The current calculation of interline spacing is fundamentally flawed, at
least on "unx".
The implementation of ServerFont::FetchFontMetric() in gcach_ftyp.cxx
does the following:
* gets ascent/descent from FT_Size_Metrics which is fine
* sets internal leading to the value of line gap while this should be
the external leading
* if the font has an OS/2 table
- recalculates the metrics based on WinAscent/WinDescent which is
absolutely wrong as these metrics should never be used to control
line spacing
- external leading get set based on a combination of metrics from HHEA
table and WinAscent/WinDescent
- for CJK it "adds half of the external leading to the ascent, the
other half is added to the descent" because "the line height for
Asian fonts is too small", my reaction reading this was "WTF!"
The main problem here is that OS/2 Win metrics should never be used for
controlling line spacing[1] and Typo metrics should used instead[2]. The
Win metrics in the font are set to be higher than the highest/deepest
glyph in the font, else Windows will clip portions of the glyphs above
those values, for most fonts Win and Typo values can be the same, but
for some special fonts that have very big glyphs like Neo Euler[3], XITS
Math[4] or Cambria Math the Win values are much bigger resulting in huge
line spacing, see attached screen shots. #38683[5] is another example of
problems caused by this.
The attached patch is an attempt to bring some sanity to the situation:
* external leading = height - ascent + descent (line gap)
* internal leading = ascent + descent - EM_size
* if the font has an OS/2 table typo metrics are used
* no need for HHEA stuff as freetype derives its size metrics from it
anyway.
* removed the bogus CJK stuff
* removed check for freetype < 2.0 which we don't support anyway
This only done for 'unx' similar work is needed for 'win' and 'aqua',
but I'm not familiar with these platforms and can't test on it.
[1] http://www.microsoft.com/typography/otspec/os2.htm#wa
[2] http://www.microsoft.com/typography/otspec/os2.htm#sta
[3] https://github.com/khaledhosny/euler-otf
[4] http://en.wikipedia.org/wiki/XITS_font_project
[5] https://bugs.freedesktop.org/show_bug.cgi?id=38683
Mail in archive:
http://lists.freedesktop.org/archives/libreoffice/2011-August/017287.html
Screenshot attachments:
http://lists.freedesktop.org/archives/libreoffice/attachments/20110829/7d829a4b/attachment-0002.pnghttp://lists.freedesktop.org/archives/libreoffice/attachments/20110829/7d829a4b/attachment-0003.png
I tried to draw polyline.... But on Windows... the end point is not
drawn... the main problem is WinAPI LineTo() function. MSDN says:
The LineTo function draws a line from the current position up to, but
not including, the specified point.
I think WinAPI Polyline() function uses LineTo() to draw a polyline. I
see a hack in VCL module in WinSalgraphics::drawLine(): "we must paint
the endpoint" But there is no such hack for drawPolyLine() function. A
possible solution is same as for drawLine().
