Much better - thanks. Any further responses will not be top posted.

Clients typically are set to view to screen width (yours does). However
as you can see, replying to such creates an issue; hence the issue of
what you see below. Unwrapped posts places the onus on person replying
to your posts to fix your 110 char format and rewrap to a common
72/80(max) character text format. I can do this in my client by Ctrl-R,
however I shouldn't have to. You can easily see the difference with your
current reply vs your other below.

So, let's go back to top posting; were you to receive /only/ this email,
would it make sense to you to read this first and then have to sort down
through the rest to understand what we are currently talking about? Try
it; print, set aside, and then start from the top.

I realise that you may have issue with your Outlook client, but even
with that it's not difficult to interleave/bottom post. Give it a try...
If it doesn't work out for you then fine, but then print a list post
that you last participated in, set aside for at least one day, read
later, and consider what you'd prefer afterwards.

And thanks for replying and trying, it's appreciated :-)


On 09/15/2011 07:02 PM, Dennis E. Hamilton wrote:
> Gary,
> 
> I see word-wrap just fine on the web page you linked to.  
> It appears that the list provided automatic word wrap. It
> won't reflow if I make the window narrower than where it
> did auto-breaking, so I couldn't read it comfortably with
> my phone's browser, unless the forced wrap is something
> like 30 characters (with landscape viewing).  But the auto-
> breaking is there, with a line width of around 110 
> characters, it seems. 
> 
> I also see word-wrap just fine in the e-mail you sent to me.
> So the answer is yes, I would see it all just fine.
> 
> The conflict is with clients that do know to word-wrap the text,
> which is kept in paragraph-level streams so the client can do
> correct word-wrap with whatever the displayed line size is.
> 
> I know some list archives *prevent* work-wrapping by using
> <pre> instead of <p> elements when plaintext is presented
> via HTML.  The GMANE page you linked to uses <pre> but then
> does automatic word wrap to keep line width at around 110
> characters.  Works fine on my monitor [;<).
> 
> When email is word-wrapped with hard line breaks, it is 
> then ugly in situations when the client also does automatic 
> word-wrapping.  And when there are ">" reply-nesting markers, 
> it gets worse.
> 
> Catch-22.
> 
> So if I sent HTML-formatted mail, would that actually work
> better for you?
> 
>  - Dennis
> 
> PS: This message manually word-wrapped for your pleasure.
> 
> PPS: There is an SMTP IETF RFC that explains how to auto-
> matically handle word-wrapping and tell when not to word-
> wrap a line.  It appears that knowledge of that is not
> uniformly distributed.  I think the architectural principle
> is that the recipient would know what its wrapping needs
> are and the sender has no way to know what works, hence
> no pre-wrapping inside paragraph text.
> 
> -----Original Message-----
> From: NoOp [mailto:[email protected]] 
> Sent: Thursday, September 15, 2011 16:44
> To: [email protected]
> Subject: [libreoffice-users] Re: Rountrip Conversion Problems (was Re: Should 
> LibreOffice ... secret formats?)
> 
> I'm going to top post on purpose this time (shock & awe)...
> 
> Dennis, sorry but I've a hard time following your posts. You top post
> without any word wrap & here is how your post appears in my standard
> email client.
> 
> I well appreciate your participation on this list, however you've
> already read, and commented[1], on "Top Posting... Can we have an LO
> Mailing List Guidelines Page?" thread. How does top posting and lack of
> word wrap make the following readable at all?
> 
> Re: word wrap:
> <http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.user/10816>
> Is it that difficult?
> 
> Were you to initially receive the following in your email client
> (X-Mailer: Microsoft Outlook 14.0) would you be able to follow and
> understand just what the heck you are talking about?
> 
> I think your contributions to this list are sincere, well thought out,
> and valuable. /Please/ reconsider your top posting and lack of word wrap
> in future responses.
> 
> Gary
> 
> [1]
> <http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.user/10798>
> 
> On 09/11/2011 06:31 PM, Dennis E. Hamilton wrote:
>> It is tough to figure out what bug to report in the multi-column text-flow 
>> problem.
>> 
>> In the dashed line problem, it is easy to report two bugs, one for dashed 
>> lines to .doc and one for dashed lines from .doc.  
>> 
>> In this multi-column flow case, LibreOffice can round trip, and the bug is 
>> in the change to column and spacing widths that have the material not fit 
>> and not flow properly.
>> 
>> So there is a bug around not being able to consume what it produces properly.
>> 
>> THE SERIOUS INTEROP QUESTION
>> 
>> The other problem, that I don't know how to deal with, is whether that is a 
>> proper .doc for what is in the .odt at all.  I *think* the problem you are 
>> seeing is that the frame on one of the images in column 2 is actually too 
>> wide.  Or maybe column 1, and it forced the kind of adjustment you are 
>> seeing.  But the consequences in Word are particularly awful.
>> 
>> What is even more amazing is that what Word does with that specific .doc has 
>> not changed since Office 97!!  NoOp gets near-identical results from the 
>> .doc in Word 97 that I get from it in Word 2010.  I bet if the second page 
>> is examined, the column 2 content will be seen to have flown down to the 
>> second column there.  (The only difference that I see in Word 2010 compared 
>> with the Word 97 screen shot is that 2010 has a double title over the graph 
>> in column 3 and consequently more text flows to the top of column 4.  I 
>> hadn't noticed that additional title doubling in my earlier report.)
>> 
>> On the other hand, what Word 2010 does with the original ODT is strangely 
>> close to what it does with the .DOC, and that is *really* inexplicable.
>> 
>> So there's not enough here for an isolated bug.
>> 
>> MORE DETAIL: I forgot to check this before.  When the .doc is opened in Word 
>> 2010, the columns are set as four across, with column 1 1.6", 2-3 at 1.25" 
>> apiece, and column 4 at 1.6".  The spacing is 0.7".  The equal column width 
>> box is not checked.  The margins are 0.35" top, left, right, and bottom, 
>> with no gutter.  The page is US Letter.
>> 
>> If I check "equal column width" I get 1.43" columns all the way across and 
>> 0.7" spacing. The duplicated titles I mention disappear, but there are other 
>> duplications in the columns.
>> 
>> (sigh)
>> 
>> FURTHER ANALYSIS POSSIBILITIES
>> 
>> Although it introduces more variables that can't be controlled, I think 
>> there are three avenues of further exploration:
>> 
>>  1. Make a .doc that seems as correct as is possible.  See what LibreOffice 
>> does with that.  Then make an .odt from that .doc from Office 2010 to see 
>> how that round-tripping works.  This might localize *something*.
>> 
>>  2. Do the same thing with .docx in both directions.  If experience is any 
>> guide, this will be worse, but because .docx is an XML format it might be 
>> possible to find more clues by inspecting the XML that travels in various 
>> directions.
>> 
>>  3. Make a Microsoft Word XML file too.  This is a rarely-used variation 
>> that *might* provide more clues.  There are filters for reading those into 
>> LibreOffice also, although I have no clue concerning their quality.  (This 
>> can be round-tripped out of LibreOffice too, I believe.)
>> 
>> There is a project, Apache Poi, that has Java tools for manipulating and 
>> converting Microsoft Office format documents.  That might help to examine 
>> the .doc files to see where the discrepancies arise.  That's a lot of work 
>> to invest for this particular file.  I think starting with variations of 
>> simple cases may work better.
>> 
>> 
>> 
>> -----Original Message-----
>> From: Spencer Graves [mailto:[email protected]] 
>> Sent: Sunday, September 11, 2011 17:29
>> To: [email protected]
>> Cc: [email protected]
>> Subject: Re: [libreoffice-users] Rountrip Conversion Problems (was Re: 
>> Should LibreOffice ... secret formats?)
>> 
>> Hi, Dennis:
>> 
>> 
>>        Thanks very much.  Should I do something to file bug reports on 
>> these items?
>> 
>> 
>>        Spencer
>> 
>> 
>> On 9/11/2011 5:08 PM, Dennis E. Hamilton wrote:
>>> I repeated test similar to those NoOp also performed to see how the 
>>> variations that I made with the dashed-line slide image show up here.
>>>
>>> CONCLUSION
>>>
>>> The round trip from Document A to B back to C is definitely broken in Libre 
>>> Office in the manner described by Spencer.
>>>
>>> The opening of either Document A or Document B in Word 2010 produces a 
>>> terrible result where the 4 columns are longer and flow at their bottoms 
>>> onto a second page.
>>>
>>> This is so bad I despair of doing any further isolation.
>>>
>>>   - Dennis
>>>
>>> ANALYSIS DETAILS
>>>
>>> A. Document A - The ODT from Spencer. In LO 3.3.2 I see 4 columns, each 
>>> 1.5" wide, with about 0.5" between.  The Format | Columns dialog reports 
>>> 1.42" with 0.70" spacing and AutoWidth is selected.
>>>
>>> B. Document B - The Word 27-2000 format DOC from Document A via Libre 
>>> Office, by Spencer
>>>
>>> C. Document C - The ODT file that reflects what is seen when Document B is 
>>> opened in Libre Office.
>>>
>>> When I open Document A in Word 2010, I see the problem that NoOp reported, 
>>> concerning a blank column showing up.  There is also an error message about 
>>> "Drawn Objects and Text Boxes 1."  I also see that there is a second page 
>>> having 4 more columns (the 4th column is empty).  It appears that the 
>>> columns stretch vertically down onto the second page.  That is, there are 
>>> only 4 columns but each column is two pages long, and the top of the second 
>>> column is all blank, so its content only appears on the second page.  There 
>>> are also columns whose content image flows off the bottom of the page and 
>>> is chopped off.
>>>
>>> When I open Document B in Word 2010, What I see is almost the same as when 
>>> opening Document A in Word, but the B view has a duplicate title over one 
>>> of the figures of the Financial Industry Profits graph in column 2.
>>>
>>> Document C in LibreOffice is now 2 pages because the column sizes are 
>>> screwed up, leading to 4 columns on the first page and a fifth column on 
>>> the second page.
>>>
>>> There's no point in making a Document X because I have no means to obtain a 
>>> correct version in Word to try saving back.
>>>
>>> -----Original Message-----
>>> From: NoOp [mailto:[email protected]]
>>> Sent: Sunday, September 11, 2011 15:09
>>> To: [email protected]
>>> Subject: [libreoffice-users] Re: Should LibreOffice even support Microsoft 
>>> secret formats?
>>>
>>> On 09/11/2011 11:06 AM, Spencer Graves wrote:
>>>> Another example:
>>>>
>>>>
>>>> 1.  Download
>>>> "http://www.cagreens.org/sclara/resources/flyers/noCreditCd-bookmark20110306.odt";.
>>>>
>>>>
>>>>
>>>>
>>>> 2.  Open in LibreOffice 3.4.3.  Save as MS Word 97 *.doc format.
>>>>
>>>>
>>>> 3.  Close, then reopen the *.doc version:  When I did this now under
>>>>   Windows 7, this changed the widths of the columns had changed and
>>>> with it the column breaks, etc.  I checked Format ->  Page ->  Columns:
>>>> *.odt showed from Autowidth with columns = 1.42, space = 0.70;  *.doc
>>>> had columns = 2.13, space = 0.70.  The numbers do not make sense to
>>>> me, but the visual change is clear.  I noticed this problem with an
>>>> earlier version of LibreOffice 3.4 and I think also with Open Office
>>>> 3.3.
>>> ...
>>>
>>> I tested as per the above, and indeed LO does save the .doc with
>>> modified column widths. I tested by saveas in LO 3.3.3 and then opened
>>> the .doc with:
>>>
>>> LO 3.3.3 (linux)
>>> LO 3.4.3 (linux)
>>> OOo 3.2.1 (go-oo build - Ubuntu linux)
>>> OOo 3.2.0 (Windows)
>>> MSO Word97 (yes I have MSO97 on an VirtuaBox Win2K install)
>>>
>>> The worst/more serious issue is that in MSO Word97 blank second column
>>> is inserted/shown. This means that the document renders only 3 populated
>>> columns rather than 4. Screenshot is here:
>>>
>>> http://imageshack.us/f/841/screenshotwin2kprorunni.png/
>>>
>>> So, you've a valid bug to report. Check to see if one hasn't already
>>> been filed before filing yours. Start a new thread regarding the problem
>>> when you've done that and I'll be glad to contribute/add to the bug
>>> report with my tests/screenshots.
>>>
>> 
>> 
> 
> 
> 



-- 
For unsubscribe instructions e-mail to: [email protected]
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

Reply via email to