From jza at openoffice.org Mon Jul 13 07:43:10 2009 From: jza at openoffice.org (Alexandro Colorado) Date: Mon Jul 13 07:51:12 2009 Subject: [odf-discuss] Starting the project ODFkit Message-ID: <497b733b0907130443g2509bc7bqa4d8d74543cca999@mail.gmail.com> Hi list, during the past Guakademy (Desktop Summit) some members of the KDE team and myself got together to study the possibility of having an ODFkit inspired by the lights of webkit with portability and scalability in mind. The project in itself is to produce an engine that can fetch and process opendocuments with a pluggable platform similar to webkit engine which is abstracted from the toolkits and application level layers. ODFkit should also help standarize on the ODF 1.2 schema for software developers and will make it simpler to develop applications on top of it. So we are looking for a mailing list to coordinate all the team and thought about opendocument fellowship as a great place to set the project. Please let me know what the community thinks. Regards -- Alexandro Colorado & Inge Wallin OpenOffice.org Español & Koffice lead developer IM: jza@jabber.org From robert_weir at us.ibm.com Mon Jul 13 09:51:19 2009 From: robert_weir at us.ibm.com (robert_weir@us.ibm.com) Date: Mon Jul 13 10:05:21 2009 Subject: [odf-discuss] Starting the project ODFkit In-Reply-To: <497b733b0907130443g2509bc7bqa4d8d74543cca999@mail.gmail.com> References: <497b733b0907130443g2509bc7bqa4d8d74543cca999@mail.gmail.com> Message-ID: What would be the functionality of an ODFkit? Would this be a read-only document renderer? Or would it having editing capabilities as well? -Rob odf-discuss-bounces@opendocumentfellowship.com wrote on 07/13/2009 07:43:10 AM: > > Hi list, during the past Guakademy (Desktop Summit) some members of > the KDE team and myself got together to study the possibility of > having an ODFkit inspired by the lights of webkit with portability and > scalability in mind. > > The project in itself is to produce an engine that can fetch and > process opendocuments with a pluggable platform similar to webkit > engine which is abstracted from the toolkits and application level > layers. > > ODFkit should also help standarize on the ODF 1.2 schema for software > developers and will make it simpler to develop applications on top of > it. > > So we are looking for a mailing list to coordinate all the team and > thought about opendocument fellowship as a great place to set the > project. Please let me know what the community thinks. > From Soren.Roug at eea.europa.eu Mon Jul 13 10:13:36 2009 From: Soren.Roug at eea.europa.eu (=?iso-8859-1?Q?S=F8ren_Roug?=) Date: Mon Jul 13 10:23:22 2009 Subject: [odf-discuss] Starting the project ODFkit In-Reply-To: Message-ID: Yes, I was wondering about the same thing. As far as I understand, KDE can use KOffice as a KPart to display ODF files. Is this a suggestion to reimplement KOffice? There is a development list called odf-devel@opendocumentfellowship.com, which might be more appropriate when the talk turns to software design. S?ren Roug -----Original Message----- From: odf-discuss-bounces@opendocumentfellowship.com [mailto:odf-discuss-bounces@opendocumentfellowship.com] On Behalf Of robert_weir@us.ibm.com Sent: 13 July 2009 15:51 To: jza@openoffice.org; ODF Discussion List Subject: Re: [odf-discuss] Starting the project ODFkit What would be the functionality of an ODFkit? Would this be a read-only document renderer? Or would it having editing capabilities as well? -Rob odf-discuss-bounces@opendocumentfellowship.com wrote on 07/13/2009 07:43:10 AM: > > Hi list, during the past Guakademy (Desktop Summit) some members of > the KDE team and myself got together to study the possibility of > having an ODFkit inspired by the lights of webkit with portability and > scalability in mind. > > The project in itself is to produce an engine that can fetch and > process opendocuments with a pluggable platform similar to webkit > engine which is abstracted from the toolkits and application level > layers. > > ODFkit should also help standarize on the ODF 1.2 schema for software > developers and will make it simpler to develop applications on top of > it. > > So we are looking for a mailing list to coordinate all the team and > thought about opendocument fellowship as a great place to set the > project. Please let me know what the community thinks. > _______________________________________________ odf-discuss mailing list odf-discuss@opendocumentfellowship.com http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss From jza at openoffice.org Mon Jul 13 11:15:57 2009 From: jza at openoffice.org (Alexandro Colorado) Date: Mon Jul 13 11:21:53 2009 Subject: [odf-discuss] Starting the project ODFkit In-Reply-To: References: Message-ID: <497b733b0907130815o3c4b2d8aofb8d88dd34e40e22@mail.gmail.com> Well the idea is not even to render ODF, nor is to make any derivative of Koffice. In all it would be more like ODFpy but implemented on C++. Taking the advantage of compiled language to deliver the performance for processing large pools of documents. The first stage is just having a CLI that can send the document content to STOUT and is able to catch areas like metadata, content, style, etc. Second stage would be to do transformations. Simple editing could be possible at this stage since we deal with writing and generating ODF. Third is to make it fast, and also make it so it can be flexible enough to enhance commands like "less" to do things similar to what it do to PDF. The idea basically is to bring ODF to the commandline, to make it easy to implement on any distro/OS and to make it accessible for scripting or programming solutions. Is very lowlevel but designed to make it extendable under different presentation layers, API, ABI and/or Toolkits that wrap around it to create different applications. The challenges that we want to solve is issues like legacy of ODF schemas from 1.0 1.1 as well as make it easy and small to port to small computers or just create very portable software under different technologies. On Mon, Jul 13, 2009 at 3:13 PM, S?ren Roug wrote: > Yes, I was wondering about the same thing. As far as I understand, KDE can use KOffice as a KPart to display ODF files. Is this a suggestion to reimplement KOffice? > > There is a development list called odf-devel@opendocumentfellowship.com, which might be more appropriate when the talk turns to software design. > > S?ren Roug > > -----Original Message----- > From: odf-discuss-bounces@opendocumentfellowship.com [mailto:odf-discuss-bounces@opendocumentfellowship.com] On Behalf Of robert_weir@us.ibm.com > Sent: 13 July 2009 15:51 > To: jza@openoffice.org; ODF Discussion List > Subject: Re: [odf-discuss] Starting the project ODFkit > > What would be the functionality of an ODFkit? Would this be a read-only > document renderer? Or would it having editing capabilities as well? > > -Rob > > odf-discuss-bounces@opendocumentfellowship.com wrote on 07/13/2009 > 07:43:10 AM: > >> >> Hi list, during the past Guakademy (Desktop Summit) some members of >> the KDE team and myself got together to study the possibility of >> having an ODFkit inspired by the lights of webkit with portability and >> scalability in mind. >> >> The project in itself is to produce an engine that can fetch and >> process opendocuments with a pluggable platform similar to webkit >> engine which is abstracted from the toolkits and application level >> layers. >> >> ODFkit should also help standarize on the ODF 1.2 schema for software >> developers and will make it simpler to develop applications on top of >> it. >> >> So we are looking for a mailing list to coordinate all the team and >> thought about opendocument fellowship as a great place to set the >> project. Please let me know what the community thinks. >> > > _______________________________________________ > odf-discuss mailing list > odf-discuss@opendocumentfellowship.com > http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss > > _______________________________________________ > odf-discuss mailing list > odf-discuss@opendocumentfellowship.com > http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss > > -- Alexandro Colorado OpenOffice.org Español IM: jza@jabber.org From robert_weir at us.ibm.com Mon Jul 13 17:22:01 2009 From: robert_weir at us.ibm.com (robert_weir@us.ibm.com) Date: Mon Jul 13 17:24:56 2009 Subject: [odf-discuss] Starting the project ODFkit In-Reply-To: <497b733b0907130815o3c4b2d8aofb8d88dd34e40e22@mail.gmail.com> References: <497b733b0907130815o3c4b2d8aofb8d88dd34e40e22@mail.gmail.com> Message-ID: The interesting thing would be if you could get it to work with the pipes & filters unix shell paradigm, so you could run the existing GNU/Linux command line toolset against an ODF document, grep, sed, etc. Of course, dealing with the content/style mechanisms of ODF beyond that would require deeper knowledge of ODF and XML processing tools like XSLT. I don't know how far we could simplify that. Maybe an odf-sed that replaced content in a formatted ODF document would be useful? Maybe a command-line tool for combining, reordering, replacing slides in a presentation? Of course, using things like the ODF Toolkit allow all of this. and more, but that is more programming rather than simple command line scripting: http://odftoolkit.org/ -Rob odf-discuss-bounces@opendocumentfellowship.com wrote on 07/13/2009 11:15:57 AM: > > Well the idea is not even to render ODF, nor is to make any derivative > of Koffice. In all it would be more like ODFpy but implemented on C++. > Taking the advantage of compiled language to deliver the performance > for processing large pools of documents. > > The first stage is just having a CLI that can send the document > content to STOUT and is able to catch areas like metadata, content, > style, etc. > > Second stage would be to do transformations. Simple editing could be > possible at this stage since we deal with writing and generating ODF. > > Third is to make it fast, and also make it so it can be flexible > enough to enhance commands like "less" to do things similar to what it > do to PDF. > > The idea basically is to bring ODF to the commandline, to make it easy > to implement on any distro/OS and to make it accessible for scripting > or programming solutions. Is very lowlevel but designed to make it > extendable under different presentation layers, API, ABI and/or > Toolkits that wrap around it to create different applications. > > The challenges that we want to solve is issues like legacy of ODF > schemas from 1.0 1.1 as well as make it easy and small to port to > small computers or just create very portable software under different > technologies. > > On Mon, Jul 13, 2009 at 3:13 PM, S?ren Roug wrote: > > Yes, I was wondering about the same thing. As far as I understand, > KDE can use KOffice as a KPart to display ODF files. Is this a > suggestion to reimplement KOffice? > > > > There is a development list called odf- > devel@opendocumentfellowship.com, which might be more appropriate > when the talk turns to software design. > > > > S?ren Roug > > > > -----Original Message----- > > From: odf-discuss-bounces@opendocumentfellowship.com [mailto:odf- > discuss-bounces@opendocumentfellowship.com] On Behalf Of > robert_weir@us.ibm.com > > Sent: 13 July 2009 15:51 > > To: jza@openoffice.org; ODF Discussion List > > Subject: Re: [odf-discuss] Starting the project ODFkit > > > > What would be the functionality of an ODFkit? Would this be a read-only > > document renderer? Or would it having editing capabilities as well? > > > > -Rob > > > > odf-discuss-bounces@opendocumentfellowship.com wrote on 07/13/2009 > > 07:43:10 AM: > > > >> > >> Hi list, during the past Guakademy (Desktop Summit) some members of > >> the KDE team and myself got together to study the possibility of > >> having an ODFkit inspired by the lights of webkit with portability and > >> scalability in mind. > >> > >> The project in itself is to produce an engine that can fetch and > >> process opendocuments with a pluggable platform similar to webkit > >> engine which is abstracted from the toolkits and application level > >> layers. > >> > >> ODFkit should also help standarize on the ODF 1.2 schema for software > >> developers and will make it simpler to develop applications on top of > >> it. > >> > >> So we are looking for a mailing list to coordinate all the team and > >> thought about opendocument fellowship as a great place to set the > >> project. Please let me know what the community thinks. > >> > > > > _______________________________________________ > > odf-discuss mailing list > > odf-discuss@opendocumentfellowship.com > > http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss > > > > _______________________________________________ > > odf-discuss mailing list > > odf-discuss@opendocumentfellowship.com > > http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss > > > > > > > > -- > Alexandro Colorado > OpenOffice.org Español > IM: jza@jabber.org > _______________________________________________ > odf-discuss mailing list > odf-discuss@opendocumentfellowship.com > http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss > From jza at openoffice.org Mon Jul 13 18:32:03 2009 From: jza at openoffice.org (Alexandro Colorado) Date: Mon Jul 13 18:32:06 2009 Subject: [odf-discuss] Starting the project ODFkit In-Reply-To: References: <497b733b0907130815o3c4b2d8aofb8d88dd34e40e22@mail.gmail.com> Message-ID: <497b733b0907131532k22803d83qcb2c061625477417@mail.gmail.com> On Mon, Jul 13, 2009 at 10:22 PM, wrote: > The interesting thing would be if you could get it to work with the pipes > & filters unix shell paradigm, so you could run the existing GNU/Linux > command line toolset against an ODF document, grep, sed, etc. Yes that the intend, to make it scriptable. > Of course, dealing with the content/style mechanisms of ODF beyond that > would require deeper knowledge of ODF and XML processing tools like XSLT. > I don't know how far we could simplify that. That could be develop at a later stage, XSLT could be too slow to be implementable, we do want to implement the ODF schema so is relatively faster. > Maybe an odf-sed that replaced content in a formatted ODF document would > be useful? Yes, simple editing could be in the future and maybe with a larger development coudl be a emacs macro or having something a-la-latex. > Maybe a command-line tool for combining, reordering, replacing slides in a > presentation? > > Of course, using things like the ODF Toolkit allow all of this. and more, > but that is more programming rather than simple command line scripting: > http://odftoolkit.org/ Yes plus is a bit slow and large to be portable let say on mobiles or something similar. > -Rob > > odf-discuss-bounces@opendocumentfellowship.com wrote on 07/13/2009 > 11:15:57 AM: > > >> >> Well the idea is not even to render ODF, nor is to make any derivative >> of Koffice. In all it would be more like ODFpy but implemented on C++. >> Taking the advantage of compiled language to deliver the performance >> for processing large pools of documents. >> >> The first stage is just having a CLI that can send the document >> content to STOUT and is able to catch areas like metadata, content, >> style, etc. >> >> Second stage would be to do transformations. Simple editing could be >> possible at this stage since we deal with writing and generating ODF. >> >> Third is to make it fast, and also make it so it can be flexible >> enough to enhance commands like "less" to do things similar to what it >> do to PDF. >> >> The idea basically is to bring ODF to the commandline, to make it easy >> to implement on any distro/OS and to make it accessible for scripting >> or programming solutions. Is very lowlevel but designed to make it >> extendable under different presentation layers, API, ABI and/or >> Toolkits that wrap around it to create different applications. >> >> The challenges that we want to solve is issues like legacy of ODF >> schemas from 1.0 1.1 as well as make it easy and small to port to >> small computers or just create very portable software under different >> technologies. >> >> On Mon, Jul 13, 2009 at 3:13 PM, S?ren Roug > wrote: >> > Yes, I was wondering about the same thing. As far as I understand, >> KDE can use KOffice as a KPart to display ODF files. Is this a >> suggestion to reimplement KOffice? >> > >> > There is a development list called odf- >> devel@opendocumentfellowship.com, which might be more appropriate >> when the talk turns to software design. >> > >> > S?ren Roug >> > >> > -----Original Message----- >> > From: odf-discuss-bounces@opendocumentfellowship.com [mailto:odf- >> discuss-bounces@opendocumentfellowship.com] On Behalf Of >> robert_weir@us.ibm.com >> > Sent: 13 July 2009 15:51 >> > To: jza@openoffice.org; ODF Discussion List >> > Subject: Re: [odf-discuss] Starting the project ODFkit >> > >> > What would be the functionality of an ODFkit? Would this be a > read-only >> > document renderer? Or would it having editing capabilities as well? >> > >> > -Rob >> > >> > odf-discuss-bounces@opendocumentfellowship.com wrote on 07/13/2009 >> > 07:43:10 AM: >> > >> >> >> >> Hi list, during the past Guakademy (Desktop Summit) some members of >> >> the KDE team and myself got together to study the possibility of >> >> having an ODFkit inspired by the lights of webkit with portability > and >> >> scalability in mind. >> >> >> >> The project in itself is to produce an engine that can fetch and >> >> process opendocuments with a pluggable platform similar to webkit >> >> engine which is abstracted from the toolkits and application level >> >> layers. >> >> >> >> ODFkit should also help standarize on the ODF 1.2 schema for software >> >> developers and will make it simpler to develop applications on top of >> >> it. >> >> >> >> So we are looking for a mailing list to coordinate all the team and >> >> thought about opendocument fellowship as a great place to set the >> >> project. Please let me know what the community thinks. >> >> >> > >> > _______________________________________________ >> > odf-discuss mailing list >> > odf-discuss@opendocumentfellowship.com >> > http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss >> > >> > _______________________________________________ >> > odf-discuss mailing list >> > odf-discuss@opendocumentfellowship.com >> > http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss >> > >> > >> >> >> >> -- >> Alexandro Colorado >> OpenOffice.org Español >> IM: jza@jabber.org >> _______________________________________________ >> odf-discuss mailing list >> odf-discuss@opendocumentfellowship.com >> http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss >> > > -- Alexandro Colorado OpenOffice.org Español IM: jza@jabber.org From jdavid at itaapy.com Wed Jul 15 04:17:54 2009 From: jdavid at itaapy.com (=?UTF-8?B?IkouIERhdmlkIEliw6HDsWV6Ig==?=) Date: Wed Jul 15 04:35:08 2009 Subject: [odf-discuss] Starting the project ODFkit In-Reply-To: <497b733b0907130815o3c4b2d8aofb8d88dd34e40e22@mail.gmail.com> References: <497b733b0907130815o3c4b2d8aofb8d88dd34e40e22@mail.gmail.com> Message-ID: <4A5D90B2.90200@itaapy.com> You may be interested in the LPod project: http://lpod-project.org/ Its main deliverable would be an specification that could be implemented in any language. There will be a reference implementation in Python, and other two alternative implementations in Perl and Ruby. To have a C++ implementation would be cool, the three above could be reduced to wrappers. The project is leaded by Jean-Marie Gouarn?, who previously developed OpenOffice::OODoc, a mature and widely used tool in Perl to do the same thing. Alexandro Colorado wrote: > Well the idea is not even to render ODF, nor is to make any derivative > of Koffice. In all it would be more like ODFpy but implemented on C++. > Taking the advantage of compiled language to deliver the performance > for processing large pools of documents. > > The first stage is just having a CLI that can send the document > content to STOUT and is able to catch areas like metadata, content, > style, etc. > > Second stage would be to do transformations. Simple editing could be > possible at this stage since we deal with writing and generating ODF. > > Third is to make it fast, and also make it so it can be flexible > enough to enhance commands like "less" to do things similar to what it > do to PDF. > > The idea basically is to bring ODF to the commandline, to make it easy > to implement on any distro/OS and to make it accessible for scripting > or programming solutions. Is very lowlevel but designed to make it > extendable under different presentation layers, API, ABI and/or > Toolkits that wrap around it to create different applications. > > The challenges that we want to solve is issues like legacy of ODF > schemas from 1.0 1.1 as well as make it easy and small to port to > small computers or just create very portable software under different > technologies. > > On Mon, Jul 13, 2009 at 3:13 PM, S?ren Roug wrote: >> Yes, I was wondering about the same thing. As far as I understand, KDE can use KOffice as a KPart to display ODF files. Is this a suggestion to reimplement KOffice? >> >> There is a development list called odf-devel@opendocumentfellowship.com, which might be more appropriate when the talk turns to software design. >> >> S?ren Roug >> >> -----Original Message----- >> From: odf-discuss-bounces@opendocumentfellowship.com [mailto:odf-discuss-bounces@opendocumentfellowship.com] On Behalf Of robert_weir@us.ibm.com >> Sent: 13 July 2009 15:51 >> To: jza@openoffice.org; ODF Discussion List >> Subject: Re: [odf-discuss] Starting the project ODFkit >> >> What would be the functionality of an ODFkit? Would this be a read-only >> document renderer? Or would it having editing capabilities as well? >> >> -Rob >> >> odf-discuss-bounces@opendocumentfellowship.com wrote on 07/13/2009 >> 07:43:10 AM: >> >>> Hi list, during the past Guakademy (Desktop Summit) some members of >>> the KDE team and myself got together to study the possibility of >>> having an ODFkit inspired by the lights of webkit with portability and >>> scalability in mind. >>> >>> The project in itself is to produce an engine that can fetch and >>> process opendocuments with a pluggable platform similar to webkit >>> engine which is abstracted from the toolkits and application level >>> layers. >>> >>> ODFkit should also help standarize on the ODF 1.2 schema for software >>> developers and will make it simpler to develop applications on top of >>> it. >>> >>> So we are looking for a mailing list to coordinate all the team and >>> thought about opendocument fellowship as a great place to set the >>> project. Please let me know what the community thinks. >>> >> _______________________________________________ >> odf-discuss mailing list >> odf-discuss@opendocumentfellowship.com >> http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss >> >> _______________________________________________ >> odf-discuss mailing list >> odf-discuss@opendocumentfellowship.com >> http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss >> >> > > > -- J. David Ib??ez Itaapy Tel +33 (0)1 42 23 67 45 9 rue Darwin, 75018 Paris Fax +33 (0)1 53 28 27 88 From jza at openoffice.org Wed Jul 15 04:43:48 2009 From: jza at openoffice.org (Alexandro Colorado) Date: Wed Jul 15 04:43:51 2009 Subject: [odf-discuss] Starting the project ODFkit In-Reply-To: <4A5D90B2.90200@itaapy.com> References: <497b733b0907130815o3c4b2d8aofb8d88dd34e40e22@mail.gmail.com> <4A5D90B2.90200@itaapy.com> Message-ID: <497b733b0907150143k3ab59478je82809f12e31c5d4@mail.gmail.com> Thanks David. So how can we go about it to set up the project in the OpenDocument Fellowship mailinglist. That way we can get the rest of the group communicating with each other. We dont want to do a OOo or KOffice mailing list since this is mostly an ODF project. Who should I talk with about getting access to a mailing list for the project? On Wed, Jul 15, 2009 at 10:17 AM, "J. David Ib??ez" wrote: > > You may be interested in the LPod project: > > http://lpod-project.org/ > > Its main deliverable would be an specification that could be implemented > in any language. There will be a reference implementation in Python, > and other two alternative implementations in Perl and Ruby. > > To have a C++ implementation would be cool, the three above could be > reduced to wrappers. > > The project is leaded by Jean-Marie Gouarn?, who previously developed > OpenOffice::OODoc, a mature and widely used tool in Perl to do the same > thing. > > > > Alexandro Colorado wrote: >> Well the idea is not even to render ODF, nor is to make any derivative >> of Koffice. In all it would be more like ODFpy but implemented on C++. >> Taking the advantage of compiled language to deliver the performance >> for processing large pools of documents. >> >> The first stage is just having a CLI that can send the document >> content to STOUT and is able to catch areas like metadata, content, >> style, etc. >> >> Second stage would be to do transformations. Simple editing could be >> possible at this stage since we deal with writing and generating ODF. >> >> Third is to make it fast, and also make it so it can be flexible >> enough to enhance commands like "less" to do things similar to what it >> do to PDF. >> >> The idea basically is to bring ODF to the commandline, to make it easy >> to implement on any distro/OS and to make it accessible for scripting >> or programming solutions. Is very lowlevel but designed to make it >> extendable under different presentation layers, API, ABI and/or >> Toolkits that wrap around it to create different applications. >> >> The challenges that we want to solve is issues like legacy of ODF >> schemas from 1.0 1.1 as well as make it easy and small to port to >> small computers or just create very portable software under different >> technologies. >> >> On Mon, Jul 13, 2009 at 3:13 PM, S?ren Roug wrote: >>> Yes, I was wondering about the same thing. As far as I understand, KDE can use KOffice as a KPart to display ODF files. Is this a suggestion to reimplement KOffice? >>> >>> There is a development list called odf-devel@opendocumentfellowship.com, which might be more appropriate when the talk turns to software design. >>> >>> S?ren Roug >>> >>> -----Original Message----- >>> From: odf-discuss-bounces@opendocumentfellowship.com [mailto:odf-discuss-bounces@opendocumentfellowship.com] On Behalf Of robert_weir@us.ibm.com >>> Sent: 13 July 2009 15:51 >>> To: jza@openoffice.org; ODF Discussion List >>> Subject: Re: [odf-discuss] Starting the project ODFkit >>> >>> What would be the functionality of an ODFkit? Would this be a read-only >>> document renderer? Or would it having editing capabilities as well? >>> >>> -Rob >>> >>> odf-discuss-bounces@opendocumentfellowship.com wrote on 07/13/2009 >>> 07:43:10 AM: >>> >>>> Hi list, during the past Guakademy (Desktop Summit) some members of >>>> the KDE team and myself got together to study the possibility of >>>> having an ODFkit inspired by the lights of webkit with portability and >>>> scalability in mind. >>>> >>>> The project in itself is to produce an engine that can fetch and >>>> process opendocuments with a pluggable platform similar to webkit >>>> engine which is abstracted from the toolkits and application level >>>> layers. >>>> >>>> ODFkit should also help standarize on the ODF 1.2 schema for software >>>> developers and will make it simpler to develop applications on top of >>>> it. >>>> >>>> So we are looking for a mailing list to coordinate all the team and >>>> thought about opendocument fellowship as a great place to set the >>>> project. Please let me know what the community thinks. >>>> >>> _______________________________________________ >>> odf-discuss mailing list >>> odf-discuss@opendocumentfellowship.com >>> http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss >>> >>> _______________________________________________ >>> odf-discuss mailing list >>> odf-discuss@opendocumentfellowship.com >>> http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss >>> >>> >> >> >> > > > -- > J. David Ib??ez > Itaapy Tel +33 (0)1 42 23 67 45 > 9 rue Darwin, 75018 Paris Fax +33 (0)1 53 28 27 88 > -- Alexandro Colorado OpenOffice.org Español IM: jza@jabber.org From s.marechal at jejik.com Wed Jul 15 04:52:03 2009 From: s.marechal at jejik.com (Sander Marechal) Date: Wed Jul 15 05:05:09 2009 Subject: [odf-discuss] Starting the project ODFkit In-Reply-To: <4A5D90B2.90200@itaapy.com> References: <497b733b0907130815o3c4b2d8aofb8d88dd34e40e22@mail.gmail.com> <4A5D90B2.90200@itaapy.com> Message-ID: <4A5D98B3.1060204@jejik.com> J. David Ib??ez wrote: > Its main deliverable would be an specification that could be implemented > in any language. There will be a reference implementation in Python, > and other two alternative implementations in Perl and Ruby. I really wish people would do reference implementations in plain C and apply some SWIG magic. C + SWIG is instant libraries for Perl, PHP, Python, Ruby, C#, LISP, Java, etcetera. C may be somewhat harder to write but I can't image doing in once in C (or C++) takes longer than doing three separate implementations in Python, Perl and Ruby. -- Sander Marechal From lars at umich.edu Wed Jul 15 05:21:25 2009 From: lars at umich.edu (Lars Nooden) Date: Wed Jul 15 05:29:40 2009 Subject: [odf-discuss] Starting the project ODFkit In-Reply-To: <497b733b0907130443g2509bc7bqa4d8d74543cca999@mail.gmail.com> References: <497b733b0907130443g2509bc7bqa4d8d74543cca999@mail.gmail.com> Message-ID: <4A5D9F95.7010901@umich.edu> Alexandro Colorado wrote: > So we are looking for a mailing list to coordinate all the team and > thought about opendocument fellowship as a great place to set the > project. Please let me know what the community thinks. +1 -- as long as the langauges used are FOSS. Regards -Lars From lars at umich.edu Wed Jul 15 05:27:18 2009 From: lars at umich.edu (Lars Nooden) Date: Wed Jul 15 05:36:08 2009 Subject: [odf-discuss] Starting the project ODFkit In-Reply-To: <497b733b0907150143k3ab59478je82809f12e31c5d4@mail.gmail.com> References: <497b733b0907130815o3c4b2d8aofb8d88dd34e40e22@mail.gmail.com> <4A5D90B2.90200@itaapy.com> <497b733b0907150143k3ab59478je82809f12e31c5d4@mail.gmail.com> Message-ID: <4A5DA0F6.8090103@umich.edu> Alexandro Colorado wrote: >... > So how can we go about it to set up the project in the OpenDocument > Fellowship mailinglist. That way we can get the rest of the group > communicating with each other. We dont want to do a OOo or KOffice > mailing list since this is mostly an ODF project. > > Who should I talk with about getting access to a mailing list for the project? I expect that would be Andy Trevor. IIRC Jean and I are moderators for the various Fellowship lists. Regards, -Lars From lars at umich.edu Wed Jul 15 05:38:50 2009 From: lars at umich.edu (Lars Nooden) Date: Wed Jul 15 05:38:22 2009 Subject: [odf-discuss] Starting the project ODFkit In-Reply-To: References: <497b733b0907130815o3c4b2d8aofb8d88dd34e40e22@mail.gmail.com> Message-ID: <4A5DA3AA.7020607@umich.edu> robert_weir@us.ibm.com wrote: > > ... > > Maybe an odf-sed that replaced content in a formatted ODF document > > would be useful? > > > > Maybe a command-line tool for combining, reordering, replacing > > slides in a presentation? The now defunct sgrep might be a starting point. It was able to do something like that that for single documents. ODF documents that are a single file might work with an unmodified sgrep. http://www.cs.helsinki.fi/u/jjaakkol/sgrepman.html http://www.cs.helsinki.fi/u/jjaakkol/sgrep.html Alternately, XLST. -Lars From jza at openoffice.org Wed Jul 15 06:05:54 2009 From: jza at openoffice.org (Alexandro Colorado) Date: Wed Jul 15 06:05:57 2009 Subject: [odf-discuss] Starting the project ODFkit In-Reply-To: <4A5D98B3.1060204@jejik.com> References: <497b733b0907130815o3c4b2d8aofb8d88dd34e40e22@mail.gmail.com> <4A5D90B2.90200@itaapy.com> <4A5D98B3.1060204@jejik.com> Message-ID: <497b733b0907150305k48ab46cet3b0d5b9676aa11a@mail.gmail.com> On Wed, Jul 15, 2009 at 10:52 AM, Sander Marechal wrote: > J. David Ib??ez wrote: >> Its main deliverable would be an specification that could be implemented >> in any language. There will be a reference implementation in Python, >> and other two alternative implementations in Perl and Ruby. > > I really wish people would do reference implementations in plain C and > apply some SWIG magic. C + SWIG is instant libraries for Perl, PHP, > Python, Ruby, C#, LISP, Java, etcetera. > > C may be somewhat harder to write but I can't image doing in once in C > (or C++) takes longer than doing three separate implementations in > Python, Perl and Ruby. > > -- > Sander Marechal At the begining I was a fan of doing it in C but for some various reasons that the Koffice people mentioned, it could roadblock portability. The advantage is that performance should be faster. I guess we can discuss this on the new ML. -- Alexandro Colorado OpenOffice.org Español IM: jza@jabber.org From jdavid at itaapy.com Wed Jul 15 06:15:22 2009 From: jdavid at itaapy.com (=?UTF-8?B?IkouIERhdmlkIEliw6HDsWV6Ig==?=) Date: Wed Jul 15 06:22:40 2009 Subject: [odf-discuss] Starting the project ODFkit In-Reply-To: <4A5D98B3.1060204@jejik.com> References: <497b733b0907130815o3c4b2d8aofb8d88dd34e40e22@mail.gmail.com> <4A5D90B2.90200@itaapy.com> <4A5D98B3.1060204@jejik.com> Message-ID: <4A5DAC3A.9040707@itaapy.com> It does make sense to start prototyping in a high level language like Python. In this particular project, the other two alternative implementations are developed by two different teams, because they want to do so. It is not worthless anyway, since it helps to validate the spec. Personally, I prefer C over C++ to write the real thing, but I can live with C++ Sander Marechal wrote: > J. David Ib??ez wrote: >> Its main deliverable would be an specification that could be implemented >> in any language. There will be a reference implementation in Python, >> and other two alternative implementations in Perl and Ruby. > > I really wish people would do reference implementations in plain C and > apply some SWIG magic. C + SWIG is instant libraries for Perl, PHP, > Python, Ruby, C#, LISP, Java, etcetera. > > C may be somewhat harder to write but I can't image doing in once in C > (or C++) takes longer than doing three separate implementations in > Python, Perl and Ruby. > -- J. David Ib??ez Itaapy Tel +33 (0)1 42 23 67 45 9 rue Darwin, 75018 Paris Fax +33 (0)1 53 28 27 88 From jza at openoffice.org Wed Jul 15 06:38:39 2009 From: jza at openoffice.org (Alexandro Colorado) Date: Wed Jul 15 06:38:43 2009 Subject: [odf-discuss] Starting the project ODFkit In-Reply-To: <4A5DAC3A.9040707@itaapy.com> References: <497b733b0907130815o3c4b2d8aofb8d88dd34e40e22@mail.gmail.com> <4A5D90B2.90200@itaapy.com> <4A5D98B3.1060204@jejik.com> <4A5DAC3A.9040707@itaapy.com> Message-ID: <497b733b0907150338x4dcf7221l1bc226cf3a4cc64a@mail.gmail.com> There is already a prototype of this development in ODFpy. However we want a faster library to process thousands of ODF from the server side. No we dont want to build the whole web stack, our goal is to focus on a library that could become an extension to cli apps, php, python etc. On Wed, Jul 15, 2009 at 12:15 PM, "J. David Ib??ez" wrote: > > It does make sense to start prototyping in a high level language like > Python. > > In this particular project, the other two alternative implementations > are developed by two different teams, because they want to do so. It > is not worthless anyway, since it helps to validate the spec. > > Personally, I prefer C over C++ to write the real thing, but I can live > with C++ > > > > Sander Marechal wrote: >> J. David Ib??ez wrote: >>> Its main deliverable would be an specification that could be implemented >>> in any language. There will be a reference implementation in Python, >>> and other two alternative implementations in Perl and Ruby. >> >> I really wish people would do reference implementations in plain C and >> apply some SWIG magic. C + SWIG is instant libraries for Perl, PHP, >> Python, Ruby, C#, LISP, Java, etcetera. >> >> C may be somewhat harder to write but I can't image doing in once in C >> (or C++) takes longer than doing three separate implementations in >> Python, Perl and Ruby. >> > > > -- > J. David Ib??ez > Itaapy Tel +33 (0)1 42 23 67 45 > 9 rue Darwin, 75018 Paris Fax +33 (0)1 53 28 27 88 > _______________________________________________ > odf-discuss mailing list > odf-discuss@opendocumentfellowship.com > http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss > > -- Alexandro Colorado OpenOffice.org Español IM: jza@jabber.org From s.marechal at jejik.com Wed Jul 15 20:47:21 2009 From: s.marechal at jejik.com (Sander Marechal) Date: Wed Jul 15 20:47:28 2009 Subject: [odf-discuss] Starting the project ODFkit In-Reply-To: <4A5DAC3A.9040707@itaapy.com> References: <497b733b0907130815o3c4b2d8aofb8d88dd34e40e22@mail.gmail.com> <4A5D90B2.90200@itaapy.com> <4A5D98B3.1060204@jejik.com> <4A5DAC3A.9040707@itaapy.com> Message-ID: <4A5E7899.2000004@jejik.com> J. David Ib??ez wrote: > It does make sense to start prototyping in a high level language like > Python. True. And when the prototyping is done, port to C. > In this particular project, the other two alternative implementations > are developed by two different teams, because they want to do so. It > is not worthless anyway, since it helps to validate the spec. I didn't mean to imply it was worthless :-) > Personally, I prefer C over C++ to write the real thing, but I can live > with C++ SWIG works with C++ too, so I'd be happy with that as well. The main advantage of C or C++ with SWIG is that you can support all the different languages with a single library. That means only one place to fix bugs or change things and all programming languages benefit. But anyway, this sort of discussion is probably best reserved for their new mailinglist. @Alexandro: Please do post in this thread the location of your new mailinglist. -- Sander Marechal From s.marechal at jejik.com Thu Jul 16 08:51:40 2009 From: s.marechal at jejik.com (Sander Marechal) Date: Thu Jul 16 08:51:50 2009 Subject: [odf-discuss] Help translate Officeshots to your language Message-ID: <4A5F225C.9030102@jejik.com> Hello all, I just sent the below message to the Officeshots mailinglist. When I made the Officeshots announcement a few months ago on this mailinglist there was some discussion about i18n and l10n so I am sending it here as well. ==== Original message ==== I have finished setting up the internationalisation and localisation frameworks for Officeshots. If you want, you can now help to translate Officeshots to your own language. Translating Officeshots can be done through Pootle. You can find the Officeshots Pootle server at this address: http://lang.officeshots.org Before you can translate Officeshots you will need to register there for an account. After that you can start translating. As you can see, there are almost no languages configured yet in Pootle. The reason is that the CakePHP framework on which Officeshots runs has a different locale structure than what Pootle expects. This means I need to add every language by hand. If you want to start working on a new language, please post to the Officeshots mailinglist and I will add the language to Pootle and to Officeshots. Also, translations made in Pootle are not automatically pushed to Subversion or to the running Officeshots instances (because of possible merge conflicts). If you need a quick sync or push of language files, please drop a line on the Officeshots mailinglist as well. Happy translating! -- Sander Marechal