Description: When I create a docx file in Writer to be converted to an ebook by Calibre, the Arial font is identified as Serif rather than Sans-serif. I can see this when I go into Calibre's edit mode. docx files created in either Word or Textmaker properly identify Arial as Sans-serif. I haven't tried other Sans-serif fonts to see if they are misidentified. Steps to Reproduce: 1.Create a docx file using Arial font 2.Open in Calibre to create ebook 3.Check ebook output in the editor Actual Results: Arial is identified as serif Expected Results: Arial is identified as sans-serif Reproducible: Always User Profile Reset: No Additional Info: Version: 6.4.0.3 (x64) Build ID: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8 CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded
Stephen, I don't Calibre, so I just could test with EPUB-Export in writer and I couldn't reproduce it (I tried with fonts Arial, Calibri, Liberation Sans). Perhaps somebody else can help. Version: 7.0.0.0.alpha0+ (x64) Build ID: 5dcbd1bb557450a2d658a710c163b310c0cee157 CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; Locale: de-DE (de_DE); UI-Language: en-GB Calc: CL
No time to test this now, but you can unzip the .epub file and investigate the contents. Perhaps you can find the snippet of markup that identifies it as Serif and share it here along with its location.
I wrote some text. Select all. Arial. Save document. Open Calibre. Open DOCX saved before with Arial. Generated E-pub. Open the E-pub document with Calibre editor. And I have this .block_ { display: block; text-align: justify; margin: 0; padding: 0 } .calibre { color: black; display: block; font-family: "Arial", sans-serif; font-size: 1em; padding-left: 0; padding-right: 0; margin: 0 5pt }
Created attachment 160947 [details] docx docx document
Created attachment 160948 [details] e-pub e-pub document
Arial is a sans-serif font, and is correct identified in my experiment with LibreOffice.
Try with a newer version of LibreOffice. I am using Version: 6.4.3.2 Build ID: 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: ro-RO (ro_RO.UTF-8); UI-Language: en-US Calc: CL 6.4.3 is much better than 6.4.0: 4 months plus of develpoment, hundreds of bugs solved between them.
(In reply to BogdanB from comment #7) > Try with a newer version of LibreOffice. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version. Change to RESOLVED WORKSFORME, if the problem went away.
For some reason the reporter sent me a CSS file in a private email. It had a rule .block_8 { display: block; font-family: "Arial", serif; font-size: 1.66667em; font-weight: bold; line-height: 1.2; page-break-after: avoid; page-break-inside: avoid; text-align: center; padding: 0; margin: 12pt 0 3pt } The value for the font-family property means that if Arial is not found, it falls back to the system default serif font. I tried to reproduce, but I don't understand how I can come up with this .block element. Stephen: you need to attach a minimal test case DOCX, so we are able to test for real.
If the first choice is Arial, than is a serif font, or any other font, I consider there is not a problem of LibreOffice, is a choise of the software to have Arial, and after that another font style. It is NOT about Arial as being a serif or sans-serif at all. So, judging by the title of the bug is not a bug.
(In reply to BogdanB from comment #10) > If the first choice is Arial, than is a serif font, or any other font, I > consider there is not a problem of LibreOffice, is a choise of the software > to have Arial, and after that another font style. > > It is NOT about Arial as being a serif or sans-serif at all. > So, judging by the title of the bug is not a bug. It is a bug, but we need the example file. The fallback is expected to be in line with the main font, so expectation would be sans-serif.
Dear Stephen Sottong, 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 INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO 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! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Stephen Sottong, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp