Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


Hi :)
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 :)  





________________________________
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 :)
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 :)  






________________________________
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,

On 15 March 2013 12:46, Virgil Arrington <cuyfalls@hotmail.com> wrote:
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

-----Original Message----- From: Tom Davies
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 :)
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,

On 15 March 2013 09:09, Tom Davies <tomdavies04@yahoo.co.uk> wrote:

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


On 15 March 2013 00:11, Tom Davies <tomdavies04@yahoo.co.uk> wrote:

Hi :)
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
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted






-- 
For unsubscribe instructions e-mail to: users+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.