Bug 115946 - FORMATTING of RTF document with incomplete font table uses different substitution fonts
Summary: FORMATTING of RTF document with incomplete font table uses different substitu...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.4.5.1 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:rtf
Depends on:
Blocks: Font-Substitution RTF-Character
  Show dependency treegraph
 
Reported: 2018-02-22 21:14 UTC by robert
Modified: 2024-09-04 19:25 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Short file showing the problem - follow the steps in the comment box (3.40 KB, application/rtf)
2018-02-22 21:14 UTC, robert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description robert 2018-02-22 21:14:00 UTC
Created attachment 140072 [details]
Short file showing the problem - follow the steps in the comment box

This bug is (possibly) related to bug 115924.

The attached document contains Japanese characters encoded using "\uNNN" escape sequences. It does not contain any fonts in its font table that contain such characters, and as a consequence, it substitutes a font that does contain them, in casu "MS Minchu". The result is that the document is displayed correctly in Word.

When the document is subsequently selected in its entirety (Ctrl-A) and the font is changed into "Courier New", nothing happens, and when the cursor is put into the Japanese text, the font still shows as "MS Minchu".

Now repeat the procedure in Writer:

Due to the afore mentioned bug 115924, the formatting is incorrect, but

1) The substitution font here is "SimSun" (doesn't really bother us)
2) A "Ctrl-A" followed by a change of the font to "Courier New" will now also, when the cursor is moved to the Japanese characters, show their font as "Courier New", and this incorrect designation will survive a Save/Close/Open sequence.

However, unlike in Word, changing the font to "Courier New" will radically alter the formatting of the document, with the Japanese characters seeming to change their metrics to almost those of "Courier New", but not enough to display the table correctly. Manually changing them back to the "SimSun" font will, if one diligently does so for all of them, (obviously) display the table correctly again.

The same so saved (after step 2 above) document will still open correctly in Word, and Word will again use the "MS Mincho" substitution font, ***and*** will show that font in its font selection box.
Comment 1 Buovjaga 2018-03-08 17:30:58 UTC
(In reply to robert from comment #0)
> However, unlike in Word, changing the font to "Courier New" will radically
> alter the formatting of the document, with the Japanese characters seeming
> to change their metrics to almost those of "Courier New", but not enough to
> display the table correctly.

For me, it's not "almost", but perfectly.

Arch Linux 64-bit
Version: 6.1.0.0.alpha0+
Build ID: b8fe96f1da2c42c04a8094ca8c57d49763b7bded
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on March 8th 2018
Comment 2 QA Administrators 2019-03-13 03:46:10 UTC Comment hidden (obsolete)
Comment 3 robert 2019-03-15 17:44:36 UTC
Version: 6.2.1.2 (x64)
Build ID: 7bcb35dc3024a62dea0caee87020152d1ee96e71
CPU threads: 8; OS: Windows 6.1; UI render: default; VCL: win; 
Locale: en-GB (en_GB); UI-Language: en-US
Calc: threaded


Still present!
Comment 4 robert 2020-09-03 22:11:15 UTC
Still the same bug @

Version: 7.0.1.2 (x64)
Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452
CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-US
Calc: threaded
Comment 5 QA Administrators 2022-09-04 03:49:18 UTC Comment hidden (obsolete)
Comment 6 robert 2022-09-04 19:24:23 UTC
Still the same bug @
Version: 7.4.0.3 (x64) / LibreOffice Community
Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a
CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-US
Calc: CL
Comment 7 QA Administrators 2024-09-04 03:14:45 UTC Comment hidden (obsolete)
Comment 8 robert 2024-09-04 19:25:10 UTC
Problem still exits @

Version: 24.8.0.3 (X86_64) / LibreOffice Community
Build ID: 0bdf1299c94fe897b119f97f3c613e9dca6be583
CPU threads: 8; OS: Windows 7 Service Pack 1 X86_64 (6.1 build 7601); UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-US
Calc: CL threaded