Bug 92657 - Questionable Default for Bullet Sizing
Summary: Questionable Default for Bullet Sizing
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevEval
: 104135 (view as bug list)
Depends on:
Blocks: Bullet-Number-Outline-Lists
  Show dependency treegraph
 
Reported: 2015-07-09 15:36 UTC by Frank
Modified: 2022-03-28 10:45 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Illustrates reason for filing Bug 92657 (27.83 KB, application/vnd.oasis.opendocument.text)
2016-09-10 16:26 UTC, Frank
Details
Bullets with measure lines (176.40 KB, image/png)
2016-10-05 14:53 UTC, Heiko Tietze
Details
Compare character height of Liberation Serif and OpenSymbol (21.24 KB, application/vnd.oasis.opendocument.text)
2016-12-09 19:36 UTC, Regina Henschel
Details
Screenshot, no line height difference (71.31 KB, image/png)
2016-12-10 01:54 UTC, ⁨خالد حسني⁩
Details
And here it is with the difference. (20.53 KB, image/jpeg)
2016-12-10 02:28 UTC, Steve Edmonds
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Frank 2015-07-09 15:36:34 UTC
If several lines are selected, and formatted as a bulleted list using 'Bullets On/Off' in the menu or sidebar (or Shift+F12), the default bullet vertical sizing is often inappropriate. This can be seen when any bulleted paragraph is long enough to wrap, and particularly so if the wrapping extends the paragraph to three or more lines.

Depending on the font in use, the line spacing/leading of the first line can sometimes be obviously greater than that of the remaining lines. While this may be desired in some circumstances, it certainly shouldn't be the default. The cure for this, of course, is to modify the character style "Bullets" (this is the default style used to format bullets) as required. Since the default settings use no line spacing or leading, the only simple approaches are to change the font, or to make the existing bullet font a smaller size.

The OpenSymbol font for bullets, by the way, is used regardless of whether the font in use contains its own 'matching' bullets or not. LibreOffice's default LiberationSerif font *does* have these symbols, typically from the General Punctuation block, u+2022 is the LO default.

With single line paragraphs, of course, this isn't as noticable until someone points it out.

I'm using LibreOffice Writer Version:
4.4.4.0.0+ Build ID: 5c6f7f0920a91c974e9639f2c751582c8f140b2b
running on 64 bit Ubuntu 14.04.02 LTS
Comment 1 Joel Madero 2015-07-11 22:41:18 UTC
Please attach a document demonstrating the issue. Marking as NEEDINFO - once you attach a document set to UNCONFIRMED. Thanks
Comment 2 Xisco Faulí 2016-09-10 15:02:34 UTC Comment hidden (obsolete)
Comment 3 Frank 2016-09-10 16:26:14 UTC
Created attachment 127246 [details]
Illustrates reason for filing Bug 92657
Comment 4 Heiko Tietze 2016-10-05 09:25:27 UTC
Bullets and numbering > Position of your example has the values of
* aligned at 18pt
* tab stop at: 36pt
* indent at: 36pt
(given you run units in points; didn't double check the defaults in my installation).

And when I understand your proposal right you want the default to be
* 0pt
* 18pt (or ~0.5cm/0.2")
* 18pt

I don't see the need to change the vertical spacing. You do not win a lot of space, and the text will be wrapped anyway. More relevant is that a list, whether numbered or not, is subordinate to the topic. The indentation makes sense.

Setting to NEW to get more opinions.

About OpenSymbol: I don't get this. But you should file different bug reports in any case.
Comment 5 Frank 2016-10-05 11:43:26 UTC
Hi Heiko:

Caution: if you are using Windows, you very likely cannot even see the problem; the reason for this is hopefully explained below. From your comments, I suspect you're not seeing the issue I describe. When I originally posted this bug, I mentioned that I was using Ubuntu, but didn't realize that the bug might be specific to Linux; the only other OS I was using, and had the problem with, was Fedora.

So, NO, I don't want (or even think it makes sense) to set any fixed values, as those should follow the font. And I have absolutely no issue at all with the *horizontal* spacing. I was merely pointing out several things:

1) The normal space between the first two lines [*vertical* spacing only - line leading or line-to-line spacing if you prefer] in a list with a bullet is distorted if the vertical size of the font used for the bullet doesn't match that of the text.

2) This bug has absolutely nothing to do with wrapping; the problem exists regardless. It's true that it only becomes glaringly obvious when there are multiple lines in the paragraph but, in such cases, the vertical distance (leading, etc) between the first and second lines is different than that between any subsequent pair of lines.

3) Writer should not attempt to substitute a bullet from another font if that bullet already exists in the font used for the text. Note that this happens very frequently in Writer in all contexts, although I suspect it has more to do with either Linux's utility for checking the fonts or, even more likely, poor construction of the fonts themselves. My understanding is that such errant and unnecessary font substitution does NOT happen in Windows (which apparently uses a different mechanism for examining fonts), but I can't confirm that.

Therefore: this is why, if you are using Windows, it is quite possible that you cannot even see the problem.

I've come to believe that this bug is merely one more symptom of the latter issue, but if you were to be able to "force" the line height of the bullet to match that of the text (which can be done manually, but is very tedious), that would be a welcome band aid.

Let me know (publicly or privately) if there are any other questions I can answer, or examples I can give.
Comment 6 Heiko Tietze 2016-10-05 14:53:36 UTC
Created attachment 127828 [details]
Bullets with measure lines

You mean the unnecessary substitution of Liberation Serif by OpenSymbol corrupts the line spacing. It's also visible in Windows, depending on the zoom factor (trying to illustrate with measure lines).

If that's true I would agree that we have a bug - if there is no other reason to use OpenSymbol as default.
Comment 7 Frank 2016-10-05 16:12:22 UTC
Great illustration; I should have done something like that in the first place. Be aware that the differences illustrated can vary from subtle to glaring depending on the particular font and point sizes used.

But, yes - that's indeed the problem I was describing.

A word of caution, though, if you're about to grab this bug to work on: The more I've looked into this, the more I get the distinct feeling that it might actually be a way more frustrating thing to address than it appears on the surface. So grab plenty of your favorite snacks and beverages before diving in!!

Thanks for the quick response ...
Comment 8 Frank 2016-11-25 12:39:41 UTC
A user just posted a similar problem on the Document Foundation forum.

See: http://nabble.documentfoundation.org/Line-spacing-changed-td4200592.html

As part of my response to him I said (among other things): "You CAN, by the way, sort of make the problem disappear by editing the bulleted list style and specifying a smaller bullet or your default font. Go to Styles and Formatting either from the Menu, the sidebar, or by pressing F11. Then choose Character Styles, and then Bullets (this latter does NOT appear unless you are set to "Show ALL styles" and even then it may show up as a series of 7 boxes instead of the characters "Bullets."

Then, choose "Modify" and you'll see that Writer is not using your paragraph font for the bullets. Here you can do one of two things: making sure that you can see the actual document, change the font size and press "Apply" - if your paragraph size is set to 12, for instance, set the bullet style to 10 and see what happens. (Actually, first try setting it much larger and press Apply just to prove to yourself that this is the cause of your particular problem.)  The other option is to simply change the font to the one you are using as the paragraph font and you'll see the problem disappear."

I had not noticed these two things when I first posted this bug, so hopefully that will help someone ferret out its cause. The 7 boxes mentioned in the first paragraph should be a big clue, and the suggestion to change bullets to larger sizes while in the dialog boxes helps I think to "see" the issue more clearly.
Comment 9 Steve Edmonds 2016-11-27 08:37:24 UTC
In reference to comment 8. I have a document that was displaying fine in LO 5.1.4 Linux.
When I updated to LO 5.2.3.3 the bug as described here was evident. The bullet character style font was starsymbol and not present on my machine. Changing the bullet character style font to arial as the bulleted text was, removed the extra leading space and the document displayed correctly.
The document with the unchanged bullet style starsymbol) displayed correctly on windows 7 32 bit with LO5.2.1.2 but also was not present on the PC.
Comment 10 Heiko Tietze 2016-11-27 11:39:45 UTC
Code pointer needed how to change the defaults for bullet lists.
Comment 11 Steve Edmonds 2016-11-27 19:15:38 UTC
After reverting back from 5.2.3.3, without any change to the bullet character style, this bug is not evident when my document is viewed in LO 5.1.6.2.0+. LO 5.1.6.2.0+ still reports the bullet font on my document as StarSymbol (which has not been installed). 
A default new document created in LO 5.1.6.2.0+ with a bullet list, reports the bullet font as opensymbol. A default new document created in LO 5.2.3.3 with a bullet list, reports the bullet font as opensymbol. Opensymbol is installed in both cases.

In LO 5.1.6.2.0+ the vertical line spacing and bullet (visual) size is consistent with bullet style font setting of StarSymbol (not on system), Opensymbol (on system) or arial (on system, also the font of the bulleted text). There is no extra leading in the first line in any case.

