[xwiki-devs] [PROPOSAL] Use openoffice server when its enabled to do PDF/RTF export
Hi devs, Really fixing http://jira.xwiki.org/jira/browse/XWIKI-5251 as it is is a real pain, i.e. using FOP. That would need a XSLT wizard and anyway RTF support is not very good in FOP (according to FOP documentation). And seriously for a format like RTF it's a waste of time IMO. So what i propose for 2.4 is to do a small modification to PDF/RTF exporter to use openoffice server when it's connected. There is already everything needed for that in openoffice component which is used for office import currently. That would be a good POC for the future office exporter which will need a lot of refactoring and API to be clean. For this proposal I'm just modifying PdfExportImpl is a as clean as possible way to have this in 2.4. The only limitation currently is that OpenOffice does not really support XHTML and parse the content as it was HTML but since we have the same constraint with IE6 it's OK for now I guess. See http://qa.openoffice.org/issues/show_bug.cgi?id=69635 for more. WDYT ? We should probably not show RTF export in the menu when openoffice server is not connected since it does not work at all even with empty content or remove the table generated by the XSLT filter for the cover. -- Thomas Mortagne
Hi, On Fri, Jun 18, 2010 at 12:38, Thomas Mortagne <[email protected]>wrote:
Hi devs,
Really fixing http://jira.xwiki.org/jira/browse/XWIKI-5251 as it is is a real pain, i.e. using FOP. That would need a XSLT wizard and anyway RTF support is not very good in FOP (according to FOP documentation). And seriously for a format like RTF it's a waste of time IMO.
So what i propose for 2.4 is to do a small modification to PDF/RTF exporter to use openoffice server when it's connected. There is already everything needed for that in openoffice component which is used for office import currently.
That would be a good POC for the future office exporter which will need a lot of refactoring and API to be clean. For this proposal I'm just modifying PdfExportImpl is a as clean as possible way to have this in 2.4.
The only limitation currently is that OpenOffice does not really support XHTML and parse the content as it was HTML but since we have the same constraint with IE6 it's OK for now I guess. See http://qa.openoffice.org/issues/show_bug.cgi?id=69635 for more.
+1, I thinks it would be a nice experiment and since the current RTF export hardly works it's an improvement even if it's not perfect yet. Guillaume WDYT ?
We should probably not show RTF export in the menu when openoffice server is not connected since it does not work at all even with empty content or remove the table generated by the XSLT filter for the cover.
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 Thanks, Marius On 06/18/2010 01:38 PM, Thomas Mortagne wrote:
Hi devs,
Really fixing http://jira.xwiki.org/jira/browse/XWIKI-5251 as it is is a real pain, i.e. using FOP. That would need a XSLT wizard and anyway RTF support is not very good in FOP (according to FOP documentation). And seriously for a format like RTF it's a waste of time IMO.
So what i propose for 2.4 is to do a small modification to PDF/RTF exporter to use openoffice server when it's connected. There is already everything needed for that in openoffice component which is used for office import currently.
That would be a good POC for the future office exporter which will need a lot of refactoring and API to be clean. For this proposal I'm just modifying PdfExportImpl is a as clean as possible way to have this in 2.4.
The only limitation currently is that OpenOffice does not really support XHTML and parse the content as it was HTML but since we have the same constraint with IE6 it's OK for now I guess. See http://qa.openoffice.org/issues/show_bug.cgi?id=69635 for more.
WDYT ?
We should probably not show RTF export in the menu when openoffice server is not connected since it does not work at all even with empty content or remove the table generated by the XSLT filter for the cover.
On Fri, Jun 18, 2010 at 12:38, Thomas Mortagne <[email protected]>wrote:
Hi devs,
Really fixing http://jira.xwiki.org/jira/browse/XWIKI-5251 as it is is a real pain, i.e. using FOP. That would need a XSLT wizard and anyway RTF support is not very good in FOP (according to FOP documentation). And seriously for a format like RTF it's a waste of time IMO.
So what i propose for 2.4 is to do a small modification to PDF/RTF exporter to use openoffice server when it's connected. There is already everything needed for that in openoffice component which is used for office import currently.
That would be a good POC for the future office exporter which will need a lot of refactoring and API to be clean. For this proposal I'm just modifying PdfExportImpl is a as clean as possible way to have this in 2.4.
The only limitation currently is that OpenOffice does not really support XHTML and parse the content as it was HTML but since we have the same constraint with IE6 it's OK for now I guess. See http://qa.openoffice.org/issues/show_bug.cgi?id=69635 for more.
WDYT ?
How do you expect to support customization of the generated output as we have currently the ability to use a PDFClass to change the default behaviour ? (even if there is some issue due to the size of the XSLT) Denis
We should probably not show RTF export in the menu when openoffice server is not connected since it does not work at all even with empty content or remove the table generated by the XSLT filter for the cover.
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Fri, Jun 18, 2010 at 14:23, Denis Gervalle <[email protected]> wrote:
On Fri, Jun 18, 2010 at 12:38, Thomas Mortagne <[email protected]>wrote:
Hi devs,
Really fixing http://jira.xwiki.org/jira/browse/XWIKI-5251 as it is is a real pain, i.e. using FOP. That would need a XSLT wizard and anyway RTF support is not very good in FOP (according to FOP documentation). And seriously for a format like RTF it's a waste of time IMO.
So what i propose for 2.4 is to do a small modification to PDF/RTF exporter to use openoffice server when it's connected. There is already everything needed for that in openoffice component which is used for office import currently.
That would be a good POC for the future office exporter which will need a lot of refactoring and API to be clean. For this proposal I'm just modifying PdfExportImpl is a as clean as possible way to have this in 2.4.
The only limitation currently is that OpenOffice does not really support XHTML and parse the content as it was HTML but since we have the same constraint with IE6 it's OK for now I guess. See http://qa.openoffice.org/issues/show_bug.cgi?id=69635 for more.
WDYT ?
How do you expect to support customization of the generated output as we have currently the ability to use a PDFClass to change the default behaviour ? (even if there is some issue due to the size of the XSLT)
The part about customizing the XSL-FO is obviously not supported but PDFClass.style is since it's about the xhtml content before it's converted to XSL-FO. I could add something like PDFClass.xhtmlofficexsl to customize the xhtml before exporting it like we have PDFClass.fopxsl to customize XSL-FO content for maybe if needed. And it's still possible to customize the xhtml by modifying pdf.vm of course.
Denis
We should probably not show RTF export in the menu when openoffice server is not connected since it does not work at all even with empty content or remove the table generated by the XSLT filter for the cover.
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Fri, Jun 18, 2010 at 15:01, Thomas Mortagne <[email protected]>wrote:
On Fri, Jun 18, 2010 at 14:23, Denis Gervalle <[email protected]> wrote:
On Fri, Jun 18, 2010 at 12:38, Thomas Mortagne < [email protected]>wrote:
Hi devs,
Really fixing http://jira.xwiki.org/jira/browse/XWIKI-5251 as it is is a real pain, i.e. using FOP. That would need a XSLT wizard and anyway RTF support is not very good in FOP (according to FOP documentation). And seriously for a format like RTF it's a waste of time IMO.
So what i propose for 2.4 is to do a small modification to PDF/RTF exporter to use openoffice server when it's connected. There is already everything needed for that in openoffice component which is used for office import currently.
That would be a good POC for the future office exporter which will need a lot of refactoring and API to be clean. For this proposal I'm just modifying PdfExportImpl is a as clean as possible way to have this in 2.4.
The only limitation currently is that OpenOffice does not really support XHTML and parse the content as it was HTML but since we have the same constraint with IE6 it's OK for now I guess. See http://qa.openoffice.org/issues/show_bug.cgi?id=69635 for more.
WDYT ?
How do you expect to support customization of the generated output as we have currently the ability to use a PDFClass to change the default behaviour ? (even if there is some issue due to the size of the XSLT)
The part about customizing the XSL-FO is obviously not supported but PDFClass.style is since it's about the xhtml content before it's converted to XSL-FO.
I could add something like PDFClass.xhtmlofficexsl to customize the xhtml before exporting it like we have PDFClass.fopxsl to customize XSL-FO content for maybe if needed.
And it's still possible to customize the xhtml by modifying pdf.vm of course.
Well, this could implied the need to rewrite the XSLT. So I am +1, but with a parameter that choose to use FOP for PDF even when a OO server is available, and for compatibility to use that setting by default. PDF output through FOP will always be me customizable that through OO and this is IMO a real feature that we should no hide for fixing RTF. Denis
We should probably not show RTF export in the menu when openoffice server is not connected since it does not work at all even with empty content or remove the table generated by the XSLT filter for the cover.
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Fri, Jun 18, 2010 at 15:39, Denis Gervalle <[email protected]> wrote:
On Fri, Jun 18, 2010 at 15:01, Thomas Mortagne <[email protected]>wrote:
On Fri, Jun 18, 2010 at 14:23, Denis Gervalle <[email protected]> wrote:
On Fri, Jun 18, 2010 at 12:38, Thomas Mortagne < [email protected]>wrote:
Hi devs,
Really fixing http://jira.xwiki.org/jira/browse/XWIKI-5251 as it is is a real pain, i.e. using FOP. That would need a XSLT wizard and anyway RTF support is not very good in FOP (according to FOP documentation). And seriously for a format like RTF it's a waste of time IMO.
So what i propose for 2.4 is to do a small modification to PDF/RTF exporter to use openoffice server when it's connected. There is already everything needed for that in openoffice component which is used for office import currently.
That would be a good POC for the future office exporter which will need a lot of refactoring and API to be clean. For this proposal I'm just modifying PdfExportImpl is a as clean as possible way to have this in 2.4.
The only limitation currently is that OpenOffice does not really support XHTML and parse the content as it was HTML but since we have the same constraint with IE6 it's OK for now I guess. See http://qa.openoffice.org/issues/show_bug.cgi?id=69635 for more.
WDYT ?
How do you expect to support customization of the generated output as we have currently the ability to use a PDFClass to change the default behaviour ? (even if there is some issue due to the size of the XSLT)
The part about customizing the XSL-FO is obviously not supported but PDFClass.style is since it's about the xhtml content before it's converted to XSL-FO.
I could add something like PDFClass.xhtmlofficexsl to customize the xhtml before exporting it like we have PDFClass.fopxsl to customize XSL-FO content for maybe if needed.
And it's still possible to customize the xhtml by modifying pdf.vm of course.
Well, this could implied the need to rewrite the XSLT. So I am +1, but with a parameter that choose to use FOP for PDF even when a OO server is available, and for compatibility to use that setting by default. PDF output through FOP will always be me customizable that through OO and
In that case maybe this proposal should probably be only about RTF.
this is IMO a real feature that we should no hide for fixing RTF.
Denis
We should probably not show RTF export in the menu when openoffice server is not connected since it does not work at all even with empty content or remove the table generated by the XSLT filter for the cover.
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi, Big +1. I also wanted to try out wiki page exporting using office importer api (well, now it's more like office converter api). The interesting thing is with openoffice we can convert html into many other formats (word, pdf, rtf etc.). It would be interesting to find out the quality of these exports. Also we should think about dividing xwiki-officeimporter into sub-modules like xwiki-officeconverter, xwiki-officeimporter and xwiki-officeexporter. Thanks. - Asiri On Fri, Jun 18, 2010 at 4:08 PM, Thomas Mortagne <[email protected]>wrote:
Hi devs,
Really fixing http://jira.xwiki.org/jira/browse/XWIKI-5251 as it is is a real pain, i.e. using FOP. That would need a XSLT wizard and anyway RTF support is not very good in FOP (according to FOP documentation). And seriously for a format like RTF it's a waste of time IMO.
So what i propose for 2.4 is to do a small modification to PDF/RTF exporter to use openoffice server when it's connected. There is already everything needed for that in openoffice component which is used for office import currently.
That would be a good POC for the future office exporter which will need a lot of refactoring and API to be clean. For this proposal I'm just modifying PdfExportImpl is a as clean as possible way to have this in 2.4.
The only limitation currently is that OpenOffice does not really support XHTML and parse the content as it was HTML but since we have the same constraint with IE6 it's OK for now I guess. See http://qa.openoffice.org/issues/show_bug.cgi?id=69635 for more.
WDYT ?
We should probably not show RTF export in the menu when openoffice server is not connected since it does not work at all even with empty content or remove the table generated by the XSLT filter for the cover.
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jun 18, 2010, at 4:51 PM, Asiri Rathnayake wrote:
Hi,
Big +1.
I also wanted to try out wiki page exporting using office importer api (well, now it's more like office converter api). The interesting thing is with openoffice we can convert html into many other formats (word, pdf, rtf etc.). It would be interesting to find out the quality of these exports.
Also we should think about dividing xwiki-officeimporter into sub-modules like xwiki-officeconverter, xwiki-officeimporter and xwiki-officeexporter.
I think xwiki-office or xwki-openoffice might be enough to hold them all in a single module. We can have packages though. Thanks -Vincent
Thanks.
- Asiri
On Fri, Jun 18, 2010 at 4:08 PM, Thomas Mortagne <[email protected]>wrote:
Hi devs,
Really fixing http://jira.xwiki.org/jira/browse/XWIKI-5251 as it is is a real pain, i.e. using FOP. That would need a XSLT wizard and anyway RTF support is not very good in FOP (according to FOP documentation). And seriously for a format like RTF it's a waste of time IMO.
So what i propose for 2.4 is to do a small modification to PDF/RTF exporter to use openoffice server when it's connected. There is already everything needed for that in openoffice component which is used for office import currently.
That would be a good POC for the future office exporter which will need a lot of refactoring and API to be clean. For this proposal I'm just modifying PdfExportImpl is a as clean as possible way to have this in 2.4.
The only limitation currently is that OpenOffice does not really support XHTML and parse the content as it was HTML but since we have the same constraint with IE6 it's OK for now I guess. See http://qa.openoffice.org/issues/show_bug.cgi?id=69635 for more.
WDYT ?
We should probably not show RTF export in the menu when openoffice server is not connected since it does not work at all even with empty content or remove the table generated by the XSLT filter for the cover.
-- Thomas Mortagne
On Fri, Jun 18, 2010 at 16:51, Asiri Rathnayake <[email protected]> wrote:
Hi,
Big +1.
I also wanted to try out wiki page exporting using office importer api (well, now it's more like office converter api). The interesting thing is with openoffice we can convert html into many other formats (word, pdf, rtf etc.). It would be interesting to find out the quality of these exports.
Also we should think about dividing xwiki-officeimporter into sub-modules like xwiki-officeconverter, xwiki-officeimporter and xwiki-officeexporter.
Yes that's part of the "will need a lot of refactoring and API to be clean" in my mail ;)
Thanks.
- Asiri
On Fri, Jun 18, 2010 at 4:08 PM, Thomas Mortagne <[email protected]>wrote:
Hi devs,
Really fixing http://jira.xwiki.org/jira/browse/XWIKI-5251 as it is is a real pain, i.e. using FOP. That would need a XSLT wizard and anyway RTF support is not very good in FOP (according to FOP documentation). And seriously for a format like RTF it's a waste of time IMO.
So what i propose for 2.4 is to do a small modification to PDF/RTF exporter to use openoffice server when it's connected. There is already everything needed for that in openoffice component which is used for office import currently.
That would be a good POC for the future office exporter which will need a lot of refactoring and API to be clean. For this proposal I'm just modifying PdfExportImpl is a as clean as possible way to have this in 2.4.
The only limitation currently is that OpenOffice does not really support XHTML and parse the content as it was HTML but since we have the same constraint with IE6 it's OK for now I guess. See http://qa.openoffice.org/issues/show_bug.cgi?id=69635 for more.
WDYT ?
We should probably not show RTF export in the menu when openoffice server is not connected since it does not work at all even with empty content or remove the table generated by the XSLT filter for the cover.
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Le 18/06/10 12:38, Thomas Mortagne a écrit :
Hi devs,
Really fixing http://jira.xwiki.org/jira/browse/XWIKI-5251 as it is is a real pain, i.e. using FOP. That would need a XSLT wizard and anyway RTF support is not very good in FOP (according to FOP documentation). And seriously for a format like RTF it's a waste of time IMO.
So what i propose for 2.4 is to do a small modification to PDF/RTF exporter to use openoffice server when it's connected. There is already everything needed for that in openoffice component which is used for office import currently.
That would be a good POC for the future office exporter which will need a lot of refactoring and API to be clean. For this proposal I'm just modifying PdfExportImpl is a as clean as possible way to have this in 2.4.
The only limitation currently is that OpenOffice does not really support XHTML and parse the content as it was HTML but since we have the same constraint with IE6 it's OK for now I guess. See http://qa.openoffice.org/issues/show_bug.cgi?id=69635 for more.
WDYT ?
We should probably not show RTF export in the menu when openoffice server is not connected since it does not work at all even with empty content or remove the table generated by the XSLT filter for the cover.
Why not use the opportunity to export to DOC instead/in addition of RTF. It would be only support the DOC export param and add/replace one menu to show DOC. We used RTF only because FOP only did RTF while what we really want is DOC Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On 06/18/2010 05:29 PM, Ludovic Dubost wrote:
Le 18/06/10 12:38, Thomas Mortagne a écrit :
Hi devs,
Really fixing http://jira.xwiki.org/jira/browse/XWIKI-5251 as it is is a real pain, i.e. using FOP. That would need a XSLT wizard and anyway RTF support is not very good in FOP (according to FOP documentation). And seriously for a format like RTF it's a waste of time IMO.
So what i propose for 2.4 is to do a small modification to PDF/RTF exporter to use openoffice server when it's connected. There is already everything needed for that in openoffice component which is used for office import currently.
That would be a good POC for the future office exporter which will need a lot of refactoring and API to be clean. For this proposal I'm just modifying PdfExportImpl is a as clean as possible way to have this in 2.4.
The only limitation currently is that OpenOffice does not really support XHTML and parse the content as it was HTML but since we have the same constraint with IE6 it's OK for now I guess. See http://qa.openoffice.org/issues/show_bug.cgi?id=69635 for more.
WDYT ?
We should probably not show RTF export in the menu when openoffice server is not connected since it does not work at all even with empty content or remove the table generated by the XSLT filter for the cover.
Why not use the opportunity to export to DOC instead/in addition of RTF. It would be only support the DOC export param and add/replace one menu to show DOC.
We used RTF only because FOP only did RTF while what we really want is DOC
Ludovic
Supporting .doc is a bit, well, late. I'm saying this because .docx should be the new and improved version, so a more relevant format would be .docx (Office Open XML). However, even Microsoft recognized that OOXML lost the battle with ODF, and the future format which will be supported by most tools seems to be ODF. And, in addition, .doc is a binary, proprietary and secret format, and we try to encourage open and/or standard formats. Yet, a large share of XWiki users are still using older versions of the MS Office suite, which makes .doc almost mandatory... -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Fri, Jun 18, 2010 at 18:05, Sergiu Dumitriu <[email protected]> wrote:
On 06/18/2010 05:29 PM, Ludovic Dubost wrote:
Le 18/06/10 12:38, Thomas Mortagne a écrit :
Hi devs,
Really fixing http://jira.xwiki.org/jira/browse/XWIKI-5251 as it is is a real pain, i.e. using FOP. That would need a XSLT wizard and anyway RTF support is not very good in FOP (according to FOP documentation). And seriously for a format like RTF it's a waste of time IMO.
So what i propose for 2.4 is to do a small modification to PDF/RTF exporter to use openoffice server when it's connected. There is already everything needed for that in openoffice component which is used for office import currently.
That would be a good POC for the future office exporter which will need a lot of refactoring and API to be clean. For this proposal I'm just modifying PdfExportImpl is a as clean as possible way to have this in 2.4.
The only limitation currently is that OpenOffice does not really support XHTML and parse the content as it was HTML but since we have the same constraint with IE6 it's OK for now I guess. See http://qa.openoffice.org/issues/show_bug.cgi?id=69635 for more.
WDYT ?
We should probably not show RTF export in the menu when openoffice server is not connected since it does not work at all even with empty content or remove the table generated by the XSLT filter for the cover.
Why not use the opportunity to export to DOC instead/in addition of RTF. It would be only support the DOC export param and add/replace one menu to show DOC.
We used RTF only because FOP only did RTF while what we really want is DOC
Ludovic
Supporting .doc is a bit, well, late. I'm saying this because .docx should be the new and improved version, so a more relevant format would be .docx (Office Open XML). However, even Microsoft recognized that OOXML lost the battle with ODF, and the future format which will be supported by most tools seems to be ODF.
And, in addition, .doc is a binary, proprietary and secret format, and we try to encourage open and/or standard formats.
Yet, a large share of XWiki users are still using older versions of the MS Office suite, which makes .doc almost mandatory...
That's for this kind of conversion i don't want to change anything to the format exported in 2.4 ;) I let this for office exporter work that will be done in 2.5.
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Fri, Jun 18, 2010 at 18:12, Thomas Mortagne <[email protected]> wrote:
On Fri, Jun 18, 2010 at 18:05, Sergiu Dumitriu <[email protected]> wrote:
On 06/18/2010 05:29 PM, Ludovic Dubost wrote:
Le 18/06/10 12:38, Thomas Mortagne a écrit :
Hi devs,
Really fixing http://jira.xwiki.org/jira/browse/XWIKI-5251 as it is is a real pain, i.e. using FOP. That would need a XSLT wizard and anyway RTF support is not very good in FOP (according to FOP documentation). And seriously for a format like RTF it's a waste of time IMO.
So what i propose for 2.4 is to do a small modification to PDF/RTF exporter to use openoffice server when it's connected. There is already everything needed for that in openoffice component which is used for office import currently.
That would be a good POC for the future office exporter which will need a lot of refactoring and API to be clean. For this proposal I'm just modifying PdfExportImpl is a as clean as possible way to have this in 2.4.
The only limitation currently is that OpenOffice does not really support XHTML and parse the content as it was HTML but since we have the same constraint with IE6 it's OK for now I guess. See http://qa.openoffice.org/issues/show_bug.cgi?id=69635 for more.
WDYT ?
We should probably not show RTF export in the menu when openoffice server is not connected since it does not work at all even with empty content or remove the table generated by the XSLT filter for the cover.
Why not use the opportunity to export to DOC instead/in addition of RTF. It would be only support the DOC export param and add/replace one menu to show DOC.
We used RTF only because FOP only did RTF while what we really want is DOC
Ludovic
Supporting .doc is a bit, well, late. I'm saying this because .docx should be the new and improved version, so a more relevant format would be .docx (Office Open XML). However, even Microsoft recognized that OOXML lost the battle with ODF, and the future format which will be supported by most tools seems to be ODF.
And, in addition, .doc is a binary, proprietary and secret format, and we try to encourage open and/or standard formats.
Yet, a large share of XWiki users are still using older versions of the MS Office suite, which makes .doc almost mandatory...
That's for this kind of conversion i don't want to change anything to
s/conversion/conversation/
the format exported in 2.4 ;) I let this for office exporter work that will be done in 2.5.
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne
Hi,
Why not use the opportunity to export to DOC instead/in addition of RTF. It would be only support the DOC export param and add/replace one menu to show DOC.
We used RTF only because FOP only did RTF while what we really want is
DOC
Ludovic
Supporting .doc is a bit, well, late. I'm saying this because .docx should be the new and improved version, so a more relevant format would be .docx (Office Open XML). However, even Microsoft recognized that OOXML lost the battle with ODF, and the future format which will be supported by most tools seems to be ODF.
We don't have to choose one. If we provide one format via OOo then we can provide all popular formats(pdf, doc, docx, odf). The cost of exporting extra formats is quite low. Thanks, Florin Ciubotaru
And, in addition, .doc is a binary, proprietary and secret format, and we try to encourage open and/or standard formats.
Yet, a large share of XWiki users are still using older versions of the MS Office suite, which makes .doc almost mandatory...
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Fri, Jun 18, 2010 at 19:03, Florin Ciubotaru <[email protected]> wrote:
Hi,
Why not use the opportunity to export to DOC instead/in addition of RTF. It would be only support the DOC export param and add/replace one menu to show DOC.
We used RTF only because FOP only did RTF while what we really want is
DOC
Ludovic
Supporting .doc is a bit, well, late. I'm saying this because .docx should be the new and improved version, so a more relevant format would be .docx (Office Open XML). However, even Microsoft recognized that OOXML lost the battle with ODF, and the future format which will be supported by most tools seems to be ODF.
We don't have to choose one. If we provide one format via OOo then we can provide all popular formats(pdf, doc, docx, odf). The cost of exporting extra formats is quite low.
Again this proposal is not about office exporter which needs a lot more work...
Thanks, Florin Ciubotaru
And, in addition, .doc is a binary, proprietary and secret format, and we try to encourage open and/or standard formats.
Yet, a large share of XWiki users are still using older versions of the MS Office suite, which makes .doc almost mandatory...
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
So for 2.4 i will commit a RTF only switch to openoffice server based export. I postpone all over decisions to 2.5 that should have a whole new office export which would make most of them a lot simplier (no need to decide which format to export, etc.). On Fri, Jun 18, 2010 at 21:44, Thomas Mortagne <[email protected]> wrote:
On Fri, Jun 18, 2010 at 19:03, Florin Ciubotaru <[email protected]> wrote:
Hi,
Why not use the opportunity to export to DOC instead/in addition of RTF. It would be only support the DOC export param and add/replace one menu to show DOC.
We used RTF only because FOP only did RTF while what we really want is
DOC
Ludovic
Supporting .doc is a bit, well, late. I'm saying this because .docx should be the new and improved version, so a more relevant format would be .docx (Office Open XML). However, even Microsoft recognized that OOXML lost the battle with ODF, and the future format which will be supported by most tools seems to be ODF.
We don't have to choose one. If we provide one format via OOo then we can provide all popular formats(pdf, doc, docx, odf). The cost of exporting extra formats is quite low.
Again this proposal is not about office exporter which needs a lot more work...
Thanks, Florin Ciubotaru
And, in addition, .doc is a binary, proprietary and secret format, and we try to encourage open and/or standard formats.
Yet, a large share of XWiki users are still using older versions of the MS Office suite, which makes .doc almost mandatory...
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne
participants (9)
-
Asiri Rathnayake -
Denis Gervalle -
Florin Ciubotaru -
Guillaume Lerouge -
Ludovic Dubost -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol