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