OASIS Open Document Format for Office Applications (OpenDocument) TC

 View Only
  • 1.  Re: [office] Question regarding user expectance.

    Posted 03-23-2007 15:41
    Hi David,
    
    sure. But bottom line this is what we "fighting" about.
    
    We could
    a) define numbered-paragraphs as KOffice does it and then let the WW import filter deal with the problem
    or
    b) define numbered-paragraphs as WW does it then KOffice import filter deal with the problem.
    
    However neither a) or b) really deals with interop.
    
    Right?
    
    ~Florian
    
    
    >>> David Faure 


  • 2.  Re: [office] Question regarding user expectance.

    Posted 03-23-2007 16:47
    On Friday 23 March 2007, Florian Reuter wrote:
    > Hi David,
    > 
    > sure. But bottom line this is what we "fighting" about.
    > 
    > We could
    > a) define numbered-paragraphs as KOffice does it and then let the WW import filter deal with the problem
    > or
    > b) define numbered-paragraphs as WW does it then KOffice import filter deal with the problem.
    > 
    > However neither a) or b) really deals with interop.
    
    Call me a idealist, but in my opinion, we should do
    c) define numbered-paragraphs in a way that "makes sense", i.e. is flexible enough for the various
    requirements of office suites, and is understandable (sufficiently documented), and is implementable,
    and then model KOffice2 around it and let the WW import filters take care of the conversion with WW.
    
    -- 
    David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
    Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
    


  • 3.  Re: [office] Question regarding user expectance.

    Posted 03-24-2007 00:25
    When Corel developed round-tripping capability in conversions between
    Word and WordPerfect 9, advanced users were unanimous on the various
    WordPerfect discussion lists that they much preferred an easily
    editable document than a document that was identical in presentation.
    
    The problems were acute with the new WordPerfect conversion filters.
    Because of basic architectural differences between Word and
    WordPerfect, DOC files converted to WPD were full of what was from
    WordPerfect users' viewpoint a mass of cruft. Presentation is
    virtually identical, but the converted DOC files are for all practical
    purposes non-editable because of the cruft. A single edit and users
    were put into a formatting nightmare. Because of this issue, I could
    point you to a half dozen downloadable scripts for stripping the Word
    cruft from converted DOC files so users can edit documents before the
    trip back to DOC.
    
    Corel's failure to come up with easily editable converted documents
    marked a mass exodus of enterprise users, particularly in large law
    firms, who had agreed to stick with WordPerfect for one more version
    to see what Corel could do to improve conversion.
    
    I realize that we are here discussing ODF <> ODF rather than DOC <>
    WPD. But I would urge that at the very least users be offered a choice
    between identical presentation and the implementing apps' normal
    processing of text. For example, forcing identical line breaks despite
    font changes or differences in font rendering can result in compressed
    and reduced point-size type. Particularly the latter is a show stopper
    for law offices, as rules of court commonly specify point sizes for
    text.
    
    The critical point comes when a legal brief precisely equals the
    maximum number of pages allowed by court rules. (Very common for
    offices to assiduously edit documents to barely get them down to the
    page limits.) If a document would exceed the allowable page count but
    for a violation of the point size rule, then the brief is subject to
    being stricken from the record and the firm is subject to sanctions by
    the court. Not a small matter, as having a brief stricken from the
    record can result in a malpractice claim against a firm by the client.
    And courts in the U.S. tend to be fastidious about their page limit
    and type size rules.
    
    As a general matter, I'd say that when identical presentation is
    required, formats like PDF with embedded fonts are the right solution.
    I'll also point out that Microsoft has never been able to pull off
    identical presentation even with its own apps. A difference in printer
    driver, a change in Word version, a change in printer metrics
    settings, font availability, all combine to make the identical
    presentation "use case" far more an unfulfilled goal than a reality in
    office productivity software. I'd rather see implementing developers
    rejecting the Microsoft definition of interoperability in favor of
    something more practical.
    
    Best regards,
    
    Marbux
    


  • 4.  Re: [office] Question regarding user expectance.

    Posted 03-26-2007 09:39
    On Saturday 24 March 2007, marbux wrote:
    > As a general matter, I'd say that when identical presentation is
    > required, formats like PDF with embedded fonts are the right solution.
    
    I completely agree. However I was referring to the number in front of paragraphs,
    not to the text layout and fonts etc.
    Don't you agree that opening a given ODF document in any office suite should show
    the same text _and_ the same numbers in front of paragraphs? In my opinion this
    isn't part of "presentation", it's really part of the contents [technically it isn't, but
    to the user it is].
    
    -- 
    David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
    Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
    


  • 5.  Re: [office] Question regarding user expectance.

    Posted 03-26-2007 17:42
    On 3/26/07, David Faure 


  • 6.  Re: [office] Question regarding user expectance.

    Posted 03-26-2007 21:31
    On Monday 26 March 2007 19:41, marbux wrote:
    > I agree. But as I understand it, it's a bit more complicated when it
    > comes to compatibility with ODF 1.0 and 1.1 documents because of the
    > differences in implementation Florian has pointed to. I agree with his
    > point that at the very least the numeration should be preserved, even
    > if there's no work-around for the form of numbers switching, e.g.,
    > from 4 to IV.
    
    Hi Marbux,
    
    backwards compatibility  to ODF1.0 and 1.1 is a funny thing for lists.
    The thing is; lists in older ODF versions are not very well specified; so 
    there is no real thing to be backwards compatible with.  Its like saying the 
    new railroads have to be able to let old trains run on them. Even if those 
    old trains have different distances between their wheels because that was 
    never made standard before.
    
    The solution there is to not be hand waving but be specific and say trains 
    from model X and models Y will run on it as well as all trains which conform 
    to the new wheel-base size.  You can look at those older models X and Y and 
    make sure they run.
    
    There are two major ODF-writing applications. And those applications have sent 
    representatives for writing(/clarifying) the specs in ODF1.2. You can be sure 
    that the old documents written by them will actually work in ODF1.2 without 
    such problems as missing numbering. I know it will work without problems for 
    KWord at least.
    
    So, Florian has been trying to throw sand in peoples eyes; he states that _if_ 
    there was another implementation of ODF1.0 that behaved differently from the 
    big two, we'd get into trouble.
    Which is much like saying that if there was a midget train our new railroad 
    tracks would not be able to handle them.
    Which is true, but not something we can fix in a consistent manner. I'd 
    personally go as far as stating that this hypothesis is irrelevant.
    -- 
    Thomas Zander