Bug 65132 - Too big font when editing presentation
Summary: Too big font when editing presentation
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
4.1.0.0.beta1
Hardware: x86-64 (AMD64) Linux (All)
: high critical
Assignee: David Tardon
URL:
Whiteboard: target:4.2.0 target:4.1.0.1
Keywords:
: 65237 (view as bug list)
Depends on:
Blocks: mab4.1
  Show dependency treegraph
 
Reported: 2013-05-29 14:53 UTC by Petr Mladek
Modified: 2013-12-17 08:16 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot when editing itemized list in Impress (102.02 KB, image/png)
2013-05-29 14:54 UTC, Petr Mladek
Details
Screenshot when I press [ESC] and stop editing the itemized list. (112.72 KB, image/png)
2013-05-29 14:56 UTC, Petr Mladek
Details
Screenshot with the daily build from today (113.33 KB, image/png)
2013-06-03 16:02 UTC, Petr Mladek
Details
bibisect log (2.93 KB, text/plain)
2013-06-03 16:30 UTC, Jorendc
Details
see comment 14, w/r to the formulas (6.05 KB, image/png)
2013-06-08 05:41 UTC, Yury
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Mladek 2013-05-29 14:53:54 UTC
Impress 4.1.0.0.beta1 uses different font when editing itemized list and when showing the itemized list. The font is too big during editation, so that it is hardly readable.

The problem is best described by the attached sceenshots.

I use Linux SLED11-SP2, x86_64, GNOME, and the official LibreOffice 4.1.0.0.beta1 build.
Comment 1 Petr Mladek 2013-05-29 14:54:52 UTC
Created attachment 79972 [details]
Screenshot when editing itemized list in Impress
Comment 2 Petr Mladek 2013-05-29 14:56:20 UTC
Created attachment 79973 [details]
Screenshot when I press [ESC] and stop editing the itemized list.

The font is suddenly well readable.
Comment 3 Jorendc 2013-06-01 10:55:10 UTC
*** Bug 65237 has been marked as a duplicate of this bug. ***
Comment 4 Jorendc 2013-06-01 10:55:53 UTC
Exactly same behavior reported in Bug 65237 -> NEW
Comment 5 Jorendc 2013-06-01 10:56:27 UTC
@Petr: I think this one should be on the MAB. What is your thought?
Comment 6 Petr Mladek 2013-06-03 16:02:01 UTC
Created attachment 80236 [details]
Screenshot with the daily build from today

Sigh, it is even worse in the daily build libreoffice-4-1~2013-06-03_00.22.26_LibreOffice_4.1.0.0.beta1_Linux_x86-64_rpm.tar.gz

The text is almost missing when I stop editing. Impress is unusable now :-(
Comment 7 Jorendc 2013-06-03 16:07:25 UTC
Will take that bibisectrequest. Removing it before someone else start doing it (would be a waste of time ;-) )
Comment 9 Petr Mladek 2013-06-04 11:07:41 UTC
Joren, thanks a lot for the bibisect. It helped a lot.

