The line numbering dot size changes if you save the file as a doc or docx file. Steps to Reproduce: 1. Open WRITER 2. Write any word 3. Select the Bullets On/Off icon in the toolbar at the top to have a line numbering for this word 4. Keep in mind the size of the line numbering dot 5. Save the file as doc / docx 6. Close the file 7. Reopen the saved file Result: The dot is larger in the doc and docx file. Remark: Actually I like this larger dot in the doc / docx file much more, because the initial LO dot is too small and the next selectable dot size in LO is to large. Reproducible with LO 4.3.3.2, Win 8.1.
CONFIRMED with LO 4.4.0.0.alpha2 + Ubuntu 14.04 (In reply to A (Andy) from comment #0) > The line numbering dot size changes if you save the file as a doc or docx > file. > > Steps to Reproduce: > 1. Open WRITER > 2. Write any word "Walrus" (using Liberation Serif 48pt) > 3. Select the Bullets On/Off icon in the toolbar at the top to have a line > numbering for this word > 4. Keep in mind the size of the line numbering dot Yes, it appears very tiny. If I put the cursor by it, the font claims to be OpenSymbol 12pt. > 5. Save the file as doc / docx First, I saved it as an ODT and reopened it. > 6. Close the file > 7. Reopen the saved file Ayup > > Result: > The dot is larger in the doc and docx file. After reopening, the font of the bullet 'dot' still claims to be OpenSymbol 12, but it is now much larger (and proportional to the text on the line). The dot now resizes up/down along with the rest of the text on the line. Same behavior exhibited when saving/reopening in DOC format.
Created attachment 116834 [details] Table of Bullet Characters in Different File Formats There are several things going on here: what the Special Characters dialogue reports and what the filters do when exporting and importing. For docx, Writer looks like it is interpreting a list style from the numbering.xml. The character style is probably also interpreted (see bug 92335) and probably takes its settings from the default paragraph for the document or the Normal paragraph. It is not setting the font to that used by the numbering. I have no idea where the font size is coming from. docx numbering.xml: <w:abstractNum w:abstractNumId="2"> <w:lvl w:ilvl="0"> <w:start w:val="1"/> <w:numFmt w:val="bullet"/> <w:lvlText w:val=""/> (F0B7) <w:lvlJc w:val="left"/> <w:pPr> <w:tabs> <w:tab w:val="num" w:pos="720"/> </w:tabs> <w:ind w:left="720" w:hanging="360"/> </w:pPr> <w:rPr> <w:rFonts w:ascii="Symbol" w:hAnsi="Symbol" w:cs="Symbol" w:hint="default"/> <w:rFonts w:cs="OpenSymbol"/> </w:rPr> </w:lvl> The next level down is: <w:rPr> <w:rFonts w:ascii="OpenSymbol" w:hAnsi="OpenSymbol" w:cs="OpenSymbol" w:hint="default"/> <w:rFonts w:cs="OpenSymbol"/> </w:rPr> In the above, "w:rFonts w:cs" is there twice. I don't know what that is about? It is not using OpenSymbol which does not have a glyph for U+F0B7. If you turn off Tools → Options → LibreOffice → View → Use system font for user interface and open the Special Characters dialogue in the Bullets and Numbering dialogue then you get block symbols. So it looks like there is an issue with that dialogue. In master, the system font option has been removed and that cannot be reproduced there. I have tried to get all of this jumble down but it has been difficult because there were several other bugs (bug 92335 & bug 92336) while trying to document this. The short of it: Why no U+2022? Windows Vista 64 Version: 4.4.4.2 Build ID: f784c932ccfd756d01b70b6bb5e09ff62e1b3285
Started with 3.5. Before, it wasn't even a dot.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20161108
Confirming with: Version: 5.4.0.0.alpha0+ Build ID: b894104a0b02a9b074c76feb925389d7bee6a493 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-12-10_01:00:52 Locale: nl-NL (nl_NL); Calc: CL
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Looks like still so in 6.4+.
*** Bug 68988 has been marked as a duplicate of this bug. ***
As I wrote in (bibisected) bug 68988, upon test with LO 6.4+: For LO created document, there's a problem with bullets (this bug). If MSO created document with bullets, LO opens and saves fine.
Current behaviour is that testing with 48 pt font size, the bullet is 12 pt upon creation. After saving to ODT, it grows to be in harmony with the text size. After saving to DOCX it grows a little bit more. Arch Linux 64-bit Version: 7.1.0.0.alpha0+ Build ID: bfbf745470cb6f99532523fdeffca061b37d8393 CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 31 May 2020
This is very irritating. Can someone explain why this keeps happening even after fixing all bugs? https://www.thatchfinder.com/directory/20216/antioch-roofing-pros/
*** Bug 140196 has been marked as a duplicate of this bug. ***
*** Bug 135610 has been marked as a duplicate of this bug. ***
From bug 140196 (duplicate) When moving the cursor to the bullet symbol, in ODT the font name is "OpenSymbol;Arial Unicode MS" while in DOCX it is "Liberation Serif".
(In reply to Telesto from comment #14) > When moving the cursor to the bullet symbol, in ODT the font name is > "OpenSymbol;Arial Unicode MS" while in DOCX it is "Liberation Serif". And this is likely the heart of the discussion. repro OpenSymbol in 7.6+