In LO 5.2.3.3 using bullet style font setting of arial (on system, the font of the bulleted text) there is no extra leading in the first line. Using opensymbol, there is a little extra leading. Using starsymbol there is most extra leading and the bullets are visually bigger.

The interesting thing here is that even when there should be no font substitution (open symbol and arial both available and both have U+2022 which I assume is used), LO 5.2.3.3 displays extra leading with the first line using opensymbol.
Comment 12 Frank 2016-11-27 20:34:08 UTC
The substitution of fonts even when the font in use has the necessary characters is actually a separate, larger problem, so don't confuse the two.

LibreOffice seems to use OS services to layout text and those seem to do the actual substitution in many cases. These services in turn rely on what the font file reports as the characters it contains and what it can do with them.

To simplify even further - if the font files themselves are faulty (and this occurs more than you might think), trouble arises.

A few of us had a recent discussion about this on the Doc Foundation forum. See:
http://nabble.documentfoundation.org/Struggling-with-Hebrew-in-LO-td4198211.html

But there is still a real issue with the bullet substitutions, which appears to be a separate and unrelated bug, although it doesn't seem impossible that the two might meet up someday to breed and then attack us all one day...
Comment 13 Steve Edmonds 2016-11-27 22:46:47 UTC
Not so simple, but at least I have a work around. I notice in the character style, bullets, Organizer tab that there are 3 entries (minimum) for bullets. 2 relate to the font selection in the fonts tab and one doesn't seem to change. On a default document this is opensymbol. In my document it is starsymbol.
Comment 14 V Stuart Foote 2016-12-09 17:06:17 UTC
Comments from the Design ML minutes for 2016-12-08...
>  * Bullet lists defaults
>    + https://bugs.documentfoundation.org/show_bug.cgi?id=92657
>    + Option 1: Replace OpenSymbol as default for bullets by text default
>    + Option 2: Reduce bullet size so that spacing is not affected by symbols
>    + code pointers needed
>    -> no easy hack, needs investigation

-- Khaled --

So what is the actual bug here, the use of OpenSymbol (is this a new
change?) or that line spacing for OpenSymbol changed? If it is the
later, it might be worth seeing if any of the edits to the font over the
years changed its line spacing (I recently did touch them, but just to
unify the various parameters, some of them were obviously broken). It
might also be possible to set the bullet style to have a fixed and very
small line spacing so that it is always smaller than the text font.

I can’t reproduce this issue here; I see no line spacing differences in
the attached document. 

-- Sutart --

The history (and code pointers) on use of OpenSymbol as default font for bullet lists can be found in this series of OOo issues archived with the Apache OpenOffice project.

https://bz.apache.org/ooo/show_bug.cgi?id=59997
https://bz.apache.org/ooo/show_bug.cgi?id=60263
https://bz.apache.org/ooo/show_bug.cgi?id=63395#c13
https://bz.apache.org/ooo/show_bug.cgi?id=88261

The OpenSymbol font has had problems with font metrics as can be seen in i59997, and of course on the LibreOffice side we've also made adjustments with some work still needed (e.g. tdf#103740).

As noted in c13 of i63395 the 2022, 25e6, 25aa from OpenSymbol were hardcoded and remain default glyphs for bullet lists. They are unstyled, so will resize as the paragraph font is resized, but will not otherwise match the font metrics of the font of the paragraph.

Commit to CVS for OpenOffice
2008/06/06 08:49:04 od 1.50.16.1: #i63395# new default bullet characters and new default bullet font
https://cgit.freedesktop.org/libreoffice/core/commit/?id=345d77aa3406c1630270e1459324ed5bf35fff11

But I believe most of the original issues (StarOffice -> OpenOffice, and ww8 import/export filter) are probably no longer valid reasons to not allow more general font fallback to handle the bullet replacement--but that would need to be investigated a bit more deeply.

But if that is the case, we could rector the static assignment of OpenSymbol to bullet lists when paragraph font provides the glyphs and allow them to assert eliminating these valid spacing issues.
Comment 15 V Stuart Foote 2016-12-09 17:07:38 UTC
s/rector/refactor
Comment 16 Frank 2016-12-09 19:23:46 UTC
As the Original Poster, here's my view -

Some folks will take whatever font is given and not notice the difference; others (myself included) choose fonts carefully for different purposes (e.g. which Scripts/Languages it supports, which styles are available, how well it arranges combined glyphs within in cell, etc.).

Therefore, I would vote strongly that your (Stuart's) last comment:

"refactor the static assignment of OpenSymbol to bullet lists when paragraph font provides the glyphs and allow them to assert eliminating these valid spacing issues."

be the default behavior!

Choices such as automatic behind-the-scenes switching to a(ny) symbol font were once necessary in the days of StarOffice and its successors in order to keep users from having to put up with * and # as their only bullet choices. We're all grown up now (from a technological standpoint). Any decent modern font has an abundance of stylistically appropriate choices for those who care.

Go for it!

Frank
Comment 17 Regina Henschel 2016-12-09 19:36:23 UTC
Created attachment 129433 [details]
Compare character height of Liberation Serif and OpenSymbol

(In reply to V Stuart Foote from comment #14)
> I can’t reproduce this issue here; I see no line spacing differences in
> the attached document. 

Set a background color to the bullet. For the anonymous list it is the character style "Bullets". And set a different background color to the first characters of the text and another different background color to the paragraph. You will notice, that the bullet is a little bit larger that the character of the text, although both are 12pt.

The problem is not only for bullets and lists, but it comes up with each OpenSymbol character. "OpenSymbol" 12pt is a little bit higher than "Liberation Serif" 12pt.

The file I have attached, has set OpenSymbol as reference for "register true". The middle column uses a "register true" Liberation Serif, the left column uses a normal Liberation Serif. You will notice, that in the left column the vertical expanse is smaller than in the middle.

And the other way round, if you set the reference style to Liberation Serif, then in the right columns you see large space, because OpenSymbol only snap to every second line.
Comment 18 Regina Henschel 2016-12-09 19:53:55 UTC
For the anonymous bullet list the character style "Bullets" is set as default, which includes OpenSymbol. For a named bullet list the character style "Numbering Symbols" is set as default, which does not contain any font settings.
For the anonymous numbered list the character style "none" is set as default, for a named numbered list the character style "Numbering Symbols" is set as default.
That is inconsistent.

@Frank: Goto character style Bullets, tab Font and remove the setting OpenSymbol by clicking on button "Standard", or goto the tab Options in the list properties and set the character style to "none". One of them, should solve your problem for now.
Comment 19 Steve Edmonds 2016-12-09 20:21:19 UTC
With LO5.2.3.3 I am displaying larger bullets and with LO5.1.6 I am not, for the same file. Is this a LO font display (font rendering) issue or a font substitution issue or when I swap LO versions is the font swapping also.
Comment 20 Frank 2016-12-09 21:50:00 UTC
(In reply to Regina Henschel from comment #18)

Regina: Thanks so much for suggesting work-arounds, but I already know and use several; I just get annoyed at the number of work-arounds I need to use with LibreOffice to solve the many "issues" which don't seem to matter much to most people. Perhaps I'm just too critical, but Stuart seems to have corralled this particular annoyance into a corner, and I just wanted to offer my encouragement.

One of these days I hope to be able to just freely intermix multiple Scripts and Languages; choose fonts without having Writer just replace them when it feels like without telling me; reload documents without finding that some paragraphs have just wandered onto the next page for reasons I can never figure out; print directly from Writer instead of having to first generate a pdf and use the Acrobat Reader, which prints things where I put them on the page and even - wonder of wonders - prints double sided documents without the two sides looking like they have entirely different margins and so forth.

I like LibreOffice Writer - I really do - none of the other FOSS offerings come close (and I have pretty much every one of them available), but I have such mixed feelings each time a new LO release is downloaded. Was something I care about finally fixed? If so, what regressions were introduced that I won't discover until too late?

But, as I said, thanks very much for taking the time to help.

Frank
Comment 21 ⁨خالد حسني⁩ 2016-12-10 01:21:34 UTC
(In reply to Frank from comment #12)
> The substitution of fonts even when the font in use has the necessary
> characters is actually a separate, larger problem, so don't confuse the two.
> 
> LibreOffice seems to use OS services to layout text and those seem to do the
> actual substitution in many cases. These services in turn rely on what the
> font file reports as the characters it contains and what it can do with them.

This was never the case on Linux, and no longer the case on other platforms in 5.3; we have full control over the text layout and font fallback.

> A few of us had a recent discussion about this on the Doc Foundation forum.
> See:
> http://nabble.documentfoundation.org/Struggling-with-Hebrew-in-LO-td4198211.
> html

Skimming few posts, it seems to be mostly speculation and misunderstanding of how bidirectional text is handled.
Comment 22 ⁨خالد حسني⁩ 2016-12-10 01:54:12 UTC
Created attachment 129440 [details]
Screenshot, no line height difference

(In reply to Regina Henschel from comment #17)
> Created attachment 129433 [details]
> Compare character height of Liberation Serif and OpenSymbol
> 
> (In reply to V Stuart Foote from comment #14)
> > I can’t reproduce this issue here; I see no line spacing differences in
> > the attached document. 
> 
> Set a background color to the bullet. For the anonymous list it is the
> character style "Bullets". And set a different background color to the first
> characters of the text and another different background color to the
> paragraph. You will notice, that the bullet is a little bit larger that the
> character of the text, although both are 12pt.

I just did that and the screenshot is attached, the bullet line has the same descender as the text line and the ascender is actually shorter.
Comment 23 ⁨خالد حسني⁩ 2016-12-10 01:57:11 UTC
(In reply to V Stuart Foote from comment #14)
> But I believe most of the original issues (StarOffice -> OpenOffice, and ww8
> import/export filter) are probably no longer valid reasons to not allow more
> general font fallback to handle the bullet replacement--but that would need
> to be investigated a bit more deeply.

Thanks for digging this up, so it was a deliberate decision and not very long ago. I’d be hesitant to take any change lightly here, without actually assessing its implications; just assuming any original issues has solved themselves by now is not enough IMO.
Comment 24 Steve Edmonds 2016-12-10 02:28:22 UTC
Created attachment 129441 [details]
And here it is with the difference.

I just uploaded a snap of what I get, showing height difference using 5.2.4.1
Comment 25 ⁨خالد حسني⁩ 2016-12-10 02:59:25 UTC
I’m testing against 5.3 here, and I suggest others to do the same since there have been changes to how line height is calculated and to OpenSymbol metrics since the last release.
Comment 26 V Stuart Foote 2016-12-10 06:32:04 UTC
(In reply to Khaled Hosny from comment #23)
>... so it was a deliberate decision and not very long ago. 

Eight years‽  

That's three years while under OOo, and then five years of our entire development effort--where we've done 116 release builds and countless dailies.  No rush obviously, but think this area of font handling is past due for some pruning.
Comment 27 ⁨خالد حسني⁩ 2016-12-10 06:58:33 UTC
(In reply to V Stuart Foote from comment #26)
> (In reply to Khaled Hosny from comment #23)
> >... so it was a deliberate decision and not very long ago. 
> 
> Eight years‽  

For the kind of change we are discussing here, yes. But I’m getting way out of my comfort zone, so I’ll leave more knowledgeable people to decide, ad far as font metrics are concerned I can’t reproduce the issue.
Comment 28 Frank 2016-12-11 05:50:35 UTC Comment hidden (off-topic)
Comment 29 Frank 2016-12-11 05:56:42 UTC Comment hidden (off-topic)
Comment 30 ⁨خالد حسني⁩ 2016-12-11 10:59:29 UTC Comment hidden (off-topic)
Comment 31 ⁨خالد حسني⁩ 2016-12-11 11:07:16 UTC Comment hidden (obsolete)
Comment 32 Frank 2016-12-11 11:31:07 UTC Comment hidden (off-topic)
Comment 33 ⁨خالد حسني⁩ 2016-12-11 11:39:47 UTC Comment hidden (off-topic)
Comment 34 Steve Edmonds 2017-05-31 20:25:03 UTC
*** Bug 104135 has been marked as a duplicate of this bug. ***
Comment 35 Heiko Tietze 2020-03-27 10:31:10 UTC
Summarizing from the UX perspective:

a) => wfm (cannot confirm the issue)
b) => nab (if there is a difference in descenders it's up to the font designer; OTOH it's unclear which to keep),
c) => wf (smaller bullet size is not a solution)

The only solution is to use the actual paragraph font for the bullets; and to accept if the font has no bullet defined. The problem here might be that the bullet character is not easy to find.

An alternative is maybe to cut the bullet at the baseline of the paragraph.
Comment 36 QA Administrators 2022-03-28 03:40:25 UTC Comment hidden (obsolete)
Comment 37 Frank 2022-03-28 10:45:06 UTC
I only tried this just now on 7.3.1.3 with a few fonts and only with Latin script, but it seems to behave properly now.

I quit using bullets with LO about five years ago since they were unpredictable (though, as I said in the original discussions, I suspect part of the issue is related to malformed fonts and what they report to apps), so maybe I'll give them a try when the opportunity arises.

So it might as well be closed if no one has looked at it or complained about it in almost six years.