The last critical status (comment #6) seems to be caused by the commit
http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-1&id=5e2d59e4b910631c802d5c7c42b7411e5a8b8db6
"Fix fdo#64972 - strikethrough displays too high"

I have reverted this to make Impress usable for 4.1.0.0.beta1 again.


The original problem went away after I reverted all the recent commits in vcl/generic/glyphs/gcach_ftyp.cxx. Especially the two:

+   http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-1&id=f9560c8f9982eaef09b74baa479c187f049c4f9e
 "Cleanup FreeType ascender/descender handling a bit"

+  http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-1&id=5e77c9e17ba7dd9d296c9b755093f01e7eb4f514
"Revert 052f181dad89ad34d90513bc9dcd3e3239727933"

Well, I reverted all the previous fixes in vcl/generic/glyphs/gcach_ftyp.cxx because there were conflicts.
Comment 10 David Tardon 2013-06-04 12:11:58 UTC
Khaled knows more about the use of fonts than I do, so I am stepping out.

dtardon->khaledhosny: The problema is probably in editeng/source/editeng/impedit3.cxx : my suspects are ImpEditEngine::RecalcFormatterFontMetrics() and ImpEditEngine::CreateAndInsertEmptyLine() .
Comment 11 Petr Mladek 2013-06-04 13:34:14 UTC
Khaled, if you are not able to reproduce it in your build. You might want to try a build with --with-distro=LibreOfficeLinux. It will use more internal libraries as defined in distro-configs/LibreOfficeLinux.conf. I see the problem with this configuration. David and Kendy saw it as well, so it has to be something more common.

Thanks in advance for looking into it.
Comment 12 ⁨خالد حسني⁩ 2013-06-07 08:09:55 UTC
I’m unable to reproduce this issue, neither with a 32 bit build on Ubuntu 12.04 nor with a 64 bit build on Debian unstable.
Comment 13 David Tardon 2013-06-07 08:18:41 UTC
all right, I take it...
Comment 14 Yury 2013-06-08 05:25:23 UTC
Might be related or not... W/r to the 1st shot: visually somewhat similar effect -- vertical stretch of the formula preview -- happens (quite often?) here after changing the font in formulas without going into formulas proper, e.g., with a script.

Also, ca. 2010-2011 I'd reported (the ticket got reorganised or smth., can't find it) cropping of the fonts in the writer's text after several changes of font in paragraph style. In such cases, the lower parts of the lines were getting cropped and lines were being sort of squeezed together vertically. Unpleasant side effect was navigation through the corrupted part of the text was being crippled (up and down cursor not working from middle of the line come to mind).

These days I experience this effect very seldom, almost never.
Comment 15 Yury 2013-06-08 05:41:57 UTC
Created attachment 80503 [details]
see comment 14, w/r to the formulas
Comment 16 Commit Notification 2013-06-12 10:34:43 UTC
David Tardon committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3a6513047409b8e8f6295152b33385ad8ef93681

fdo#65132 compute font height correctly



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 17 David Tardon 2013-06-12 10:46:47 UTC
The text is still stretched vertically, compared to that with disabled autofitting, but at least it is usable.
Comment 18 Commit Notification 2013-06-12 10:48:09 UTC
David Tardon committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ed31769088acc76eeed0f83b53227a429a5bf3a8&h=libreoffice-4-1

fdo#65132 compute font height correctly


It will be available in LibreOffice 4.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 19 Commit Notification 2013-06-20 11:24:27 UTC
David Tardon committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5f00be141d86e3eadddd554cd9d18ebe47d4d59b

Revert "fdo#65132 compute font height correctly"



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 20 Commit Notification 2013-06-20 14:24:49 UTC
David Tardon committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0a66aac248d69d7fc47f669b5757a52e0f06e38d&h=libreoffice-4-1

Revert "fdo#65132 compute font height correctly"


It will be available in LibreOffice 4.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 21 Yury 2013-06-20 17:53:40 UTC
I don't understand what has been done, and where, but # 55469 is regressed to where it were, and more, the environemtn variable SAL_USE_NEW_LINEHEIGHT solution isn't working in 4.1.0.1.
Comment 22 David Tardon 2013-06-21 04:28:08 UTC
(In reply to comment #21)
> I don't understand what has been done, and where, but # 55469 is regressed
> to where it were, and more, the environemtn variable SAL_USE_NEW_LINEHEIGHT
> solution isn't working in 4.1.0.1.

There had been a mistake in the new computation of internal leading, which Khaled fixed, but the fix did miss RC1. That was the real cause for this bug, bug 55469 and several others. Anyway, this discussion is irrelevant here, as this bug _is_ fixed in RC1 and will continue to be fixed--in a better way--in RC2.
Comment 23 Yury 2013-06-22 15:06:28 UTC
Thank you very much, then.
Is this fix accessible already via the git fetch-and-build -- scriptlibo_git_from_tar.sh environment?