Created attachment 123563 [details] PPTX with Fira Mono fonts Bug 90237 is about filesave. But, page 6, attached here has fileopen bug. Seems like Fira Mono fonts replacement problem, with additional paragraphs. Maybe this should be "Fonts" component, but it's not available.
Created attachment 123564 [details] compare PPTX fileopen in MSO 2010 and LO52+ without Fira Mono installed
Due to Bug 61134, substitute font is not shown. From http://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/VCL.xcu I can't see what's the replacement for Fira family.
Yes agree the isssue is handling of not-present fontname from the style. With no means of determining what font has been substituted. The tool tip does indicate the font is not available with the generic: "Font Name. The current font is not available and will be substituted" however what the substitute font becomes is not indicated. That is bug 61134. *** This bug has been marked as a duplicate of bug 61134 ***
Sorry, I don't agree this is a duplicate of Bug 61134. Indication of substitute font is only one problem. What is and where do we find a substitute font for Mira family at all? And, why do we have additional empty paragraphs? See "compare PPTX fileopen MSO LO52+".
@Timur, * There are no additional paragraphs, rather the substitute font has different font metrics and the text box holding the strings is wrapping. To demonstrate, select the text as replaced and reduce font size (24 -> 16), notice that the additional wrap lines (interplay of line length and text box spacing to margins) are removed from the text box. So you could say as a specific issue that LO is selecting a font family with poor font metric match for Fira Mono. But AFAICS the .PPTX provides no hinting other than direct formatting for mono space metrics--such that for an unknown (to LibreOffice) font we seem to only get a font substitution of DejaVu Sans Mono at 24 pt. The replacement font process is *arcane* (touchng import filters, and within VCL--and different mechanisms depending on OS). So, what the users really need to know is which font has been substituted for an otherwise valid paragraph or character style. And that is exactly issue of bug 61134, in that we do not know the specific font being substituted for the unknown fontname as imported. As an aside--SIL licensed Fira (metric equivilent FF Meta) might be good Sans and Sans Mono font to bundle.
(In reply to V Stuart Foote from comment #5) > There are no additional paragraphs, rather the substitute font has different > font metrics and the text box holding the strings is wrapping. To > demonstrate, select the text as replaced and reduce font size (24 -> 16) You're right. > So you could say as a specific issue that LO is selecting a font family with > poor font metric match for Fira Mono. When I installed Fira fonts, I got the same preview with LO as before. So, can we conclude that problem is not replacement font? Why is it still wrong then?
(In reply to Timur from comment #6) > > So you could say as a specific issue that LO is selecting a font family with > > poor font metric match for Fira Mono. > When I installed Fira fonts, I got the same preview with LO as before. > So, can we conclude that problem is not replacement font? No. And in fact, when I install FiraMono-Regular and open the .PPTX (v.14 Office 2010) in PowerPoint 2007, the 24 pt Fira Mono also wraps inside the PowerPoint textbox. Turns out our DejaVu Sans Mono replacement in 24pt is actually very close in metrics. And I have to reduce font size to 17.5pt to get it to fit in PowerPoint 2007. > Why is it still wrong then? Since it also affects earlier MS Office builds, there may be some direct formatting applied to the font in the document textbox that is not being picked up/described in the OOXML. That would be a NOTOURBUG, or at most a import filter issue. I didn't see anything in the XML but one of the filter devs might have a better idea. But, I'll check a MS Office 2010 and 2013 build of PowerPoint and see how those behave with FiraMono vs. DejaVu Sans Mono. Otherwise still suggest this be closed as duplicate of bug 61134, the UI issue being the general case of not knowing what the substitute font is short of comparing character by character against a font map.
Created attachment 123618 [details] compare PPTX fileopen in MSO 2010 and LO52+ with Fira Mono installed Previously, I attached "compare PPTX fileopen in MSO 2010 and LO52+ without Fira Mono installed" which showed that MSO 2010 opens it fine. Now, I attach "compare PPTX fileopen in MSO 2010 and LO52+ with Fira Mono installed" which shows that MSO 2010 also wraps, I don't know why. I took TTF Fira from https://github.com/mozilla/Fira.
Created attachment 123619 [details] compare PPTX fileopen in MSO 2010 and LO52+ when text set as DejaVu Sans Mono When text is set as DejaVu Sans Mono then it looks just like with Fira both in MSO and LO. So, it doesn't look to me like replacement font metrics problem.
Again, suspect some MS Office 2010 direct formatting of the textbox that is not picked up (nor apparently reproducible). So, resolve this as invalid? And perhaps a note back to bug 90237 that font substitution for missing fonts also can change the document round trip. Where possible folks on the LO side need to obtain the missing fonts to improve interoperability. Alternatively, fonts can be embedded into OOXML documents. Not unreasonable to ask originators using MS Office to enable that feature (full font, or just used characters)--especially for PowerPoint presentations. What I'm not sure about is how well having it set in source OOXML and also in ODF (File -> Properties -> Font: "Embed fonts in the document") behaves round trip.
I'd ask you to leave this open for a while, maybe someone will have an explanation. If not, I'll close it sometimes. I changed the title to what I see as a question now: "Fileopen: Fira Mono fonts shown different in PPTX with MSO and LO, only when not installed":
Reverting back to Stuart's titling as it is more correct and changing component to LibreOffice as this wont only affect Impress when the font is used. Similar discussion about font substitutions when on in my bug 91004, and the result was to contact fontconfig.
From the screenshots, that does not look like a font issue. I’m seeing extra empty lines and different indentation. This looks like formatting issue.
You're right. I'm sorry add cc-ed you, I'll remove you now. I don't know how I didn't figure out this before. Looks like Stuart was right all the time: "suspect some MS Office 2010 direct formatting of the textbox that is not picked up (nor apparently reproducible)". PowerPoint/Impress don't have Paragraph Mark toggle, but it seems LO doesn't read well some combination from this document like: semicolon, manual line break, tab. It happens twice, although there are manual line breaks and tabs on more lines.
reverting the 4.4 patch https://cgit.freedesktop.org/libreoffice/core/commit/?id=840f4fc4d677740fc4b0ebcb658f4a828e184dad helps somewhat. It is a place to start anyway.
Still repro in Version: 6.0.0.0.alpha1+ (x64) Build ID: a0ebba3d8855fee0bcec04a10137ae3a4f9f0e77 CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-11-22_05:59:17 Locale: zh-CN (zh_CN); Calc: group threaded
Dear Timur, 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
Seems better, all code is now within the box, unlike before. Somewhat different font, but not so important. I'll put WFM.