Thread: [Embedlets-developer] RE: On with the quest!
Status: Alpha
Brought to you by:
tkosan
Menu
▾
▴
embedlets-developer
|
From: Ted K. <tk...@ya...> - 2003-01-28 10:58:17
|
Andrzej said: >Let's get on with the quest, shall we? Until today I was still unsure about whether or not we as a group were going to be able to agree enough to develop an Embedlet specification and reference implementation but, after the 'post fest' that occurred over the past 24 hours, any concerns I may have had have disappeared. ;-) It took me 5 solid hours to read through and absorb all the traffic that you guys generated (sheesh, was it a full moon or something!?) and there were a significant number of absolutely critical ideas that were submitted. What I would like to do is to go back through the posts, extract these critical ideas and then place them into one or more documents inside of the CVS. We can then use these ideas as the tentative founding guidelines for the Embedlets specification and the documents can be evolved as we move forward. I have found that sourceforge's CVS system seems to work very well with OpenOffice's XML file formats and I propose that we use these file formats for our development documents. At least one advantage that these file formats provide is the ability to save text, drawing and spreadsheet files in XML formats that can be easily transformed into HTML snapshots for publishing on the website. Does anyone have problems with this proposal? Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Brill P. <bri...@ro...> - 2003-01-28 17:36:56
|
Yes... I don't use OpenOffice. What's wrong with plain text? - Brill Pappin Rogue Robotics www.roguerobotics.com ----- Original Message ----- From: "Ted Kosan" <tk...@ya...> To: <emb...@li...> Sent: Tuesday, January 28, 2003 5:58 AM Subject: [Embedlets-developer] RE: On with the quest! > Andrzej said: > > >Let's get on with the quest, shall we? > > Until today I was still unsure about whether or not we as a group were going to > be able to agree enough to develop an Embedlet specification and reference > implementation but, after the 'post fest' that occurred over the past 24 hours, > any concerns I may have had have disappeared. ;-) > > It took me 5 solid hours to read through and absorb all the traffic that you > guys generated (sheesh, was it a full moon or something!?) and there were a > significant number of absolutely critical ideas that were submitted. > > What I would like to do is to go back through the posts, extract these critical > ideas and then place them into one or more documents inside of the CVS. We can > then use these ideas as the tentative founding guidelines for the Embedlets > specification and the documents can be evolved as we move forward. > > > I have found that sourceforge's CVS system seems to work very well with > OpenOffice's XML file formats and I propose that we use these file formats for > our development documents. At least one advantage that these file formats > provide is the ability to save text, drawing and spreadsheet files in XML > formats that can be easily transformed into HTML snapshots for publishing on > the website. > > Does anyone have problems with this proposal? > > > Ted > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Ted K. <tk...@ya...> - 2003-01-28 18:54:02
|
Brill, > What's wrong with plain text? No font control, no formatting, no universal end-of-line marker standard, no automatic page numbers, no automatic headers and footers, no spell checking, no spreadsheets, no editable diagrams. Every time we publish a new version of the spec I do not want to have to copy a .txt version of it into a formatting tool. It seems much cleaner to me to just put it under format control from day one with diagrams etc. constantly in place. Aside from this, the main reason I proposed openoffice was that it uses XML file formats that work well in a CVS (CVS does not like binary file formats). Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Brill P. <bri...@ro...> - 2003-01-28 22:17:27
|
> > What's wrong with plain text? > > No font control, no formatting, no universal end-of-line marker standard, no > automatic page numbers, no automatic headers and footers, no spell checking, no > spreadsheets, no editable diagrams. Ok, HTML then ;) I bet OpenOffice can edit HTML in a WYSIWYG, which word can also do. Not only that, but it means the docs can be dropped on the server for easy display. Or maybe us a Wiki... I can set up one there for light duty... > Every time we publish a new version of the spec I do not want to have to copy a > .txt version of it into a formatting tool. It seems much cleaner to me to just > put it under format control from day one with diagrams etc. constantly in > place. > > Aside from this, the main reason I proposed openoffice was that it uses XML > file formats that work well in a CVS (CVS does not like binary file formats). you have to mark a file as binary instead of text when you check it into CVS (do it all the time with no problems)... as for text, CVS automatically converts the EOL char for you, to the platform its being checked out to (if its checked in as text). - Brill |
|
From: Ted K. <tk...@ya...> - 2003-01-29 05:26:21
|
Brill, > you have to mark a file as binary instead of text when you check it into CVS > (do it all the time with no problems)... Well yes, one can check binary files into CVS but they are just stored there and are not under version control. If two people change part of a binary file and then submit the changes, CVS can not tell whether there was a collision or not. > Ok, HTML then ;) I bet OpenOffice can edit HTML in a WYSIWYG, which word can > also do. Not only that, but it means the docs can be dropped on the server > for easy display. What about spread sheets and diagrams? Beyond this, HTML is a great presentation technology but I think that XML is a much more flexible technology to place editable content into. Do you know of any better XML file formats than the OpenOffice XML file format that is designed for office-suite class document storage? Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Brill P. <bri...@ro...> - 2003-01-29 05:45:30
|
The problem is not that its an XML file format... the problem is that in order to use it, I have to install and use a not-insignificant application that I have no interest in using (though I'm sure its a great app). So, that's why I suggest HTML. If formatting is essential, doesn't OpenOffice have a WYSIWYG editor like FrontPage or something? The current version of FrontPage is actually pretty good... not a lot of garbage... surely OpenOffice has something like that? - Brill Pappin Rogue Robotics www.roguerobotics.com ----- Original Message ----- From: "Ted Kosan" <tk...@ya...> To: <emb...@li...> Sent: Wednesday, January 29, 2003 12:26 AM Subject: [Embedlets-developer] Re: OpenOffice > Brill, > > > you have to mark a file as binary instead of text when you check it into CVS > > (do it all the time with no problems)... > > Well yes, one can check binary files into CVS but they are just stored there > and are not under version control. If two people change part of a binary file > and then submit the changes, CVS can not tell whether there was a collision or > not. > > > > > Ok, HTML then ;) I bet OpenOffice can edit HTML in a WYSIWYG, which word can > > also do. Not only that, but it means the docs can be dropped on the server > > for easy display. > > What about spread sheets and diagrams? Beyond this, HTML is a great > presentation technology but I think that XML is a much more flexible technology > to place editable content into. > > Do you know of any better XML file formats than the OpenOffice XML file format > that is designed for office-suite class document storage? > > > Ted > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Ted K. <tk...@ya...> - 2003-01-29 06:28:17
|
Brill, > The problem is not that its an XML file format... the problem is that in > order to use it, I have to install and use a not-insignificant application > that I have no interest in using (though I'm sure its a great app). Well, you know, it pretty much installs itself and if one is mostly only going to be typing text and leaving the formatting chores up to others then the learning curve is very short. You should be up and running within 20 minutes max. > So, that's why I suggest HTML. If formatting is essential, doesn't > OpenOffice have a WYSIWYG editor like FrontPage or something? > The current version of FrontPage is actually pretty good... not a lot of > garbage... surely OpenOffice has something like that? Sure, OpenOffice has a WYSIWYG editor but any WYSIWYG editors are going to fight each other to have the document's tag selection and formatting placed in its own pet style. I have tried this and it does not work well at all. Here is my perspective. I have downloaded and read through a number of specifications like the Servlet spec, the JavaBeans spec, the EJB spec and most recently the new Sun ACE spec. Most specifications contain a ton of typing, formatting, sectioning and sub-sectioning. A number of them also contain a significant number of diagrams. Since I bet I have more free time than anyone else on the list (you guys have no idea how much free time a university faculty member has!) the responsibility for typing in, formatting, reformatting and maintaining the specifications we generate will probably fall on my shoulders. As I analyze this I am not at all looking forward to the prospect of having to do this work using raw text or even HTML. Beyond this, if our core working documents are in raw text or HTML I also do not want to have to go through the work of copying them into an office suite for formatting every time a new version of the specification is released. I am kind of stuck on this issue right now because it looks like we are within a week or so of actually starting work on developing the specification documents and I would personally rather resolve this issue sooner rather than later. What do other people on the list think? Are we going to encode the core specification documents inside of a modern, open, XML based office suite format or are we going to chisel it into clay tablets? ;-) Again, if everone mostly leaves the formatting chores up to me, entering and editing text using OpenOffice is quite easy. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Jac K. <j.k...@th...> - 2003-01-29 07:02:52
|
On Tue, 28 Jan 2003, Ted Kosan wrote: > What do other people on the list think? Are we going to encode the core > specification documents inside of a modern, open, XML based office suite > format or are we going to chisel it into clay tablets? ;-) How about using DocBook? Still XML but everyone would be able to use their own 'pet' editor. And using the right tools it can be published in at least HTML, PDF, RTF. Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Ted K. <tk...@ya...> - 2003-01-29 07:09:26
|
Jac, > How about using DocBook? Still XML but everyone would be able to use their > own 'pet' editor. And using the right tools it can be published in at > least HTML, PDF, RTF. I think DocBook might be very promising. Do you have any favorite editors that I might look at first to get me started? Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Christopher S. <cs...@oo...> - 2003-01-29 07:30:44
|
Just a queation on OfficeSuite XML format - I do not see this in the docs that have been posted, they are all binary format. Am I missing something? -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Jac Kersing Sent: Tuesday, January 28, 2003 11:11 PM To: emb...@li... Subject: Re: [Embedlets-developer] Re: OpenOffice On Tue, 28 Jan 2003, Ted Kosan wrote: > What do other people on the list think? Are we going to encode the core > specification documents inside of a modern, open, XML based office suite > format or are we going to chisel it into clay tablets? ;-) How about using DocBook? Still XML but everyone would be able to use their own 'pet' editor. And using the right tools it can be published in at least HTML, PDF, RTF. Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Ted K. <tk...@ya...> - 2003-01-29 07:49:45
|
Christopher, > Just a queation on OfficeSuite XML format - I do not see this in the docs > that have been posted, they are all binary format. Am I missing something? By 'OfficeSuite' do you mean 'OpenOffice' or some other office suite? Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Christopher S. <cs...@oo...> - 2003-01-29 18:26:21
|
My apologies OpenOffice 1.0.2 - how do you get XML format documents out of the package? -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Ted Kosan Sent: Tuesday, January 28, 2003 11:50 PM To: emb...@li... Subject: [Embedlets-developer] Re: OpenOffice Christopher, > Just a queation on OfficeSuite XML format - I do not see this in the docs > that have been posted, they are all binary format. Am I missing something? By 'OfficeSuite' do you mean 'OpenOffice' or some other office suite? Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Ted K. <tk...@ya...> - 2003-01-29 22:15:33
|
Christopher (or Chris?) >how do you get XML format documents out of > the package? They are zipped! Create a short text document, save it and then unzip it! It is very cool! Here is where to get all the OpenOffice XML documentation: xml.openoffice.org Ted --- Christopher Smith <cs...@oo...> wrote: > My apologies OpenOffice 1.0.2 - how do you get XML format documents out of > the package? > > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of Ted > Kosan > Sent: Tuesday, January 28, 2003 11:50 PM > To: emb...@li... > Subject: [Embedlets-developer] Re: OpenOffice > > > Christopher, > > > Just a queation on OfficeSuite XML format - I do not see this in the docs > > that have been posted, they are all binary format. Am I missing something? > > By 'OfficeSuite' do you mean 'OpenOffice' or some other office suite? > > > Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Brill P. <bri...@ro...> - 2003-01-29 16:03:00
|
Hey, looks interesting... I'd be into that I think... do you have some preferred apps we can evaluate? - Brill Pappin Rogue Robotics www.roguerobotics.com ----- Original Message ----- From: "Jac Kersing" <j.k...@th...> To: <emb...@li...> Sent: Wednesday, January 29, 2003 2:11 AM Subject: Re: [Embedlets-developer] Re: OpenOffice > On Tue, 28 Jan 2003, Ted Kosan wrote: > > > What do other people on the list think? Are we going to encode the core > > specification documents inside of a modern, open, XML based office suite > > format or are we going to chisel it into clay tablets? ;-) > > How about using DocBook? Still XML but everyone would be able to use their > own 'pet' editor. And using the right tools it can be published in at > least HTML, PDF, RTF. > > Regards, > > Jac > > -- > Jac Kersing Technical Consultant The-Box Development > j.k...@th... http://www.the-box.com > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Jac K. <j.k...@th...> - 2003-02-01 21:30:22
|
On Wed, 29 Jan 2003, Brill Pappin wrote: > > How about using DocBook? Still XML but everyone would be able to use their > > own 'pet' editor. And using the right tools it can be published in at > > least HTML, PDF, RTF. > Hey, looks interesting... I'd be into that I think... do you have some > preferred apps we can evaluate? Take a look at XML Editor and FO Convertor at www.xmlmind.com. To learn more www.docbook.org, it has the "Complete reference" on-line, (and the docbook sources of this O'Reilly book as well) Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Nicola K. B. <nic...@ap...> - 2003-02-01 22:47:30
|
Jac Kersing wrote: > On Wed, 29 Jan 2003, Brill Pappin wrote: > > >>>How about using DocBook? Still XML but everyone would be able to use their >>>own 'pet' editor. And using the right tools it can be published in at >>>least HTML, PDF, RTF. > > >>Hey, looks interesting... I'd be into that I think... do you have some >>preferred apps we can evaluate? > > > Take a look at XML Editor and FO Convertor at www.xmlmind.com. To learn > more www.docbook.org, it has the "Complete reference" on-line, (and the > docbook sources of this O'Reilly book as well) Take a look at this too. http://xml.apache.org/forrest/ It can now use plain html too or wiki syntax. It renders svg to png too, makes pdfs and is completely skinnable. Ok, it's a shameless plug, I'm a developer there ;-P -- Nicola Ken Barozzi nic...@ap... - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- |
|
From: Brill P. <bri...@ro...> - 2003-02-02 10:27:28
|
Hey, cool... Really a Wiki is the way we want to go, but I think it would require hosting on someones server... > Take a look at this too. > http://xml.apache.org/forrest/ > > It can now use plain html too or wiki syntax. > It renders svg to png too, makes pdfs and is completely skinnable. > Ok, it's a shameless plug, I'm a developer there ;-P Hey, it does look good... have you guys got a desktop app for it yet (or will you)? Guess I could build one... but I'm so swamped I'd get it working, then leave you all to deal with it ;) - Brill Pappin |
|
From: Nicola K. B. <nic...@ap...> - 2003-02-02 10:44:46
|
Brill Pappin wrote: > Hey, cool... > > Really a Wiki is the way we want to go, but I think it would require hosting > on someones server... It can be done on Sourceforge too. I use a simple file-based one: http://www.krysalis.org/cgi-bin/krywiki.pl >>Take a look at this too. >>http://xml.apache.org/forrest/ >> >>It can now use plain html too or wiki syntax. >>It renders svg to png too, makes pdfs and is completely skinnable. > >>Ok, it's a shameless plug, I'm a developer there ;-P > > > Hey, it does look good... have you guys got a desktop app for it yet (or > will you)? Guess I could build one... but I'm so swamped I'd get it working, > then leave you all to deal with it ;) ;-) No desktop app, and none planned. But you can use any html editor ATM. Probably we'll support Openoffice too in the future, we'll see. -- Nicola Ken Barozzi nic...@ap... - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- |
|
From: Ted K. <tk...@ya...> - 2003-02-02 13:05:34
|
Nicola, > Take a look at this too. > http://xml.apache.org/forrest/ After spending some time studying the information on the Forrest site it does not take one long to see that the site does an exceptional job of marketing Forrest's virtues. In my opinion, wrapping the Embedlet project's documentation inside an XML file format was always a must but I had not given too much thought on how to make this information available to the public aside from placing periodic snapshots of it on a website or having them pull it from the CVS. If the periodic CVS snapshot technique is considered to be a country lane that can be used to publish CVS contents to the web, then in comparison Forrest appears to provide a 6 lane highway that can pump the contents in a CVS to the web in a wide variety of flexible formats on an on-demand basis. I also like Forrest's Documentation DTDs better than OpenOffice's DTDs because they appear to be optimized for use with software project documentation while OpenOffice's DTDs are much more generic. Finally, I had been wondering how we were going to put together the Embedlets main website and how much of a pain it was going to be to maintain it. If we decide to go with something like Forrest then a lot of hard work has already been done for us and we would have a much higher quality website on day one then we could ever achieve with a home grown website. What do other people think of the possibility of using Forrest for our documentation needs? Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Jac K. <j.k...@th...> - 2003-02-02 13:49:17
|
On Sun, 2 Feb 2003, Ted Kosan wrote: > What do other people think of the possibility of using Forrest for our > documentation needs? First impression, very nice. However I do have some questions: - Is Forrest able to handle large multi chapter documents? All the webpages have the 'printer friendly' button, but that's only that single page and I would like our pdfs to contain all chapters, not one pdf for each chapter. - What would we use to edit the documents and diagrams? I'm not particulary fond of having to edit XML files when creating documentation. The tags tend to distract from the contents... (would that be one of the reasons the word userbase outnumbers the TeX [or insert your favorite here] userbase??) BTW, my second concern is valid for docbook as well. XmlMind XML Editor enables more or less wysiwyg editing, but it's not OpenOffice. The options so far are (if I remember correctly): * OpenOffice + free full blown office suite with editor and graphics module + wysiwyg = XML based storage, however with proprietary DTD - large (a lot of disk space and not very fast) - no pdf creation without commercial plugins (afaik) * DocBook + XML standard documents use whatever editor you like + output to pdf, html, rtf and more - no real wysiwyg tools for editing - no standardized graphics input format * Forrest + XML documents + ouput to HTML and pdf + standard graphics format???? - no wysiwyg editors Please help by adding to/correcting this list... Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Nicola K. B. <nic...@ap...> - 2003-02-02 14:46:05
|
Jac Kersing wrote:
> On Sun, 2 Feb 2003, Ted Kosan wrote:
>
>>What do other people think of the possibility of using Forrest for our
>>documentation needs?
>
> First impression, very nice. However I do have some questions:
> - Is Forrest able to handle large multi chapter documents? All the
> webpages have the 'printer friendly' button, but that's only that single
> page and I would like our pdfs to contain all chapters, not one pdf for
> each chapter.
This is a feature that's been worked upon.
> - What would we use to edit the documents and diagrams? I'm not
> particulary fond of having to edit XML files when creating documentation.
> The tags tend to distract from the contents... (would that be one of the
> reasons the word userbase outnumbers the TeX [or insert your favorite
> here] userbase??)
>
> BTW, my second concern is valid for docbook as well. XmlMind XML Editor
> enables more or less wysiwyg editing, but it's not OpenOffice.
I understand this concern. Currently we support SVG for diagrams, and
Openoffice can
> The options so far are (if I remember correctly):
> * OpenOffice
> + free full blown office suite with editor and graphics module
> + wysiwyg
> = XML based storage, however with proprietary DTD
> - large (a lot of disk space and not very fast)
> - no pdf creation without commercial plugins (afaik)
> * DocBook
> + XML standard documents use whatever editor you like
> + output to pdf, html, rtf and more
> - no real wysiwyg tools for editing
> - no standardized graphics input format
> * Forrest
> + XML documents
> + ouput to HTML and pdf
> + standard graphics format????
> - no wysiwyg editors
>
> Please help by adding to/correcting this list...
There are errors in the above, because you are mixing tools that are not
the same thing.
- Openoffice here is a wordprocessor and a vector drawing program.
- Docbook is a file format
- Forrest is a publishing tool
One could use all of them if he wanted: people are working on a
OO->Docbook filter, and Forrest can quite easily work with DocBook.
Let's see if we can get the best of these tools:
Forrest as a publishing system has no rivals in the above comparison.
It can not publish sites that use these file formats:
- Forrest document DTD
- html
- wiki format
- simplified docbook (almost there)
- SVG (automatic rendering to SVG)
It has only one issue: no editor.
Solution: make Forrest accept openoffice files as a source of content.
Forrest is based on Cocoon, and with Apache Cocoon it's very easy to add
this kind of functionality.
The problem of the CVS diffs remains though, since diffing binaries file
is not possible, and diffs of the xml format of OpenOffice sucks badly.
Currently Forrest is able to use html files as input, so using a simple
html editor is another option. The html DTD doesn't suck that much, and
decent editors make decent html source.
Basically, it all boils down to the editor and the format it saves in.
AbiWord for example saves in docbook, but deosnt' have sections and no
tables :-(
Any further suggestion about editors and formats they save in?
--
Nicola Ken Barozzi nic...@ap...
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
|
|
From: Jac K. <j.k...@th...> - 2003-02-02 17:29:03
|
On Sun, 2 Feb 2003, Nicola Ken Barozzi wrote: > This is a feature that's been worked upon. Any information on when it will be ready? > There are errors in the above, because you are mixing tools that are not > the same thing. That's intentionaly, it provokes response :-) > - Openoffice here is a wordprocessor and a vector drawing program. > - Docbook is a file format > - Forrest is a publishing tool > > One could use all of them if he wanted: people are working on a > OO->Docbook filter, and Forrest can quite easily work with DocBook. OO is not able to handle DocBook and a filter will never be able to do a perfect job. To write documents with a DocBook DTD one needs an editor accepting a generic DTD or a specialized DocBook editor. > Forrest as a publishing system has no rivals in the above comparison. ... > - simplified docbook (almost there) Ok, that sounds good, any ETA? Because we're looking at a lot of 'not yet ready' components already and I'm hestitant to start using tools that have not been proven yet. This project is challenging without our need to worry about tools. > - SVG (automatic rendering to SVG) And rendering SVG to PDF???? > It has only one issue: no editor. > Solution: make Forrest accept openoffice files as a source of content. > Forrest is based on Cocoon, and with Apache Cocoon it's very easy to add > this kind of functionality. That would require creating a translation for every OpenOffice tag to an equivalent tag for the publishing format. I'm not sure this is an efford we should start, writing this kind of xslt stylesheet is a project itself. > The problem of the CVS diffs remains though, since diffing binaries file > is not possible, and diffs of the xml format of OpenOffice sucks badly. That was to be expected. However, StarOffice includes functions to merge changes different people made into a master document. A quick search in the OpenOffice help suggests it is supported as well... (See help index: Version management) > Currently Forrest is able to use html files as input, so using a simple > html editor is another option. The html DTD doesn't suck that much, and > decent editors make decent html source. Not decent are: Word, Frontpage, MacroMedia tools and a lot more. Just tried the OpenOffice (StarOffice 6 in my case) html mode and it actually didn't do as badly as I feared it would. The html code was reasonable clean and might even conform to a DTD. :-) > Basically, it all boils down to the editor and the format it saves in. > AbiWord for example saves in docbook, but deosnt' have sections and no > tables :-( An editor without tables and sections won't work. Scrap Abiword, at least for the moment. > Any further suggestion about editors and formats they save in? Nope, may-be one of the other participants???????? Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Nicola K. B. <nic...@ap...> - 2003-02-02 18:47:28
|
Jac Kersing wrote:
> On Sun, 2 Feb 2003, Nicola Ken Barozzi wrote:
>
>>This is a feature that's been worked upon.
>
> Any information on when it will be ready?
In opensource? A date? ;-)
If it's an important point for you, I'll bump it's priority.
>>There are errors in the above, because you are mixing tools that are not
>>the same thing.
>
> That's intentionaly, it provokes response :-)
;-P
That's a typical opensource mantra:
- bad ideas with bad code don't attract anybody.
- good ideas with good code attract users.
- good ideas with bad code attract developers.
>> - Openoffice here is a wordprocessor and a vector drawing program.
>> - Docbook is a file format
>> - Forrest is a publishing tool
>>
>>One could use all of them if he wanted: people are working on a
>>OO->Docbook filter, and Forrest can quite easily work with DocBook.
>
> OO is not able to handle DocBook and a filter will never be able to do a
> perfect job. To write documents with a DocBook DTD one needs an editor
> accepting a generic DTD or a specialized DocBook editor.
I agree.
>>Forrest as a publishing system has no rivals in the above comparison.
>
> ...
>
>> - simplified docbook (almost there)
>
> Ok, that sounds good, any ETA? Because we're looking at a lot of 'not yet
> ready' components already and I'm hestitant to start using tools that
> have not been proven yet. This project is challenging without our need to
> worry about tools.
I'd not suggest to use Docbook unless there's a compelling reason. The
stylesheet is there, but not yet tested extensively.
As for Forrest, the tool is really Apache Cocoon, that is more than
proven. Forrest is an application built on Cocoon, and used to build
many Apache websites.
>> - SVG (automatic rendering to SVG)
>
> And rendering SVG to PDF???
In the pages they can automatically render as PNG.
FOP is capable of rendering to PDF too IIRC, I can enable it.
>>It has only one issue: no editor.
>>Solution: make Forrest accept openoffice files as a source of content.
>>Forrest is based on Cocoon, and with Apache Cocoon it's very easy to add
>>this kind of functionality.
>
> That would require creating a translation for every OpenOffice tag to an
> equivalent tag for the publishing format. I'm not sure this is an efford
> we should start, writing this kind of xslt stylesheet is a project itself.
Not really. I did it for HTML and it's quite easy. The fact is that we
don't support every HTML tag. We only support the semantical ones, not
the presentational ones. Same would be with OO.
>>The problem of the CVS diffs remains though, since diffing binaries file
>>is not possible, and diffs of the xml format of OpenOffice sucks badly.
>
> That was to be expected. However, StarOffice includes functions to merge
> changes different people made into a master document. A quick search in
> the OpenOffice help suggests it is supported as well... (See help index:
> Version management)
I find CVS diffs to be really better because of the way CVS works with
multiple committs, merges, etc.
>>Currently Forrest is able to use html files as input, so using a simple
>>html editor is another option. The html DTD doesn't suck that much, and
>>decent editors make decent html source.
>
> Not decent are:
> Word, Frontpage, MacroMedia tools and a lot more.
>
> Just tried the OpenOffice (StarOffice 6 in my case) html mode and it
> actually didn't do as badly as I feared it would. The html code was
> reasonable clean and might even conform to a DTD. :-)
For Forrest consumption it doesn't need to conform, we pass it through
jtidy.
>>Basically, it all boils down to the editor and the format it saves in.
>>AbiWord for example saves in docbook, but deosnt' have sections and no
>>tables :-(
>
> An editor without tables and sections won't work. Scrap Abiword, at least
> for the moment.
I reckoned.
>>Any further suggestion about editors and formats they save in?
I use Mozilla composer, btw.
> Nope, may-be one of the other participants????????
--
Nicola Ken Barozzi nic...@ap...
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
|
|
From: Jac K. <j.k...@th...> - 2003-02-03 20:03:08
|
On Sun, 2 Feb 2003, Nicola Ken Barozzi wrote: > In opensource? A date? ;-) It happens, sometimes. And in a few cases projects actualy meet those deadlines :-) > If it's an important point for you, I'll bump it's priority. Not at this moment. Might become one if we start using Forrest for documentation. > In the pages they can automatically render as PNG. > FOP is capable of rendering to PDF too IIRC, I can enable it. FOP does PDF and if the input is well a well defined (broken) subset of FO it even works well... > I find CVS diffs to be really better because of the way CVS works with > multiple committs, merges, etc. Have you tested OpenOffice merging? Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Nicola K. B. <nic...@ap...> - 2003-02-03 23:02:44
|
Jac Kersing wrote:
,,,
>>I find CVS diffs to be really better because of the way CVS works with
>>multiple committs, merges, etc.
>
> Have you tested OpenOffice merging?
I mean in a shared environment. Are you able with OO to browse the
previous diffs in time, or branch? Simple merging is just one aspect.
--
Nicola Ken Barozzi nic...@ap...
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
|