Re: [tdf-discuss] ignore m$ legacy?
On 22 July 2011 02:06, Andrew Douglas Pitonyak and...@pitonyak.org wrote: On 07/21/2011 09:43 AM, Gordon Burgess-Parker wrote: On 21/07/2011 14:23, Andrew Douglas Pitonyak wrote: I am of the opinion that good inter-operability with MSO products makes it easier to attract new users and that poor inter-operability with MSO products makes it more difficult. I quite agree. As (I would say) between 90 and 95% of the business world uses MSO, there's no incentive to change from MSO if the alternatives aren't 100% compatible in terms of formatting, other than cost of upgrading and the activities of the BSA and its' companions. My wife sends me documents written in Office 2003 which sometimes are so badly mangled when I open them in OO or LO that I have to open them in MSO to see what they should look like. And these are in general not complicated documentsHaving said that, then there have also been instances of formatting incompatibilities between different versions of MSO Much depends on the formatting that is used. Simple documents usually have no difficulties. Realize that in OOo I can represent things that I cannot represent in MSO and the opposite holds as well. Images anchored to paragraphs are particular troublesome. Open Source Consortium is currently trying to get a UK government policy to use simple document layouts for interoperability where ever possible. Discourage unnecessary decoration, complex tables etc. IMHO it would improve their documents in any case an lower the production costs so better for the tax payer. -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/**AndrewMacro.odthttp://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php -- Unsubscribe instructions: E-mail to discuss+help@**documentfoundation.orgdiscuss%2bh...@documentfoundation.org Problems? http://www.libreoffice.org/**get-help/mailing-lists/how-to-** unsubscribe/http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.**documentfoundation.org/** Netiquette http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.**documentfoundation.org/www/**discuss/http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted -- Ian Ofqual Accredited IT Qualifications (The Schools ITQ) www.theINGOTs.org +44 (0)1827 305940 The Learning Machine Limited, Reg Office, 36 Ashby Road, Tamworth, Staffordshire, B79 8AQ. Reg No: 05560797, Registered in England and Wales. -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.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.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] ignore m$ legacy?
On 22/07/2011 02:06, Andrew Douglas Pitonyak wrote: On 07/21/2011 09:43 AM, Gordon Burgess-Parker wrote: On 21/07/2011 14:23, Andrew Douglas Pitonyak wrote: I am of the opinion that good inter-operability with MSO products makes it easier to attract new users and that poor inter-operability with MSO products makes it more difficult. I quite agree. As (I would say) between 90 and 95% of the business world uses MSO, there's no incentive to change from MSO if the alternatives aren't 100% compatible in terms of formatting, other than cost of upgrading and the activities of the BSA and its' companions. My wife sends me documents written in Office 2003 which sometimes are so badly mangled when I open them in OO or LO that I have to open them in MSO to see what they should look like. And these are in general not complicated documentsHaving said that, then there have also been instances of formatting incompatibilities between different versions of MSO Much depends on the formatting that is used. Simple documents usually have no difficulties. Realize that in OOo I can represent things that I cannot represent in MSO and the opposite holds as well. Images anchored to paragraphs are particular troublesome. What is far more disturbing, is that MS has replaced free OEM copies of Works with a free (albeit with advertising) version of Office 2010 that just contains limited functionality versions of Word and Excel - thus attempting to perpetuate the stranglehold of proprietary document formats. -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.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.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] disclaimer for extension website
While that is certainly advisable, I think we need some good CYA. Some people in this sad sad world just like to sue. Marc-André Laverdière Software Security Scientist Innovation Labs, Tata Consultancy Services Hyderabad, India On 07/21/2011 11:57 PM, Dennis E. Hamilton wrote: I think the DMCA guff is avoidable as long as your extension site is not in the United States. Mirrors will have to be careful too, though. - Dennis -Original Message- From: Florian Effenberger [mailto:flo...@documentfoundation.org] Sent: Thursday, July 21, 2011 01:32 To: discuss@documentfoundation.org Subject: [tdf-discuss] disclaimer for extension website Hello, I'd like to quote my colleague Thorsten Behrens on this: == [ ... ] That whole DMCA guff they have there further down is prolly unnecessary, we can simply link to our imprint, so people know whom to contact. == Any feedback welcome, as we want to launch the extensions website soon. :) Florian -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.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.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
[tdf-discuss] Re: disclaimer for extension website
Le 2011-07-21 04:32, Florian Effenberger a écrit : Hello, I'd like to quote my colleague Thorsten Behrens on this: == With the upcoming extension website, we'll need some kind of click-through license agreement, for someone submitting software, and a disclaimer on the front page, refusing liability on third-party-provided software that we host. What makes this really easier is that we'll for the while only host opensource extensions, so at least in theory, one can properly review the source code for any nasties. Looked a bit into the boilerplate the Mozilla foundation came up with, for that - https://addons.mozilla.org/en-US/firefox/about https://addons.mozilla.org/en-US/developers/docs/policies/reviews https://addons.mozilla.org/en-US/developers/docs/policies/submission http://www.mozilla.com/en-US/about/legal.html are the relevant pages I guess. The meat of that is: Legal Disclaimers and Limitations Responsibility of Contributors. Those who post material to, provide links to material from, or otherwise make material available by means of Mozilla’s websites (“Contributors”) are entirely responsible for the content of, and any harm resulting from, that material. By acting as a Contributor, you represent and warrant that: * the downloading, copying and use of the materials you make available will not infringe the proprietary rights, including but not limited to intellectual property rights, of any third party; * you have fully complied with any third-party licenses relating to such materials, and have done all things necessary to successfully pass through to end users any required terms; * the materials you make available do not contain any viruses, worms, Trojan horses or other harmful or destructive content; * the materials you make available are not obscene or libelous, and do not violate the right of privacy or publicity of any third party; and * you have, in the case of computer code, accurately categorized and described the type and nature of the materials if and when requested by Mozilla to do so. Without limiting any of those representations or warranties, Mozilla has the right (though not the obligation) to, in Mozilla’s sole discretion: (a) remove any content that, in Mozilla’s reasonable opinion, violates any Mozilla policy or is in any way harmful or objectionable; or (b) require changes in any license agreement relating to any materials made available by any Contributor. Responsibility of Website Users. Mozilla has not reviewed, and cannot review, all of the material, including computer software, available on or by means of Mozilla’s websites, and cannot therefore be responsible for that material’s content, use or effects. By operating its websites, Mozilla does not represent or imply that it endorses the material there available, or that it believes such material to be accurate, useful or nonharmful. You are responsible for taking precautions as necessary to protect yourself and your computer systems from viruses, worms, Trojan horses and other harmful or destructive content. Mozilla's websites may contain content that is offensive, indecent or otherwise objectionable, as well as content containing technical inaccuracies, typographical mistakes and other errors. Mozilla’s websites may also contain material that violates the privacy or publicity rights, or infringes the proprietary rights, of third parties, or the downloading, copying or use of which is subject to additional terms and conditions, stated or unstated. Mozilla disclaims any responsibility for any harm resulting from the use by Mozilla's visitors of Mozilla’s websites, or from any downloading by those visitors of content available on or by means of Mozilla’s websites. I would also add the 3rd point on the Mozilla legal page[1] as an important point. 3. Changes. Content contained on Mozilla’s websites, including these Legal Disclaimers and Limitations, may be changed at the sole discretion of Mozilla and without notice. You are bound by any such updates or changes, and so should periodically review these Legal Disclaimers and Limitations. That whole DMCA guff they have there further down is prolly unnecessary, we can simply link to our imprint, so people know whom to contact. Do you mean to say that if there are any DMCA issues that the people will contact someone on the Impressum page? For those who do not live in the US, it is easy to discount the impact of the DMCA. However, Americans do need to keep an eye on any content contravening the DMCA, claiming ignorance is not an excuse.So any material helping LibreOffice manage DMCA legal matters should still be considered, as we are trying to break into the US office productivity market. (Disclaimer: I live in Canada.) == Any feedback welcome, as we want to launch the extensions website soon. :) Florian Otherwise, yes, the Mozilla Legal Disclaimers and Limitations pages seem OK to me. I guess the an added bonus to this discussion
Re: [tdf-discuss] ignore m$ legacy?
On 21/07/2011, Andrew Douglas Pitonyak and...@pitonyak.org wrote: On 07/21/2011 08:47 AM, e-letter wrote: On 21/07/2011, Andrew Douglas Pitonyakand...@pitonyak.org wrote I am more comfortable in OOo than I am in MSO, so, I have created many MSO deliverables in OOo and LO. The only time that I make an exception is when I believe that I am not able to seamlessly move between formats because of incompatibilities. So, if I intend to create a large document with multiple images, links, and fields, I begin and end with MSO. That is your prerogative, but it is preferable to see writer used to create such large documents in the native odt format, at least to demonstrate the power of LO. The problem is that the final deliverable to the client is an MSO document and the complicated structures that I frequently use do not properly export to the MSO document format. It is very time consuming to work through a 250 page document full of cross-references and text frames that do NOT export to the format required by the client. I lost many hours fixing up the document in MSO so that it would be ready for final delivery. In my opinion interoperability with the _m$ format_ weakens increased adoption of the odf. At the start of a 250 page document, ideally the decision should be made to use odt and the issue become ensuring that LO behaviour in native odt format occurs with minimal bugs. This experience alone should promote wider adoption of LO. The claim to offer (or attain to) perfect interoperability with the _m$ format_ leads to time wasted trying to get LO to work with m$. If the end requirement is m$, pay to use m$. Suppose a user wrote to a m$ forum to complain that m$word cannot create a good document in odt format. A likely response would be to go and use LO (or another odf compliant program)! MSO is able to create a nice document. Certainly there are constructs that I use in my ODT files that are not easily supported in MSO (say items related to page styles), but things that are supported by both do not always carry over. Fine. People are/should be free to choose whichever program they prefer. If someone likes the interface of m$o, good for them. The point of the original post, is that priority should be for LO performance in native odf to be better than m$o performance in native m$ format (or indeed secondary odf). It does not seem right that people complain that writer does not save to m$ format well, when the statement writer creates beautiful, easily-created odf documents should be the main reason to use LO. -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.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.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] ignore m$ legacy?
On 21/07/2011, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Yes, don't confuse ODF compatibility with OpenOffice.org (or LibreOffice) compatibility. I was in the room on one occasion when Microsoft was asking for advice on their approach to ODF 1.1 Spreadsheet documents. Unfortunately, none of us blinked about how this would work for users who are unaware that ODF 1.1 has no standard for calculation formulas but think that OpenOffice.org Calc is the standard. I don't believe that ODF support was broken. The ODF support in Office 2007 is the first time that integrated ODF support appeared in Microsoft Office. I know there are bugs, some of them rather surprising/disappointing. Or deliberate..? - Dennis (ODF 1.2 is a different story but I don't know the current status of OpenFormula in LibreOffice and I have not seen anything on Microsoft plans in this area. I have seen a statement that Microsoft wants to present its ODF plans for the next release of Office at an April 2012 Plugfest in Brussels.) Thanks for your mention of open formula; a quick search revealed new knowledge as I wasn't aware such an initiative was in place. Is it viable to develop some sort of open macro language also? Personally don't use them presumably such an interoperability feature would be beneficial. The issue of formula loss in spreadsheets is interesting. If a spreadsheet is started in calc then the recipient must use calc also. If someone develops a tool in calc, then the recipient has no alternative but to install LO (or odf compliant alternative). -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.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.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] ignore m$ legacy?
On 22/07/2011 15:24, e-letter wrote: Fine. People are/should be free to choose whichever program they prefer. If someone likes the interface of m$o, good for them. The point of the original post, is that priority should be for LO performance in native odf to be better than m$o performance in native m$ format (or indeed secondary odf). It does not seem right that people complain that writer does not save to m$ format well, when the statement writer creates beautiful, easily-created odf documents should be the main reason to use LO. True to a certain point. But you can't ignore the fact that 90-95% of Office suite users USE MS! They aren't going to be persuaded to migrate to LO or even OO if when they are sent documents created by MSO, they don't render properly in LO. The ability for LO to create fine ODF documents far better then MS creates Office documents will only be a major factor in the uptake of LO when the number of users of LO is approaching that of those who use MSO - ie as the split tends towards a much higher proportion of LO users. Rather a catch 22 situation wouldn't you say? -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.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.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] ignore m$ legacy?
At 02:33 21-7-2011, Andrew Douglas Pitonyak wrote: On 07/20/2011 05:02 PM, e-letter wrote: On the users mailing list, a significant proportion of a random view of questions seems to be with relation to using LO is some way with m$ document formats. (...) I might also conclude that there is NO reason to support any other file format either. I mean, really, why should I support a non-ODF format? PDF generation? Remove it! (...) Please don't remove PDF generation. That would be the end of the only free and open-source PDF generator that produces tagged PDF, which is a requirement for accessibility. Best regards, Christophe -- Christophe Strobbe K.U.Leuven - Dept. of Electrical Engineering - SCD Research Group on Document Architectures Kasteelpark Arenberg 10 bus 2442 B-3001 Leuven-Heverlee BELGIUM tel: +32 16 32 85 51 http://www.docarch.be/ Twitter: @RabelaisA11y --- Open source for accessibility: results from the AEGIS project www.aegis-project.eu --- Please don't invite me to Facebook, Quechup or other social networks. You may have agreed to their privacy policy, but I haven't. -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.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.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Microsoft ODF 1.1 Support (was RE: [tdf-discuss] ignore m$ legacy?)
I don't find it credible that Microsoft would intentionally deviate in ways to break a format, considering the level of scrutiny they receive from regulatory authorities and everyone else. I find it more creditable that they didn't do a terrific job in their first effort and it might not have been something the developers were keen about. But I have no way of knowing nor of knowing the difficulties there are for mapping in and out of their own internal processing model. They obviously can't support a feature that the native application can't support (as is the case for LibreOffice as well, of course). In any case, Microsoft produced public implementation notes about their support for ODF 1.1 in Office 2007 (it was SP2, not the SP1 I mentioned in another message). There are also implementation notes for Office 2010 support of ODF (and OOXML, etc.). My old links to the Implementation Notes failed me yesterday, but I've now learned that they've moved! (Deep linking into microsoft.com, even searching into microsoft.com, is one of my more frustrating experiences.) Here is relevant information for those interested in the details: http://blogs.msdn.com/b/dmahugh/archive/2008/12/16/odf-implementation-notes-for-office-2007-sp2.aspx is a December 2008 blog post about the original implementation notes and their purpose. (There are similar notes for OOXML.) http://blogs.msdn.com/b/dmahugh/archive/2011/07/13/new-dii-website-locations.aspx explains the change in location and format. The actual notes are here: http://msdn.microsoft.com/en-us/library/ee908651.aspx You can get a PDF or you can get a Zip that has *all* of the Microsoft Office standards implementations and also disclosure of the formats, etc. There are two versions of the notes for ODF, one for Office 2007, one for Office 2010. What I'd like to point out about these implementation notes is (1) they are a fledgling effort and could use a lot more work too, but (2) these seem to be the only ODF implementation notes that *anyone* has ever produced. They are nailed to the ODF specification. - Dennis DIGGING DEEPER On the web site you can explore the implementation notes for Office 2010 ODF on-line. If you go into 2 Conformance Statements in the sidebar contents, you can then go into 2.1 Normative Variations. If you get to 2.1.209 Section 8.1.3, Table Cell, you'll see that table:formula is not supported in table cells of Word documents (and I suspect the same is true for LibreOffice Write document). (The table:formula attribute is an optional attribute on any ODF table cell.) Here is the text about table:formula for Excel 2010: iii. The standard defines the attribute table:formula, contained within the element table:table-cell, contained within the parent element office:spreadsheet \ table:table-row This attribute is supported in core Excel 2010. When saving the table:formula attribute, Excel 2010 precedes the formula string with the msoxl namespace. When saving the table:formula attribute, Excel 2010 saves a formula string that follows [ISO/IEC-29500-1] section 18.17, except workbook-names are written as literal values instead of tokens given the lack of a relationship part. When loading the attribute table:formula, Excel 2010 first looks at the namespace. If the namespace is “msoxl”, Excel 2010 will load the value of table:formula as a formula in Excel 2010. When loading the table:formula attribute, if the namespace is missing or unknown, the table:formula attribute is not loaded, and the value “office:value” is used instead. If the result of the formula is an error, Excel 2010 loads the text:p element and maps the element to an Error data type. Error data types that Excel 2010 does not support are mapped to #VALUE! Note that the formula syntax and semantics used is defined in the OOXML standard (IS 29500). -Original Message- From: e-letter [mailto:inp...@gmail.com] Sent: Friday, July 22, 2011 07:33 To: discuss@documentfoundation.org Subject: Re: [tdf-discuss] ignore m$ legacy? On 21/07/2011, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Yes, don't confuse ODF compatibility with OpenOffice.org (or LibreOffice) compatibility. I was in the room on one occasion when Microsoft was asking for advice on their approach to ODF 1.1 Spreadsheet documents. Unfortunately, none of us blinked about how this would work for users who are unaware that ODF 1.1 has no standard for calculation formulas but think that OpenOffice.org Calc is the standard. I don't believe that ODF support was broken. The ODF support in Office 2007 is the first time that integrated ODF support appeared in Microsoft Office. I know there are bugs, some of them rather surprising/disappointing. Or deliberate..? [ ... ] -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more:
Re: [tdf-discuss] ignore m$ legacy?
On 07/22/2011 10:24 AM, e-letter wrote: On 21/07/2011, Andrew Douglas Pitonyakand...@pitonyak.org wrote: On 07/21/2011 08:47 AM, e-letter wrote: On 21/07/2011, Andrew Douglas Pitonyakand...@pitonyak.org wrote I am more comfortable in OOo than I am in MSO, so, I have created many MSO deliverables in OOo and LO. The only time that I make an exception is when I believe that I am not able to seamlessly move between formats because of incompatibilities. So, if I intend to create a large document with multiple images, links, and fields, I begin and end with MSO. That is your prerogative, but it is preferable to see writer used to create such large documents in the native odt format, at least to demonstrate the power of LO. The problem is that the final deliverable to the client is an MSO document and the complicated structures that I frequently use do not properly export to the MSO document format. It is very time consuming to work through a 250 page document full of cross-references and text frames that do NOT export to the format required by the client. I lost many hours fixing up the document in MSO so that it would be ready for final delivery. In my opinion interoperability with the _m$ format_ weakens increased adoption of the odf. At the start of a 250 page document, ideally the decision should be made to use odt and the issue become ensuring that LO behaviour in native odt format occurs with minimal bugs. This experience alone should promote wider adoption of LO. The claim to offer (or attain to) perfect interoperability with the _m$ format_ leads to time wasted trying to get LO to work with m$. If the end requirement is m$, pay to use m$. If anything, this experience means that LO is less likely to be used because if there is a change in requirements and I must generate and deliver an MSO document, then I had better not be using LO if the document will be sufficiently complex that it will not export well. Even worse, given that MSO has the greatest market share it means that most legacy documents use the MSO formats. I knew many people that refused to switch from Word Perfect when I told them that OOo would NOT read their document archives that they spent years creating. To date, I have seen only one client that requested that an ODF document be the final deliverable. As they went around the table trying to figure out what experience the large team had with OOo, the best that was there was yeah, heard about it, never used it. LO does not have sufficient penetration to play like MS to force users into staying with LO. The point of the original post, is that priority should be for LO performance in native odf to be better than m$o performance in native m$ format (or indeed secondary odf). Oh! Ummm, yeah. I think that I was just hit in the head with something important and logical. :-) It does not seem right that people complain that writer does not save to m$ format well, when the statement writer creates beautiful, easily-created odf documents should be the main reason to use LO. Let me add to your statement, because much of it is VERY important. 1. Many people find the LO interface more intuitive, easy, and obvious to use than learning the new MSO interface. 2. Most people do NOT write complex documents (think home user that writes letters and such) so complex support is not required. That said, when people complain that there is an issue with formatting, it tells me that either (a) The document has some level of complexity (b) There are probably things that float around (like frames or images), and these are very difficult to get right. Even MSO has issues when moving between versions. -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.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.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
