The current default set of bullet characters used in the toolbar split button and dialog need to be improved. Below are lists from various sources. Current: bullet, large bullet, large diamond, large square, large right arrow with stem, right arrow half black & white, X mark, check HTML[1]: bullet, bullet with white fill, square (Wingding U+F0A7) MS Word 2010: bullet, circle (bullet with white fill), square, image, black diamond minus white X, arrow half black & white, check WordPerfect X7: bullet, large bullet, diamond, square, triangle (right arrow), empty checkbox, shadowed empty checkbox, checkmark, star, smiley face TextEdit (Mac): bullet, bullet with white fill, square, square with white fill, dash, check, diamond iWork Pages: bullet, 5-point star, 8-point star, 4-point star, 4-leaf clover, 4-piece diamond, check, arrow with stem, dash, small triangle pointing right, bullet with a stroke [1] https://www.w3schools.com/html/html_lists.asp
This list along with the unicode values for these bullets as well as images are available in this google doc. https://docs.google.com/document/d/16-6zkZl5LiICnUILhv1CfIHIdyQFyTJKp7XGST5zq5U/edit#bookmark=id.fjy2txljed77
Isn't this a dup of bug 106507?
@Jay, * Agree some change to that list are needed, and perhaps expand in the UI as for bug 106507 current list of bullets is here: http://opengrok.libreoffice.org/xref/core/svx/source/dialog/svxbmpnumvalueset.cxx#68 But, we are limited to what we provide hardcoded to OpenSymbol; and that font will likely need additional glyphs and movement of glyphs from PUA to correct Unicode codepoint. For example: BLACK DIAMOND SUIT U+e00c -> U+2666 BLACK SQUARE U+e00a -> U+25a0
I'm gathering all the information on this issue in this google drive folder https://drive.google.com/drive/folders/0B6qJrVIa0SAlMTR1ZjhaQVNxVk0 and working on the new list in this google spreadsheet https://docs.google.com/spreadsheets/d/1-ZnF1nkNXzbwb9rjCxztfxnXYAv5bK9QSsyTklOdqmI/edit?usp=sharing (In reply to V Stuart Foote from comment #3) > Agree some change to that list are needed, and perhaps expand in the UI as > for bug 106507 I think bug 106507 can be closed as a duplicate of this. > But, we are limited to what we provide hardcoded to OpenSymbol; and that > font will likely need additional glyphs and movement of glyphs from PUA to > correct Unicode codepoint. Yep that would need to be done. Who is maintainer of OpenSymbol? Khaled: Would that happen to be you. :D > For example: > BLACK DIAMOND SUIT U+e00c -> U+2666 U+E00C should go into U+25C6 (BLACK DIAMOND) U+E002 should go into U+2666 > BLACK SQUARE U+e00a -> U+25a0 yep
I only touch OpenSymbol when I really really have to.
(In reply to Khaled Hosny from comment #5) > I only touch OpenSymbol when I really really have to. So does that mean you are the maintainer? Would moving existing glyphs from one unicode position to another position be a difficult thing to do?
(In reply to Yousuf Philips (jay) from comment #6) > (In reply to Khaled Hosny from comment #5) > > I only touch OpenSymbol when I really really have to. > > So does that mean you are the maintainer? Would moving existing glyphs from > one unicode position to another position be a difficult thing to do? No to both questions, but be aware that there is code somewhere that depends on the exact code points in the font and will have to be fixed first.
(In reply to Khaled Hosny from comment #7) > No to both questions, but be aware that there is code somewhere that depends > on the exact code points in the font and will have to be fixed first. So any idea how to get in touch with the maintainer? Well we could always copy the glyphs to the new location and not disturb the other code. ;D
(In reply to Yousuf Philips (jay) from comment #8) > (In reply to Khaled Hosny from comment #7) > > No to both questions, but be aware that there is code somewhere that depends > > on the exact code points in the font and will have to be fixed first. > > So any idea how to get in touch with the maintainer? I have no idea who he is.
@Jay, we can change what we need to for OpenSymbol. Currently we are at v102.10 with 1055 glyphs, Mike K. did the last major batch of changes. But as Khaled mentions we have to be mindful of spots in the UI that call glyphs from OpenSymbol by PUA codepoint. So aside for bullets as here, IMHO OpenSymbol needs rework to ween ourselves from the PUA use in OpenSymbol to improve font fallback and for better use when substituting fonts in the LO UI.
Hi, referring to bug 106507 on "4 more default bullet types", there was kind of an agreement on new dash bullet types. I take some info from comment 8 in that bug by Yousuf: There were three dash types discused: - (U+2013) "Halbgeviertstrich" (in English: en dash / en rule) ‐ (U+2010) "Divis" (in English: hyphen) // TextEdit and iWork Pages have a dash preset, though Pages uses U+2D (which IMHO looks the same like U+2010) Indeed, it would be helpful to have two good dash bullet types. I personally prefer the U+2013, as it is a typographic standard in Germany (and other West European countries?) plus one shorter dash type, like U+2010 or U+2D
*** Bug 110455 has been marked as a duplicate of this bug. ***
(In reply to Susan Cragin from bug 110455) > It would be nice to have an empty square box as an option. I am a teacher > and print out lists that my students check off on paper copies. > In addition, the solid boxes (and the circle) take up too much toner so I > never use them anyway. I support this idea.
I'd just like to add a vote for this, and for empty squares. In Google Docs, I can put in an empty square and then right-mouse and change that one to a check mark. Great for to-do lists. An empty box is great for other lists, especially the paper ones I pass out to my students. Half of them don't bring computers to class, and I am always having them fill out forms. (You'd be surprised at what community college students don't have!) Also, when students study for classes, they typically now type their class notes, then print them out and study from them by highlighting them and scribbling all over them. And so there's a screen / paper thing going on there, too. Good for empty boyes And I'd like to repeat my comment that we should avoid anything that uses up too much toner, or have options that don't. I never use solid boxes partly for this reason. If you are developing other list markers, may I suggest something that means a question? Students often make lists of questions. Or points to remember ! Maybe you could have fat question marks and exclamation points.
(In reply to Heiko Tietze from comment #13) > I support this idea. I'm assuming this is U+25A1 and according to the google spreadsheet, you listed it as 'No' (row 19). :D (In reply to Susan Cragin from comment #14) > And I'd like to repeat my comment that we should avoid anything that uses up > too much toner, or have options that don't. I never use solid boxes partly > for this reason. All bullets are small so they dont take up much toner and ultimately its the user's choice of what bullet they prefer to use. > If you are developing other list markers, may I suggest something that means > a question? Students often make lists of questions. Or points to remember ! > Maybe you could have fat question marks and exclamation points. We are gathering a list of commonly used ones to use as defaults.
Hi, I would like to ask what the current status is with regard to the "new default set of bullet characters"? I also would like to ask how to transfer information from bug 106507 to here, because this bug here is more comprehensive. In that bug (here short summary), I had suggested to add following (they exist in OpenSymbol): – (U+2013) (EN DASH, in German: "Halbgeviertstrich") ‐ (U+2010) "Divis" (in English: hyphen) (not in OpenSymbol; thus Jay refers to U+2D (HYPHEN-MINUS), which is similar but not the same) ▸ (U+25B8) (BLACK RIGHT-POINTING SMALL TRIANGLE) → (U+2192) (RIGHTWARDS ARROW) In the discussion to that bug, Heiko (and Jay) were particularly in favor of the addition of EN DASH (Halbgeviertstrich), since it contributes to the typographical standardization (it is a typographic standard (e.g. in Germany)).
*** Bug 131160 has been marked as a duplicate of this bug. ***
*** Bug 157025 has been marked as a duplicate of this bug. ***