Tom,
On 15 March 2013 10:50, Tom [via Document Foundation Mail Archive]
<ml-node+s969070n4043988...@n3.nabble.com> wrote:
> 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
--
Robert AH Prins
robert(a)prino(d)org
>> From: Robert Prins <[hidden email]>
>>To: Tom Davies <[hidden email]>
>>Cc: "[hidden email]" <[hidden email]>
>>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 <[hidden email]> 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.
>>> Regards from
>>> Tom :)
>>>
>>>
>>> ________________________________
>>> From: Robert Prins <[hidden email]>
>>> To: Tom Davies <[hidden email]>
>>> Cc: "[hidden email]" <[hidden email]>
>>> 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 <[hidden email]> 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.
>>>> Regards from
>>>> Tom :)
>>>>
>>>>
>>>> ________________________________
>>>> From: prino <[hidden email]>
>>>> To: [hidden email]
>>>> 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!
--
View this message in context:
http://nabble.documentfoundation.org/BUG-Writer-seems-to-ignore-some-par-in-RTF-file-tp4043901p4043994.html
Sent from the Users mailing list archive at Nabble.com.
--
For unsubscribe instructions e-mail to: users+h...@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
