Description: The attached document, when opened in Writer, looks like garbage. The also attached .PDF shows how it should be displayed. Version: 6.4.5.2 (x64) Build ID: a726b36747cf2001e06b58ad5db1aa3a9a1872d6 CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; Locale: en-GB (en_GB); UI-Language: en-US Calc: threaded What is the use of V7 with a gazillion more features, when even such a simple document cannot even be rendered OK? Steps to Reproduce: 1. Open file Actual Results: Garbage Expected Results: Open the PDF Reproducible: Always User Profile Reset: No Additional Info: Opened it the way Word XP opens it
Created attachment 163456 [details] File that renders completely wrong in LO
Created attachment 163457 [details] This is the way it should be displayed Note the file uses a commercial font (Cubiculum), replacing it with Courier New results in the same rendering.
Can not confirm. This RTF format document is formatted with a "Cubiculum" monospaced font at 10pt--which of course is not going to be present most systems. Substitution of Courier New will work--but with bcz of different font metrics would need to be reduced to 9pt, but the tab stops (haphazardly set on generation of the RTF) will cause issues for the alignment and lines. There is no expectation that an RTF formatted document will be filter imported with 100% fidelity. IMHO the import filter is good enough, not worth dev effort needed to improve. Please work in ODF--we "guarantee" that format.
Cubiculum is on my system, and the formatting in LO is screwed up, Word has absolutely no problems with it. And don't tell me to use .ODT, unless you have a version of LO that runs on IBM's z/OS, which is where dozens of our files originate. .ODT is a stunningly complicated bloatware format and .RTF is just simple plain text that can very easily be created on z/OS. And your "but the tab stops (haphazardly set on generation of the RTF) will cause issues for the alignment and lines." remark is plain arrogant! The tabs were purposely set to the values in the document to generate the three-column layout! Stop adding new "new shiny and whiter than white" features to the suite, and concentrate on removing bug like these, you know, that 80/20 rule! People needing the most complicated functions work in environments where the price of an office suite is 0.001% of their daily turnover, and nobody gives an (fill in your favourite expletive) about it!
Found in 3.5.7.2 but not in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
(In reply to robert from comment #4) If there is a rush to get this solved: https://www.libreoffice.org/download/libreoffice-in-business/ Or for contributions https://wiki.documentfoundation.org/Development
(In reply to robert from comment #4) > Stop adding new "new shiny and whiter than white" features to the suite, and > concentrate on removing bug like these, you know, that 80/20 rule! People > needing the most complicated functions work in environments where the price > of an office suite is 0.001% of their daily turnover, and nobody gives an > (fill in your favourite expletive) about it! -> For my curiosity: is there also a rule where to start with 'bug like these'. There are a quite a number of those, sadly, IMHO (not talking about RTF specifically) So is there also a rule on how to set priority's. All those bug more or less 'trivial' in some way. Don't think that RTF is the most used format these day's (but of course depending on system; user case etc). So rather hard to define what's important or not. Especially with a suite with quite some functionality FWIW: on the RTF format: https://bugs.documentfoundation.org/showdependencytree.cgi?id=81234&hide_resolved=1
(In reply to robert from comment #4) > Cubiculum is on my system, and the formatting in LO is screwed up, Word has > absolutely no problems with it. > Great use MS Word, RTF is a Microsoft 'non-format' that we must filter import--we do not edit it directly. > ... You use an undocumented file format generated from a niche os with a proprietary monospaced font and expect 100% fidelity on filter import to LibreOffice? Who is at fault here? We do give a @#$%! here... INMHO filter import of the RTF source document is acceptable, and it remains => WFM
A RTF specification is available. The attached file only uses explicitly documented RTF features. And, sadly, Windoze probably runs 90+% of all desktops, so don't call it a niche OS, because nobody in their right mind is going to edit documents with either LO or M$ Office on Android.
(In reply to Telesto from comment #7) > (In reply to robert from comment #4) > > Stop adding new "new shiny and whiter than white" features to the suite, and > > concentrate on removing bug like these, you know, that 80/20 rule! People > > needing the most complicated functions work in environments where the price > > of an office suite is 0.001% of their daily turnover, and nobody gives an > > (fill in your favourite expletive) about it! > > -> For my curiosity: is there also a rule where to start with 'bug like > these'. There are a quite a number of those, sadly, IMHO (not talking about > RTF specifically) So is there also a rule on how to set priority's. All > those bug more or less 'trivial' in some way. Don't think that RTF is the > most used format these day's (but of course depending on system; user case > etc). So rather hard to define what's important or not. Especially with a > suite with quite some functionality There is very obviously no hard and fast rule to classify "bug(s) like these", but what confidence does it instil in people if even a single one A4-sized document that only uses the most basic of RTF features cannot be rendered correctly in Writer. Hell, if it uses a font that's not on the system, why not open a pop-up that asks the user which font to substitute. I still use the Word XP freebie that came with my old AD 2003 PC, and I've set it up to show me a pop-up whenever I open something non-.DOC. How hard would it be to add a similar feature to Writer, when opening a non-.ODT format file, with a warning that it may not render correctly, just as there is one when saving in non-.ODT formats?
Still totally screwed up: 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
Created attachment 168481 [details] Spaces between spaces This is strange. There is another spaces between spaces. When toggle formating marks is on, it still don't see such spaces...
This is going nowhere. First, the cubiculum is downloadable. But by 5.50 €, so i gues noone will buy this. Second, when I change font to Consolas, which is in windows, problem stay same. But I have litle played with this and it start to be ok. So after change to consolas font, it seemed like no-monotype font, but after my work it was like monotype font. Maybe better question is, which way have you created the document. When I enabled showing the formatting marks like enters and spaces in LO, I see there some strange thing: spaces. Look to printscreen, it is in red circle. The space, made by spacebar is signed as dot. But between that dots is another space. I dont understand, what does it mean. Can you look at this? And additionally do trying everything with monotype font, what is defaultly in windows. For example the Consolas, but also Courier and many others. You can search the right font in notepad, for example. In version 3.3 it really works... And there is no the second spaces. Any one knows, what is it?
Also in 4.3 it is ok. Important is to switch the .rtf document to font "consolas". Version: 4.3.8.0.0+ Build ID: 2d13cf60ecdab83997c9cd7275c799ddd96617cd
(In reply to Martin Srdoš from comment #13) > This is going nowhere. > > First, the cubiculum is downloadable. But by 5.50 €, so i gues noone will > buy this. > > Second, when I change font to Consolas, which is in windows, problem stay > same. But I have litle played with this and it start to be ok. So after > change to consolas font, it seemed like no-monotype font, but after my work > it was like monotype font. > > Maybe better question is, which way have you created the document. When I > enabled showing the formatting marks like enters and spaces in LO, I see > there some strange thing: spaces. Look to printscreen, it is in red circle. > The space, made by spacebar is signed as dot. But between that dots is > another space. I dont understand, what does it mean. > > Can you look at this? And additionally do trying everything with monotype > font, what is defaultly in windows. For example the Consolas, but also > Courier and many others. You can search the right font in notepad, for > example. > > In version 3.3 it really works... And there is no the second spaces. Any one > knows, what is it? Cannot reproduce the image, Version: 7.0.4.2 (x64) Build ID: dcf040e67528d9187c66b2379df5ea4407429775 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 and layout (seems) to be even more screwed up (untested as I will not go through the hassle of installing old versions of LO on Windoze, screwing up my current version) Anyway, opening the file with a hex editor doe *not* show the offending ghost character.
Yes, there are spaces only in the new versions, namely since 6.4.0.0.alpha0+. Bisected: 7191de8f74030ec80a72d7e8b2960a4c029bf157 is the first bad commit commit 7191de8f74030ec80a72d7e8b2960a4c029bf157 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Sat Aug 24 02:46:58 2019 -0700 source 24b04db5a63b57a74e58a7616091437ad68548ac I am adding László Németh and Michael Stahl to CC list.
(In reply to Martin Srdoš from comment #14) > Also in 4.3 it is ok. Important is to switch the .rtf document to font > "consolas". > > Version: 4.3.8.0.0+ > Build ID: 2d13cf60ecdab83997c9cd7275c799ddd96617cd Using Version: 7.0.4.2 (x64) Build ID: dcf040e67528d9187c66b2379df5ea4407429775 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 I can switch to whatever fixed pitch font I want, and in Writer the results continue to be an utter mess. In Word the document displays completely correct with the same fixed-pitch fonts. When is LO finally going to support such utterly elementary documents?
See also bug 123703 suggests the \defchp formatting coming from RTF is interpreted. For formats missing the \defchp as the sample document here we need to add the 1\6th em U+2006 additional space on import. Apparently that is not the case with this "generated" RTF. If I delete all the extra \u2006 1/6th em spacing added by the RTF import filter (for see also bug 123703 [1]) the formatting with a mon0-sapce font substitution at 10pt (Courier New or Consolas) fits to the single page with formatting matching the PDF. So, is this NOTOURBUG? Or should we adjust ww8 filter to accommodate a non-compliant RTF generator? László? =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/77172/
s/a mon0-sapce font/a mono-space font
Version: 7.1.3.2 (x64) / LibreOffice Community Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1 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 Still a mess! OK(ish) in Consolas Utter rubbish in "Bitstream Vera Sans Mono" Utter rubbish in "Courier New" Utter rubbish in "DejaVu Sans Mono" Utter rubbish in "Lucida Console"
(In reply to Telesto from comment #5) > Found in > 3.5.7.2 > > but not in > LibreOffice 3.3.0 > OOO330m19 (Build:6) > tag libreoffice-3.3.0.4 I thought it is a regression in 3.5 because of this comment of Telesto, working in 3.3 but not in 3.5