Age | Commit message (Collapse) | Author | Files | Lines |
|
This will help drawing the high contrast mode and makes the plus more
visible even given the background color.
|
|
|
|
|
|
|
|
|
|
Commit 3364fefe1e2dec522211040f2f9ea37bf5cd7466 introduced a new (and
font technically correct) handling of interline spacing that affects
line heights in all applications. Activate that only if
SAL_USE_NEW_LINEHEIGHT=1 is set in the environment, else use the old
handling until all quirks are sorted out.
|
|
XUnoTunnel.getSomething
|
|
|
|
See ML history for details:
Message-ID: <1315514308476-3321065.post@n3.nabble.com>
|
|
|
|
|
|
|
|
this local declaration makes no sense, based on the previous code, it seems
this is a rest of the former code change
|
|
|
|
Where not-Linux was in practice solaris. We can be pretty sure that the
ismultlingual path is effectively unused. so following that chain of logic
quite a bit can go.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Radek Doulik <rodo@novell.com>
|
|
|
|
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.png
http://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().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It doesn't make sense to try to use anything else to print on *nix
systems these days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
i.e. add the missing api directly to ServerFont
|