Bug 113453 - Applying font replacement to a Word DOC document causes incorrect import and display of document, especially images are deleted
Summary: Applying font replacement to a Word DOC document causes incorrect import and ...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.4.2.2 release
Hardware: x86-64 (AMD64) macOS (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:doc
: 113452 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-10-25 23:36 UTC by Francisco
Modified: 2020-02-16 00:41 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
The document where the problem were found (308.50 KB, application/msword)
2017-10-25 23:38 UTC, Francisco
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Francisco 2017-10-25 23:36:12 UTC
Description:
If the font replacement is active, when I try to import a .doc document it misses a page and the images that contains. The document has a table and then some images that it supposed to be on the next page. The import filter put the images on the header, and I suppose, when apply the font replace rule, the page and his header are missing.

Steps to Reproduce:
1.Enable the font replacement rule
2.Open the .doc document
3.

Actual Results:  
Some inserted images are missed when open a .doc document whit the font replacement rule active (in this case futura for helvetica neue)

Expected Results:
The document opens with the font helvetica instead of futura and the images are placed on the second page


Reproducible: Always


User Profile Reset: No



Additional Info:
If I disable the font replace rule, the document opens with the images on the second page


User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Safari/604.1.38
Comment 1 Francisco 2017-10-25 23:38:22 UTC
Created attachment 137297 [details]
The document where the problem were found
Comment 2 V Stuart Foote 2017-10-26 04:19:55 UTC
*** Bug 113452 has been marked as a duplicate of this bug. ***
Comment 3 Alex Thurgood 2017-10-27 12:45:29 UTC
Confirming with

Version: 5.4.2.2
Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4
Threads CPU : 4; OS : Mac OS X 10.13; UI Render : par défaut; 
Locale : fr-FR (fr_FR.UTF-8); Calc: group
Comment 4 QA Administrators 2018-10-28 03:57:49 UTC Comment hidden (obsolete)
Comment 5 Roman Kuznetsov 2018-10-28 09:42:31 UTC
Francisco, I can't repro your bug in to

Version: 6.2.0.0.alpha1+ (x64)
Build ID: b439cfda24676c5272e3fe30c0a521975f948274
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2018-10-24_08:08:13
Locale: ru-RU (ru_RU); Calc: threaded

but may be I can not right understand your decription about "Enable the font replacement rule"

please retest your document in 6.2 alpha 1 yourself
Comment 6 QA Administrators 2019-10-29 03:30:00 UTC Comment hidden (obsolete)
Comment 7 eisa01 2020-02-16 00:41:52 UTC
This seems to work for me. Document looks the same as in Word

Not entirely sure on the font replacement, but the font Futura is used as you seem to indicate

Version: 7.0.0.0.alpha0+
Build ID: 0cb4f304abf6f8dd6b40eb800788d2fe80581813
CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded