BUG: Writer seems to ignore some "\par" in RTF file

users
#1

If you open the following, name it "whatever.rtf"

=== CUT ===
{\rtf1\ansi\deff0
{\fonttbl
{\f0\fmodern\fcharset0\fprq1 Courier New;}}
\paperw16840\paperh11907\margl709\margr709\margt1418\margb567
\lndscpsxn
\cols2\colsx709
\pard\plain
\sl-140\slmult0\fs14
{\b Rows\par}{
\par
+------+\par

Row |\par

+------+\par

   1 |\par
  60 |\par

+------+\par
\column
\par
\par
+------+\par

Row |\par

+------+\par

  61 |\par
120 |\par

+------+\par
\column
\par
\par
+------+\par

Row |\par

+------+\par

121 |\par

+------+\par

Tot |\par

+------+\par
}}
=== CUT ===

in Word, it will correctly put two blank lines above the second and third
column. Open it in Writer (4.0.1.2) and there will be only *one* blank line
above columns two and three.

Not good!

#2

Hi :slight_smile:
MS developed Rtf making all the promises about cross-platform and cross-product compatibility that are currently being made for their ISO format.  Unfortunately they never quite lived up to those promises and got taken to court about it and lost the case.  So they stopped developing it and created the OOXML and got that registered as an ISO standard instead.  Now people seem to be having similar problems with the new OOXML formats that they had with the Rtf, perhaps even more problems.

So, just avoid Rtf.  It always was a broken, proprietary format and even though MS have stopped doing any development of it there still hasn't been any improvement in it's compatibility. 
Regards from
Tom :slight_smile:

#3

Tom,

Maybe...

But RTF has one huge advantage, it's very easy to create on other
systems, as it is pure text. The "file" I posted is generate on IBM's
z/OS. Maybe you can tell me how I can generate an ODT file on that
platform?

Robert

#4

Hi :) 
The Odt format is a zip container that holds an Xml file(s).  So my guess is that if you can generate Xml in text-files then it should be reasonably easy.

But as you point out it does generate fairly different results on different machines using different OSes or / and different programs.  Then when generated you have no idea how it will display on other different machines, different OSes or in different programs.

You are free to post it as a bug-report but it's an inherent problem with the format itself and one that MS never fixed.  Remember that this mess of a format and the vast waste of effort endure by quite a lot of people and companies did land MS in court and MS lost the case.  Some companies seem to have been put out of business by it's failures to be more cross-compatible.  So, you are not alone. 
Regards from
Tom :slight_smile:

#5

Tom,

The Odt format is a zip container that holds an Xml file(s). So my guess is
that if you can generate Xml in text-files then it should be reasonably
easy.

You've got to be kidding...

Take this line from a file (in fixed pitch font):
=== SOURCE ===

  72 | 1386 | 43 | 26 | 112 | 14 | FL RG P CH D GB LV

NL B S |
=== SOURCE ===

In RTF it's simple:
=== RTF ===

  72 | 1386 | 43 | 26 | 112 | 14 | FL RG P CH D GB LV

NL B S |\par
=== RTF ===

And in ODT?

=== ODT ===
<text:p text:style-name="P1"><text:span text:style-name="T1">| <text:s
text:c="2"/>72 | 1386 | <text:s text:c="2"/>43 | <text:s
text:c="2"/>26 | <text:s/>112 | <text:s text:c="2"/>14 | FL
<text:s/>RG <text:s/>P <text:s text:c="2"/>CH <text:s/>D <text:s
text:c="2"/>GB <text:s/>LV <text:s/>NL <text:s/>B <text:s
text:c="2"/>S <text:s text:c="2"/>|</text:span></text:p>
=== ODT ===

Care to explain why Writer breaks up this line in umpteen parts, and
seems to do so on all places where there are two of more spaces? What
is wrong with spaces in XML? Why, so it seems to me, replace 2 spaces
with a *20* character substitute of "<text:s text:c="2"/>"?

Also, in this case the RTF file is just 325kb. The "content.xml" is 1,152kb.

Another RTF file is 2,887kb. For this one the "content.xml" is
"merely" 8,961kb, and even stranger: Open the RTF-saved-as-ODT, add
and insert and delete a single space at the very beginning, and save
again, and now "content.xml" is suddenly reduced to 7,056kb. Why
wasn't is saved like that right from the start?

RTF may have drawbacks, but for simple text it's vastly easier to
generate than the XML used in Writer. Add the fact that CPU time on
z/OS is rather more expensive than on Windoze boxes, and the case
against generating ODT files on z/OS is pretty strong... I'll probably
file the problem as a bug, but I won't hold my breath for the
solution.

Robert

#6

Hi :slight_smile:
If it's just text then why not use the txt format?

I'm not sure why your Odts are ending up so large.  Typically around 20-50Kb seems fairly normal for just a couple of pages.

I feel i should apologise that MS never made the Rtf format OpenSource rather than proprietary and hid the format's specs so that other programs couldn't use it until years after each new release of it and then withdrew development of it after they lost their court case but MS is a 3rd party organisation and we have no control over what they do. 
Regards from
Tom :slight_smile:

#7

Tom,

If it's just text then why not use the txt format?

Because it's text with limited bolding of some words.

I'm not sure why your Odts are ending up so large. Typically around 20-50Kb
seems fairly normal for just a couple of pages.

The ODT's are not that big, but on z/OS I would have to create them as
the constituent XML files and those are huge!

I feel i should apologise that MS never made the Rtf format OpenSource
rather than proprietary and hid the format's specs so that other programs
couldn't use it until years after each new release of it and then withdrew
development of it after they lost their court case but MS is a 3rd party
organisation and we have no control over what they do.

I don't think they're hidden any longer, and as for my problem, the
file I gave as an example is laughably simple, so don't blame M$ for
hidden specs. Writer should be able to import it correctly.

Robert

#8

Hi :slight_smile:
Then perhaps use html for the formatting?

Is the aim to create files that won't be able to be read in the future?  If so then keeping on with Rtf does make sense but if you do want them to be able to be read in the future then you need to change to a different format.

MS have taken the first steps to phasing it out.  They have stopped developing the format and blocked anyone else from developing it.  So, all known existing problems will remain and weakness found in the future will also remain.  The next sensible step is to make it readable but not writeable and then eventually phase out even the ability to read it. 
Regards from
Tom :slight_smile:

#9

Interesting discussion. For years, I have been an RTF fan for the very reasons mentioned by Robert. A small word processor I use a lot, called Atlantis, uses RTF as its native format. I also found that nearly every word processor on the planet is able to read RTF files.

But, as Robert found and Tom has explained, I found that every word processor reads those RTF files differently. It seems that there are so many different ways to format an RTF file that it's difficult to find consistency among the various programs.

So, as Tom points out, the format never became what it could have. It's a rotten shame.

In terms of file sizes, I think a lot depends on how much information the program inserts into the various files. I wrote a 44 page paper in LO. In ODT format, the file is 57 KB. When I imported the file into Atlantis and saved it in RTF format, it ballooned to 135 KB. Again, I think this is because of the different ways different programs deal with RTF.

At any rate, I've given up hoping that RTF would be a "universal" file format, simply because there are so many different "right" ways to interpret RTF files. As much as possible now, I just stick with ODT and, if I know I'll need to load it into a different program, I'll save a plain text copy. Yes, I lose all my formatting, but I've never found any clean transfer of *any* file format between different programs. Something, somewhere, is always messed up, so I find it best to start with plain text and go from there if I have to go from, say, LO to Word or WordPerfect, or back again.

Virgil

#10

Virgil,

Interesting discussion. For years, I have been an RTF fan for the very
reasons mentioned by Robert. A small word processor I use a lot, called
Atlantis, uses RTF as its native format. I also found that nearly every word
processor on the planet is able to read RTF files.

But, as Robert found and Tom has explained, I found that every word
processor reads those RTF files differently. It seems that there are so many
different ways to format an RTF file that it's difficult to find consistency
among the various programs.

So, as Tom points out, the format never became what it could have. It's a
rotten shame.

In terms of file sizes, I think a lot depends on how much information the
program inserts into the various files. I wrote a 44 page paper in LO. In
ODT format, the file is 57 KB. When I imported the file into Atlantis and
saved it in RTF format, it ballooned to 135 KB. Again, I think this is
because of the different ways different programs deal with RTF.

No, that's because ODT files are in essence ZIP files. The RTF files
we create on z/OS are specially crafted (someone had too much time on
his hands) to leave out everything and anything that isn't strictly
required.

Take the aforementioned 2,887kb RTF file created on z/OS:

If I save this in Word, (as RTF) without doing anything other than a
"Save As", it balloons up to an astonishing 13,286kb
If I save this in Writer, (as RFT) same scenario, 12,226kb
If I save the saved-in-Word RTF in Writer things get really bad: 16,887kb

And zipped, same order: 342kb, 612kb, 489kb & 554kb.

Save the z/OS RTF as ODT: 563kb, but this is in essence a ZIP file,
the constituent files have a total size of 9,007kb

At any rate, I've given up hoping that RTF would be a "universal" file
format, simply because there are so many different "right" ways to interpret
RTF files. As much as possible now, I just stick with ODT and, if I know
I'll need to load it into a different program, I'll save a plain text copy.
Yes, I lose all my formatting, but I've never found any clean transfer of
*any* file format between different programs. Something, somewhere, is
always messed up, so I find it best to start with plain text and go from
there if I have to go from, say, LO to Word or WordPerfect, or back again.

Going to plain text is not an option when your files are created on
another platform in huge volumes, which makes post-processing them
with any PC based word processor impossible.

Simple elementary RTF (paragraphs, columns, new pages,
bold/italic/underline) should be formatted the same by every word
processor. For goodness sake, what is so difficult about correctly
formatting two consecutive \par tags after a \column that Writer gets
is knickers in a twist?

Robert

#11

Hi :slight_smile:
Could the output be piped through something to convert to html?  Would it be difficult to construct?  Is anyone here able to do something simple or is it likely to be horribly complex?
Regards from
Tom :slight_smile:

#12

Hi :slight_smile:
Ok, i googled it and found a few interesting ideas for Rtf - Html.  There seems to be a few freeware tools but i tend to distrust freeware and then there were some guides on how to write your own and some with just coding in C# and stuff.  Oddly i didn't look through our own Extensions site but there is bound to be something there and if not then perhaps one of these links would be helpful getting something up there

http://stackoverflow.com/questions/439301/convert-rtf-to-html

http://blogs.msdn.com/b/matt/archive/2009/09/28/converting-rtf-to-html.aspx
http://code.msdn.microsoft.com/windowsdesktop/Converting-between-RTF-and-aaa02a6e
Regards from
Tom :slight_smile:

________________________________
From: Tom Davies <tomdavies04@yahoo.co.uk>
To: "robert@prino.org" <robert@prino.org>; Virgil Arrington <cuyfalls@hotmail.com>
Cc: "users@global.libreoffice.org" <users@global.libreoffice.org>
Sent: Friday, 15 March 2013, 13:49
Subject: Re: [libreoffice-users] BUG: Writer seems to ignore some "\par" inRTF file

Hi :slight_smile:
Could the output be piped through something to convert to html?  Would it be difficult to construct?  Is anyone here able to do something simple or is it likely to be horribly complex?
Regards from
Tom :slight_smile:

________________________________
From: Robert Prins <robert@prino.org>
To: Virgil Arrington <cuyfalls@hotmail.com>
Cc: Tom Davies <tomdavies04@yahoo.co.uk>; users@global.libreoffice.org
Sent: Friday, 15 March 2013, 13:15
Subject: Re: [libreoffice-users] BUG: Writer seems to ignore some "\par" inRTF file

Virgil,

Interesting discussion. For years, I have been an RTF fan for the very
reasons mentioned by Robert. A small word processor I use a lot, called
Atlantis, uses RTF as its native format. I also found that nearly every word
processor on the planet is able to read RTF files.

But, as Robert found and Tom has explained, I found that every word
processor reads those RTF files differently. It seems that

there are so many

different ways to format an RTF file that it's difficult to find consistency
among the various programs.

So, as Tom points out, the format never became what it could have. It's a
rotten shame.

In terms of file sizes, I think a lot depends on how much information the
program inserts into the various files. I wrote a 44 page paper in LO. In
ODT format, the file is 57 KB. When I imported the file into Atlantis and
saved it in RTF format, it ballooned to 135 KB. Again, I think this is
because of the different ways different programs deal with RTF.

No, that's because ODT files are in essence ZIP files. The RTF files
we create on z/OS are specially crafted (someone had too much time on
his hands) to leave out everything and anything that isn't strictly
required.

Take the aforementioned 2,887kb RTF file created on z/OS:

If I

save this in Word, (as RTF) without doing anything other than a

"Save As", it balloons up to an astonishing 13,286kb
If I save this in Writer, (as RFT) same scenario, 12,226kb
If I save the saved-in-Word RTF in Writer things get really bad: 16,887kb

And zipped, same order: 342kb, 612kb, 489kb & 554kb.

Save the z/OS RTF as ODT: 563kb, but this is in essence a ZIP file,
the constituent files have a total size of 9,007kb

At any rate, I've given up hoping that RTF would be a "universal" file
format, simply because there are so many different "right" ways to interpret
RTF files. As much as possible now, I just stick with ODT and, if I know
I'll need to load it into a different program, I'll save a plain text copy.
Yes, I lose all my formatting, but I've never found any clean transfer of
*any* file format between different programs. Something, somewhere, is
always messed

up, so I find it best to start with plain text and go from

there if I have to go from, say, LO to Word or WordPerfect, or back again.

Going to plain text is not an option when your files are created on
another platform in huge volumes, which makes post-processing them
with any PC based word processor impossible.

Simple elementary RTF (paragraphs, columns, new pages,
bold/italic/underline) should be formatted the same by every word
processor. For goodness sake, what is so difficult about correctly
formatting two consecutive \par tags after a \column that Writer gets
is knickers in a twist?

Robert
--
Robert AH Prins
robert(a)prino(d)org

Sent: Friday, March 15, 2013 6:49 AM
To: robert@prino.org
Cc: users@global.libreoffice.org

Subject: Re: [libreoffice-users] BUG: Writer seems to ignore some "\par"
inRTF file

Hi :slight_smile:
If it's just text then why not use the txt format?

I'm not sure why your Odts are ending up so large.  Typically around 20-50Kb
seems fairly normal for just a couple of pages.

I feel i should apologise that MS never made the Rtf format OpenSource
rather than proprietary and hid the format's specs so that other programs
couldn't use it until years after each new release of it and then withdrew
development of it after they lost their court case but MS is a 3rd party
organisation and we have no control over what they do.

________________________________
From: Robert Prins <robert@prino.org>
To: Tom Davies <tomdavies04@yahoo.co.uk>
Cc: "users@global.libreoffice.org" <users@global.libreoffice.org>
Sent: Friday, 15 March 2013, 10:31
Subject: Re: [libreoffice-users] BUG: Writer seems to ignore some "\par"
in RTF file

Tom,

The Odt format is a zip container that holds an Xml file(s).  So my

guess

is
that if you can generate Xml in text-files then it should be reasonably
easy.

You've got to be kidding...

Take this line from a file (in fixed pitch font):
=== SOURCE ===
>  72 | 1386 |  43 |  26 |  112 |  14 | FL  RG  P  CH  D  GB  LV
NL  B  S  |
=== SOURCE ===

In RTF it's simple:
=== RTF ===
>  72 | 1386 |  43 |  26 |  112 |  14 | FL  RG  P  CH  D  GB  LV
NL  B  S  |\par
=== RTF ===

And in ODT?

=== ODT ===
<text:p text:style-name="P1"><text:span text:style-name="T1">| <text:s

text:c="2"/>72 | 1386 | <text:s text:c="2"/>43 | <text:s

text:c="2"/>26 | <text:s/>112 | <text:s text:c="2"/>14 | FL
<text:s/>RG <text:s/>P <text:s text:c="2"/>CH <text:s/>D <text:s
text:c="2"/>GB <text:s/>LV <text:s/>NL <text:s/>B <text:s
text:c="2"/>S <text:s text:c="2"/>|</text:span></text:p>
=== ODT ===

Care to explain why Writer breaks up this line in umpteen parts, and
seems to do so on all places where there are two of more spaces? What
is wrong with spaces in XML? Why, so it seems to me, replace 2 spaces
with a *20* character substitute of "<text:s text:c="2"/>"?

Also, in this case the RTF file is just 325kb. The "content.xml" is
1,152kb.

Another RTF file is

2,887kb. For this one the "content.xml" is

"merely" 8,961kb, and even stranger: Open the RTF-saved-as-ODT, add
and insert and delete a single space at the very beginning, and save
again, and now "content.xml" is suddenly reduced to 7,056kb. Why
wasn't is saved like that right from the start?

RTF may have drawbacks, but for simple text it's vastly easier to
generate than the XML used in Writer. Add the fact that CPU time on
z/OS is rather more expensive than on Windoze boxes, and the case
against generating ODT files on z/OS is pretty strong... I'll probably
file the problem as a bug, but I won't hold my breath for the
solution.

Robert
--
Robert AH Prins
robert(a)prino(d)org

But as you point out it does generate fairly different results

on

different
machines using different OSes or / and different programs.  Then when
generated you have no idea how it will display on other different
machines,
different OSes or in different programs.

You are free to post it as a bug-report but it's an inherent problem with
the format itself and one that MS never fixed.  Remember that this mess
of a
format and the vast waste of effort endure by quite a lot of people and
companies did land MS in court and MS lost the case.  Some companies seem
to
have been put out of business by it's failures to be more
cross-compatible.
So, you are not alone.

________________________________
From: Robert Prins <robert@prino.org>
To: Tom Davies <tomdavies04@yahoo.co.uk>
Cc: "users@global.libreoffice.org" <users@global.libreoffice.org>
Sent: Friday, 15 March 2013, 7:04
Subject: Re: [libreoffice-users] BUG: Writer seems to ignore some "\par"
in
RTF file

Tom,

Maybe...

