Bug 133591 - Invisible caracter generate when export in .txt
Summary: Invisible caracter generate when export in .txt
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.3.6.2 release
Hardware: All Linux (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Save-Text
  Show dependency treegraph
 
Reported: 2020-06-01 18:32 UTC by fg
Modified: 2021-04-03 03:47 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description fg 2020-06-01 18:32:02 UTC
Description:
From Writer, you export in .txt
You open the file with a simple text editor* : there is a invisible caracter at the begining of the text (at left from the first letter or number).
So, it's not visible, but it is obvious when you import this text, for instance with "EasyTAG".

* Yes with "gedit", but no problem with "Mousepad" !

Steps to Reproduce:
1. "Enregistrer sous..." a text in ".txt"
2. Open the .txt with gedit
3. With "<" or ">", move the cursor to the right or left from the begining of the test to "detect" the invisible caracter

Actual Results:
Invisible caracter create

Expected Results:
No invisible caracter !


Reproducible: Always


User Profile Reset: No



Additional Info:
Only the text "raw"
Comment 1 V Stuart Foote 2020-06-01 20:25:04 UTC
Can not confirm on Windows builds
Version: 7.0.0.0.beta1 (x64)
Build ID: 94f789cbb33335b4a511c319542c7bdc31ff3b3c
CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

A Writer document 'save-as' to 'Text (*.txt)' contains no hidden characters at start of text.  

Verified with a gvim session 'Convert to HEX', only expected characters from the text body are present.
Comment 2 sebk 2020-06-02 09:03:03 UTC
I tried to reproduce:
1. open Writer
2. enter "abc" without (the "), no line feed
3. Save As -> Text (.txt)
4. open with an hex editor. The file holds 7 bytes:
EF BB BF 61 62 63 0A

These 3 first bytes are a UTF8 BOM (see https://en.wikipedia.org/wiki/Byte_order_mark ).

@fg: could you check your file if it is the same ? Maybe your text editor just misunderstands this.

The question is: should these be there or not. I think this is a design decision, some editors offer the choice to save txt file with or without BOM (Notepad++ on Windows has this).
Should LO have this ? I don't know.

About:
Version: 6.0.6.2
Build ID: 1:6.0.6-0ubuntu0.14.04.1
CPU threads: 8; OS: Linux 4.4; UI render: default; VCL: gtk2; 
Locale: fr-FR (en_US.UTF-8); Calc: group
Comment 3 Dieter 2020-06-04 17:44:52 UTC
I also can't confirm it with

Version: 7.0.0.0.beta1 (x64)
Build ID: 94f789cbb33335b4a511c319542c7bdc31ff3b3c
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL
Comment 4 Buovjaga 2020-09-03 16:48:58 UTC
(In reply to sebk from comment #2)
> I tried to reproduce:
> 1. open Writer
> 2. enter "abc" without (the "), no line feed
> 3. Save As -> Text (.txt)
> 4. open with an hex editor. The file holds 7 bytes:
> EF BB BF 61 62 63 0A
> 
> These 3 first bytes are a UTF8 BOM (see
> https://en.wikipedia.org/wiki/Byte_order_mark ).
> 
> @fg: could you check your file if it is the same ? Maybe your text editor
> just misunderstands this.

fg: please respond.
Comment 5 QA Administrators 2021-03-03 03:52:58 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2021-04-03 03:47:06 UTC
Dear fg,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp