Bug Hunting Session
Bug 98650 - Formatting with manual line breaks and tabs from specific PPTX not shown properly in Impress
Summary: Formatting with manual line breaks and tabs from specific PPTX not shown prop...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:pptx
Depends on:
Blocks: PPTX-Paragraph
  Show dependency treegraph
 
Reported: 2016-03-14 14:55 UTC by Timur
Modified: 2019-05-28 09:28 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
PPTX with Fira Mono fonts (77.39 KB, application/vnd.openxmlformats-officedocument.presentationml.presentation)
2016-03-14 14:55 UTC, Timur
Details
compare PPTX fileopen in MSO 2010 and LO52+ without Fira Mono installed (80.19 KB, image/jpeg)
2016-03-14 15:03 UTC, Timur
Details
compare PPTX fileopen in MSO 2010 and LO52+ with Fira Mono installed (77.50 KB, image/jpeg)
2016-03-16 08:06 UTC, Timur
Details
compare PPTX fileopen in MSO 2010 and LO52+ when text set as DejaVu Sans Mono (77.30 KB, image/jpeg)
2016-03-16 08:09 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Timur 2016-03-14 14:55:52 UTC
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.
Comment 1 Timur 2016-03-14 15:03:07 UTC
Created attachment 123564 [details]
compare PPTX fileopen in MSO 2010 and LO52+ without Fira Mono installed
Comment 2 Timur 2016-03-14 15:08:26 UTC
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.
Comment 3 V Stuart Foote 2016-03-15 04:24:56 UTC
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 ***
Comment 4 Timur 2016-03-15 07:45:20 UTC
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+".
Comment 5 V Stuart Foote 2016-03-15 15:26:58 UTC
@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.
Comment 6 Timur 2016-03-15 16:11:57 UTC
(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?
Comment 7 V Stuart Foote 2016-03-15 17:30:44 UTC
(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.
Comment 8 Timur 2016-03-16 08:06:00 UTC
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.
Comment 9 Timur 2016-03-16 08:09:12 UTC
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.
Comment 10 V Stuart Foote 2016-03-16 14:16:18 UTC
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.
Comment 11 Timur 2016-03-16 14:48:21 UTC Comment hidden (obsolete)
Comment 12 Yousuf Philips (jay) (retired) 2016-09-20 20:03:32 UTC
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.
Comment 13 Khaled Hosny 2016-11-29 11:32:01 UTC
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.
Comment 14 Timur 2016-11-29 12:06:00 UTC
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.
Comment 15 Justin L 2017-05-06 18:37:58 UTC
reverting the 4.4 patch https://cgit.freedesktop.org/libreoffice/core/commit/?id=840f4fc4d677740fc4b0ebcb658f4a828e184dad helps somewhat.  It is a place to start anyway.
Comment 16 Volga 2017-11-23 11:17:06 UTC
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
Comment 17 QA Administrators 2019-05-28 02:47:27 UTC Comment hidden (obsolete)
Comment 18 Timur 2019-05-28 09:28:45 UTC
Seems better, all code is now within the box, unlike before. 
Somewhat different font, but not so important. 
I'll put WFM.