But RTF has one huge advantage, it's very easy to create on other
systems, as it is pure text. The "file" I posted is generate on

IBM's

z/OS. Maybe you can tell me how I can generate an ODT file on that
platform?

Robert
--
Robert AH Prins
robert(a)prino(d)org

Hi :slight_smile:
MS developed Rtf making all the promises about cross-platform and
cross-product compatibility that are currently being made for their ISO
format.  Unfortunately they never quite lived up to those promises and
got
taken to court about it and lost the case.  So they stopped developing
it
and created the OOXML and got that

registered as an ISO standard

instead.
Now people seem to be having similar problems with the new OOXML formats
that they had with the Rtf, perhaps even more problems.

So, just avoid Rtf.  It always was a broken, proprietary format and even
though MS have stopped doing any development of it there still hasn't
been
any improvement in it's compatibility.
________________________________
From: prino <robert@prino.org>
To: users@global.libreoffice.org
Sent: Thursday, 14 March 2013, 21:47
Subject: [libreoffice-users] BUG:

Writer seems to ignore some "\par" in

RTF
file

If you open the following, name it "whatever.rtf"

=== CUT ===
{\rtf1\ansi\deff0
{\fonttbl
{\f0\fmodern\fcharset0\fprq1 Courier New;}}
\paperw16840\paperh11907\margl709\margr709\margt1418\margb567
\lndscpsxn
\cols2\colsx709
\pard\plain
\sl-140\slmult0\fs14
{\b Rows\par}{
\par
+------+\par
> Row  |\par
+------+\par
>    1 |\par
>  60 |\par
+------+\par
\column
\par
\par

+------+\par

> Row  |\par
+------+\par
>  61 |\par
>  120 |\par
+------+\par
\column
\par
\par
+------+\par
> Row  |\par
+------+\par
>  121 |\par
+------+\par
> Tot  |\par
+------+\par
}}
=== CUT ===

in Word, it will correctly put two blank lines above the second and
third
column. Open it in Writer (4.0.1.2) and there will be only *one* blank
line
above columns two and three.

Not good!

--
For unsubscribe instructions

e-mail to: users+help@global.libreoffice.org

#13

You'd better avoid LibreOffice, then.

Brian Barker

#14

WebSphere Portal Enable 7 for z/OS
Enabling Document Conversion Services

Document Conversion Services are used when working with the Common Mail Portlet, WCM authoring and previewing, and search.

Document conversion is now supported on z/OS.

Perform the following configuration steps to ensure that document conversions will work for Microsoft Office, Lotus SmartSuite®, and OpenOffice file types:
http://infolib.lotus.com/resources/portal/7.0.0/doc/en_us/pt700abd003/html-wrapper.html

If you are using the this package in z/OS, you might be able to let it do the work for you. LibreOffice should open an OpenOffice document pretty cleanly.

Hope this helps

#15

Hi :slight_smile:
Free Software is very different from freeware.  Just because something happens to be free in price doesn't mean it is OpenSource, has a community or any of the other things we might expect from Free Software and that LibreOffice has an abundance of.

Regards from

Tom :slight_smile:

#16

Free Software is very different from freeware.

Ho, ho! This is rubbish, of course: freeware is free software. (I suspect you know that. I certainly hope you do. Try a good dictionary. Try a poor one, come to that.)

Just because something happens to be free in price doesn't mean it is OpenSource, has a community ...

As you could have read (and no doubt did), I made no mention of open source or communities or anything else - as neither did you. I simply quoted your own unqualified reference to "freeware". So this suggestion now is a straw man.

Everyone will have giggled at your original suggestion ("I tend to distrust freeware") in the context of the mailing list for a freeware product. Mine was just the obvious throw-away response. Remember the advice: when in a hole, stop digging!

Brian Barker

#17

Brian wrote,

Everyone will have giggled at your original suggestion ("I tend to

distrust freeware") in the context of the mailing list for a freeware
product.

I didn't giggle because I fully understood Tom's distinction between freeware and the open source LO.

LO is not a "freeware" product; it is open source. In common parlance (forgetting the dictionary), "freeware" is typically software that is published by one person or company in which all rights to the product are retained by the publisher. The software is given away for free solely by the grace of the publisher and there may be "strings" attached to its use. For example, "freeware" may have some functions disabled or may be limited to personal as opposed to commercial use.

By that description, which is widely understood, LO is *not* a "freeware product" as stated in your post. It is open source, which is not only free with respect to price, but also free as to use and license, and as Tom points out, is supported by a worldwide community. Freeware is often produced in a single hacker's garage, which might justify Tom's tendency to distrust it.

Virgil