Bug 82604 - FORMATTING: Underlining exceeds paragraph mark
Summary: FORMATTING: Underlining exceeds paragraph mark
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
 
Reported: 2014-08-14 08:44 UTC by Marc PHILIPPE
Modified: 2022-02-16 15:56 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
ODT + TTF used + list of fonts WITHOUT the problem (59.34 KB, application/zip)
2014-08-14 08:44 UTC, Marc PHILIPPE
Details
Screenshot (123.58 KB, image/jpeg)
2014-10-20 07:41 UTC, Marc PHILIPPE
Details
Screenshots of 3 different behaviours (612.45 KB, application/zip)
2016-02-24 06:17 UTC, Marc PHILIPPE
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marc PHILIPPE 2014-08-14 08:44:43 UTC
Created attachment 104609 [details]
ODT + TTF used + list of fonts WITHOUT the problem

Problem description: 

Steps to reproduce:
1. Type a paragraph in font "Arial".
2. Underline it.
3. Change font to "Benguiat Frisky" (see below: b)
4. Insert special character "→" (see below: b) in the paragraph

Problem discovered on LO 4.3.1.1, Windows 7.

Expected behavior:
No underlining after the paragraph mark.

Current behavior:
a) The underlining exceeds the paragraph mark.
b) The problem only occurs if the special character is not defined in the font used. (I guess LO falls back onto a default font for drawing the character.) On Windows 7, most fonts don't have "→".
c) There is no problem if the paragraph begins with "→", but the exceeding underlining starts as soon as "→" is placed 2nd, and increases as "→" moves forward in the paragraph.

Operating System: Windows 7
Version: 4.3.0.4 release
Comment 1 Jacques Guilleron 2014-08-14 13:34:51 UTC
Hi Marc,

I tried this:

Options > LibreOffice > Fonts
In Replacement Table, Font:
Enter: Benguiat Frisky
Replace by:
Enter: Segoe Script
Check: Apply Button
Check: Allways and Apply replacement Table

Once reopened, the excessive underlining disappears.

Jacques

LO 4.3.0.4 & Windows 7 Home Premium
Comment 2 Jacques Guilleron 2014-08-14 13:56:14 UTC
So, you have to find a font with all the characters you want to use or avoid it.

Regards,

Jacques
Comment 3 Owen Genat (retired) 2014-10-11 12:07:31 UTC
(In reply to Marc PHILIPPE from comment #0)
> a) The underlining exceeds the paragraph mark.
> b) The problem only occurs if the special character is not defined in the
> font used. (I guess LO falls back onto a default font for drawing the
> character.) On Windows 7, most fonts don't have "→".
> c) There is no problem if the paragraph begins with "→", but the exceeding
> underlining starts as soon as "→" is placed 2nd, and increases as "→" moves
> forward in the paragraph.

Not reproducible under GNU/Linux using v4.3.2.2 with the provided example, regardless of whether Benguiat Frisky font is installed or not. Possibly only affects the Windows build.
Comment 4 tommy27 2014-10-20 05:12:07 UTC
reproducible under Win7x64 using LO 4.3.2.2. status NEW.

@Mark
please upload screenshots to make the bug easier to understand by other users.
thanks for your bug report.
Comment 5 Marc PHILIPPE 2014-10-20 07:41:59 UTC
Created attachment 108086 [details]
Screenshot
Comment 6 Marc PHILIPPE 2014-10-20 07:44:07 UTC
@tommy27: I've just uploaded the screenshot.
Comment 7 Buovjaga 2015-01-19 16:24:00 UTC
Could reproduce with Windows, but not with Linux.

Win 7 Pro 64-bit, LibO Version: 4.3.6.1
BuildID: 9629686a67dd1f357477c13325e45a66f3452bb9

Version: 4.5.0.0.alpha0+
Build ID: 5f6bdce0c0ac687f418821ce328f2987bf340cda
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-01-17_01:06:46

Ubuntu 14.10 64-bit Version: 4.5.0.0.alpha0+
Build ID: 0ffa3abc7d6c0437ece30cfb1430d28ffcc9f5c1
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2015-01-15_22:47:16

Version: 4.3.3.2
Build ID: 430m0(Build:2)
Comment 8 QA Administrators 2016-02-21 08:38:10 UTC Comment hidden (obsolete)
Comment 9 Marc PHILIPPE 2016-02-24 06:17:24 UTC
Created attachment 122933 [details]
Screenshots of 3 different behaviours
Comment 10 Marc PHILIPPE 2016-02-24 06:23:49 UTC
Bug still present in LO 5.1 on Windows, 
but behaviour changed because of bug 94597 (present since v5.0.2).

But the bug doesn't show up in LO 5 on Linux (Linux Mint).

See the details below 
+ screenshots of the 3 versions in attachment of Comment 9 (3behaviours.zip).

* BUG in LO 5.1.0.3 (Windows),
  behaviour CHANGED 
  because of bug 94597 (regression present since v5.0.2)

  - LO Version: 5.1.0.3 (x64)
  - Build ID:   5e3e00a007d9b3b6efb6797a8b8e57b51ab1f737   
  - OS:         Win 10 (x64)

* BUG in LO 5.0.1.2 (Windows),
  behaviour as originally stated 
  (bug 94597 not present yet)

  - LO Version: 5.0.1.2 (x64)
  - Build ID:   81898c9f5c0d43f3473ba111d7b351050be20261
  - OS:         Win 10 (x64)

* NOT present in LO 5, Linux build:

  - LO Version: 5.0.3.2
  - Build ID:   1:5.0.3~rc2-0ubuntu1~trusty2
  - OS:         Linux Mint 17.3 (x64) (running in Oracle VM on Windows 10)
Comment 11 Marc PHILIPPE 2016-02-24 06:24:12 UTC
Behaviour change tied with bug 94597.
Comment 12 QA Administrators 2017-03-06 16:10:43 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2019-12-03 14:19:09 UTC Comment hidden (obsolete, spam)
Comment 14 Buovjaga 2022-02-16 15:56:30 UTC
No problem anymore

Version: 7.3.0.3 (x64) / LibreOffice Community
Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3
CPU threads: 2; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: fi-FI (fi_FI); UI: en-US
Calc: threaded