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:spencer.gra...@prodsyse.com] 
> Sent: Sunday, September 11, 2011 17:29
> To: dennis.hamil...@acm.org
> Cc: users@global.libreoffice.org
> 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:gl...@sbcglobal.net]
>> Sent: Sunday, September 11, 2011 15:09
>> To: users@global.libreoffice.org
>> 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: 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

Reply via email to