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:
184.108.40.206.0+ Build ID: 5c6f7f0920a91c974e9639f2c751582c8f140b2b
running on 64 bit Ubuntu 14.04.02 LTS
Please attach a document demonstrating the issue. Marking as NEEDINFO - once you attach a document set to UNCONFIRMED. Thanks
Dear Bug Submitter,
This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INVALID
due to lack of needed information.
For more information about our NEEDINFO policy please read the
wiki located here:
If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
Thank you for helping us make LibreOffice even better for everyone!
Sat, 10 Sep 2016 16:48:27 +0200
Created attachment 127246 [details]
Illustrates reason for filing Bug 92657
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
* 18pt (or ~0.5cm/0.2")
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.
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.
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.
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 ...
A user just posted a similar problem on the Document Foundation forum.
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.
In reference to comment 8. I have a document that was displaying fine in LO 5.1.4 Linux.
When I updated to LO 220.127.116.11 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 LO18.104.22.168 but also was not present on the PC.
Code pointer needed how to change the defaults for bullet lists.
After reverting back from 22.214.171.124, without any change to the bullet character style, this bug is not evident when my document is viewed in LO 126.96.36.199.0+. LO 188.8.131.52.0+ still reports the bullet font on my document as StarSymbol (which has not been installed).
A default new document created in LO 184.108.40.206.0+ with a bullet list, reports the bullet font as opensymbol. A default new document created in LO 220.127.116.11 with a bullet list, reports the bullet font as opensymbol. Opensymbol is installed in both cases.
In LO 18.104.22.168.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 22.214.171.124 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 126.96.36.199 displays extra leading with the first line using opensymbol.
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:
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...
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.
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.
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 188.8.131.52: #i63395# new default bullet characters and new default bullet font
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.
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!
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.
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.
With LO184.108.40.206 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.
(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.
(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.
Skimming few posts, it seems to be mostly speculation and misunderstanding of how bidirectional text is handled.
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.
(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.
Created attachment 129441 [details]
And here it is with the difference.
I just uploaded a snap of what I get, showing height difference using 220.127.116.11
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.
(In reply to Khaled Hosny from comment #23)
>... so it was a deliberate decision and not very long ago.
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.
(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.
(In reply to Khaled Hosny from comment #21)
When you say "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." it isn't clear to me what you mean by "this."
I was referring to undesirable font substitutions made while using Writer on Linux, which happens quite regularly and is rather easy to demonstrate by choosing a font for some passage that is known to have glyphs/characters required and then saving the file as either an .fodt or a pdf. These can be examined (in a text editor or Acrobat Reader respectively to see which fonts were actually used). I do suspect that how the fonts reported their capabilities has something to do with this, but I take pains to select the fonts carefully.
In the case of Thai, for instance, even with all the CTL settings set up for that, this happened to me just last week with one of the fonts in the tlwg group (the "official" set of fonts used by the Thai government, although I don't recall which one at the moment).
And particularly with Thai, I just noticed today that with the most recent release (18.104.22.168) the diacritic vowels are no longer rendered correctly in Writer using ANY font; I even went back and opened some earlier documents that displayed and printed correctly in earlier versions and they don't display correctly either.
But, as I said, this seems to me to be a different issue than the bullet issue, so probably belongs somewhere else.
(In reply to Khaled Hosny from comment #21)
** I must have posted this to the wrong place, as it isn't showing below: it's an earlier response I had posted.
Re: "paragraph direction and alignment are two different things." Certainly true (and, from many discussions here and elsewhere, it's obvious to me that anyone who cares about such things already knows this as well) but, I think, misses the primary point, which is to eliminate a bizarre and confusing user interface.
So: Two responses to your comment: "This usually means you didn’t set the paragraph direction and just aligned the paragraph to the right while leaving its direction LTR. No jumping would happen if the paragraph has RTL direction."
First off, I'm basing my own opinions on the idea that following the Unicode Standard in this regard *should be* the objective, since a) it is well thought out and b) results in an interface that is both more intuitive and far easier to use in practice. The reference for that, by the way, is http://www.unicode.org/reports/tr9/tr9-35.html for the official “Unicode® Standard Annex #9: UNICODE BIDIRECTIONAL ALGORITHM.”
So here goes.
To your point about setting the paragraph direction, you are correct. But why should a user need to do so if it is unnecessary? Annex 9 clearly recommends that the *default* paragraph direction should be set to the directionality of the first strongly directional character entered into a that paragraph. This is just my interpretation, of course, but it's bolstered by the fact that it makes life easier. More on the *default* in a bit ...
The Calligra Words and FocusWriter word processors, as well as the gEdit and Kate text editors both act in this manner, so it's not unheard of. Of course, neither word processor has the feature set of Writer, but that's not the scope of this discussion - I will say that, for some complex or extensive entry where intermingling of bidirectional text is required, I will switch to one of those to do the actual typing, and then copy the block to Writer to make use of its other features. In such situations, Writer's behavior is actually annoying.
Secondly, you seem to be assuming that paragraphs run in just one direction or another. For certain use cases, that's reasonable, of course, but as a general rule, that is entirely too limiting. (Think of translators, literary, morphological, and etymological analyses, and so forth).
Far and away the most annoying aspect of this is when initially entering an RTL phrase of more than one word in an otherwise LTR paragraph. Having the cursor jump to the right as each space (a non-directional or "neutral" as Annex 9 calls it) between each RTL word is entered is fun to watch, but certainly not what a typical user would expect.
Annex 9 does not specify this (although I've read some postings suggesting it does). The relevant section says “Generally, NIs [i.e. neutral and isolate formatting characters] take on the direction of the surrounding text. In case of a conflict, they take on the embedding direction.” But, if the user hasn't yet entered any character beyond the space, there is no SURROUNDING text - there is only PRECEDING text. The cursor should stay just where it is unless and until the user enters another LTR character. Of course this doesn't take into account very unusual needs (where the isolate formatting characters are needed), but for typical text entry, this is the most common use case for mixing bidirectional text in a single paragraph.
As a further comment on "No jumping would happen if the paragraph has RTL direction." The same distracting behavior will occur in the opposite direction if an LTR segment is entered into a RTL paragraph. (except when numeric digits are entered, which are mostly LTR even with RTL languages; they seem to be handled independently of other characters in most implementations - but again, that's a distraction from this particular thread).
The original poster also mentioned his struggle with placing the period at the end of a sentence; in a normally LTR paragraph containing bidirectional text that ENDS WITH the non-default directionality I could almost hear him screaming as it took me ages to figure out how to overcome that in Writer, but it seems that interpreting "surrounding" is the culprit here as well. I'm not sure if you've ever explained to a non-technical translator how to insert a zero-width character before, but it can turn into a fascinating conversation - I'd like to see Writer (and, to be fair) many other apps a bit more intuitive to use in such cases.
Editing text in bidirectional paragraphs is a bit different, of course, since the settled layout needs to be disrupted, but the issues there are a bit more involved than entry, so I'll leave well enough alone for the moment.
But thanks for responding; it's good to know that some attention is being bestowed on those (apparently very) few of us who type such things.
Are you, by the way, the "HarfBuzz" Khaled Hosny, or is that a different person?
(In reply to Frank from comment #28)
> (In reply to Khaled Hosny from comment #21)
> When you say "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." it isn't clear to me what you mean by "this."
The text I quoted above my reply, namely the “…seems to use OS services…” part.
> I was referring to undesirable font substitutions made while using Writer on
> Linux, which happens quite regularly and is rather easy to demonstrate by
> choosing a font for some passage that is known to have glyphs/characters
> required and then saving the file as either an .fodt or a pdf. These can be
> examined (in a text editor or Acrobat Reader respectively to see which fonts
> were actually used). I do suspect that how the fonts reported their
> capabilities has something to do with this, but I take pains to select the
> fonts carefully.
This might be a result from having three different font settings; for “Western”, “CTL” and “Asian” (in quotation marks because I find these terms questionable, but I digress). If you go to Format → Character → Font, you should see three different font selection widgets (if you have both “CTL” and “Asian” enabled). When LibreOffice detects that you switched to script that it categorizes as, say, CTL, it will use the CTL font and so on. I’m not saying this is ideal but it is the way things are right now.
> In the case of Thai, for instance, even with all the CTL settings set up for
> that, this happened to me just last week with one of the fonts in the tlwg
> group (the "official" set of fonts used by the Thai government, although I
> don't recall which one at the moment).
> And particularly with Thai, I just noticed today that with the most recent
> release (22.214.171.124) the diacritic vowels are no longer rendered correctly in
> Writer using ANY font; I even went back and opened some earlier documents
> that displayed and printed correctly in earlier versions and they don't
> display correctly either.
Please report any bugs or regressions you have, there were some changes in earlier 5.2.x releases that caused regressions in text layout and have since been reverted (see bug 103103).
Your last comment is really off-topic here, and I don’t this bug is the right place to discuss it. Feel free to open a new bug to discuss paragraph direction issue.
(In reply to Khaled Hosny from comment #30)
Thanks for the reply.
Your comment: "there were some changes in earlier 5.2.x releases that caused regressions in text layout and have since been reverted" made me remember that I had earlier installed a 5.3 testing image for the earlier bug hunting that I didn't have time to play with.
I tried that, loaded some of my docs, and the placement of diacritic vowels in Thai does indeed work correctly in that version.
Re: the "off topic" comment, I agree and said so in comment 28; there just seemed some momentum there that I didn't want to lose... Sorry!
(In reply to Frank from comment #32)
> Re: the "off topic" comment, I agree and said so in comment 28; there just
> seemed some momentum there that I didn't want to lose... Sorry!
Feel free to CC me for any bug report you think needs my attention.
*** Bug 104135 has been marked as a duplicate of this bug. ***
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.