Summary: | Font metrics are wrong | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Stephan Schutter <stephan.schutter> |
Component: | Impress | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED INSUFFICIENTDATA | ||
Severity: | normal | CC: | telesto, vsfoote |
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 108226 |
Description
Stephan Schutter
2019-04-29 14:13:55 UTC
This should be marked as major since it prevents the use of the software in all but a few situations. Nothing actionable here... Unlikely to be font metrics, more likely it is differences in internal structure of an OOXML/MS Office binary or MS Office XML document as compared to structure of an ODF document. Documents (ODF or OOXML) are filter imported into LibreOffice, and they are filter exported out to corresponding formats--if you can avoid round trips ODF -> OOXML -> ODF you'll have better formatting results. MS Office will open/produce ODF, or OOXML strict (giving the filters a better chance for fitelity). Second caveat is that internally, LibreOffice is optimized for ODF, filter import/export of MS formats, while good is never going to match fidelity of ODF. Finally there are occasions when the build of a font has different font attributes Windows systems have fonts that Linux systems substitute--and vice-a-versa. But that does not seem to be the complaint here. Have a read of META bug 108226 or META bug 103494 structure of Text Box objects is a major difference between MS and ODF formats, import filters can only do so much--they'll never be exact matches and "round trip" of a document is particularly error prone. |