Bug 115924 - FORMATTING Substituted font does not revert to original after last \uNNNN escape in RTF file
Summary: FORMATTING Substituted font does not revert to original after last \uNNNN esc...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:rtf
Depends on:
Blocks: Font-Substitution
  Show dependency treegraph
 
Reported: 2018-02-21 21:51 UTC by robert
Modified: 2018-03-08 17:31 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
File demonstrating the problem (7.74 KB, application/rtf)
2018-02-21 21:51 UTC, robert
Details
Second file with pre-massaged RTF still showing the FORMATTING problem (3.49 KB, application/rtf)
2018-02-22 20:38 UTC, robert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description robert 2018-02-21 21:51:39 UTC
Created attachment 140046 [details]
File demonstrating the problem

The attached .RTF file contains Japanese Unicode characters represented by \uNNNNN escape sequences. The problem is that the white-space after the last \uNNNNN character is also rendered in the substitution font (SimSun) which screws up the alignment of the table.

Note that MS Word also screws up the alignment, but at least the font will revert to "Courier New" after the last \uNNNNN escape.






As an aside, but that's is ***not*** the issue here, the fact that both LO Writer and MS Word screw up the alignment is (obviously?) caused by the fact that the SimSun (LO Writer) and MS Mincho (MS Word) substitution fonts have different metrics when compared to "Courier New"!
Comment 1 robert 2018-02-22 20:38:23 UTC
Created attachment 140067 [details]
Second file with pre-massaged RTF still showing the FORMATTING problem
Comment 2 robert 2018-02-22 20:41:50 UTC
The second file contains pre-massaged RTF (these files are created on z/OS using a mixture of PL/I and REXX) that still shows the problem - ungrouped (i.e. not enclosed in "{" and "}" white-space immediately following a group with a different font, such as "{\f1\charscalex60 \u23431\u37117\u23470\u24066}" will ***not*** revert to the original (in casu "\f0") font.
Comment 3 Buovjaga 2018-03-08 13:52:25 UTC
Confirmed. For me, the substitution font is Source Han Serif.
In 3.6 it is Noto Sans CJK TC Regular.
In 3.3, everything is just Courier New, but the alignment is still messed up a bit.

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

Arch Linux 64-bit
Version 3.6.7.2 (Build ID: e183d5b)

Arch Linux 64-bit
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4