Re: [DOCS] Switching to XML
Joshua D. Drake a écrit : > On Fri, 2006-12-08 at 21:58 +0100, Peter Eisentraut wrote: >> Joshua D. Drake wrote: >>> You can create, edit, convert, save, and open docbook xml in >>> OpenOfice.org. >> Sure, there are more editing options with DocBook XML. No one disputes >> that. But the question at hand was about processing the DocBook. > > Yes which is generated from our use of SGML which is the core of this > problem and the core of the question as a whole. > > SGML is making working with the documentation *harder*. > +1 > We have people that *DO NOT* contribute because of this SGML > requirement. They have what I consider extremely valid reasons, namely > it is dumb to require a writer to use emacs or write tags explictly. > > Hell, the only reason I have even bothered to contribute what little I > have to the docs is because I wrote a book in SGML, thus it is a no > brainer to me. Others aren't so tortured as to have done the same. > I'm not so sure it will help you find more contributors. I'm part of a project which aims to translate HOWTO from TLDP. They don't find contributors and we too have really hard times to find contributors despite the fact we try to only use DocBook XML (TLDP use DocBook SGML, DocBook XML and LinuxDoc formats). Did you try to use OpenOffice.org with DocBook ? I tried once and it was a complete disaster. But it was a long time ago. I will try again this week-end. > There is a long standing support within the community to move to XML > including: > > Josh Berkus > Josh Drake > Robert Treat > Andrew Dunslane > David Blewett > David Fetter > Devrim Gunduz > Darcy Buskermolen > > And that is just from #postgresql > > The french team also uses Docbook XML and they can generate a PDF in 30 > minutes... it takes us DAYS because of the SGML. > In fact, we need 15 minutes to build HTML files and 10 minutes to build PDF file. To be completely honest, I don't seem to be able to build PDF file for 8.2.0 release. I must have made a mistake (or perhaps a lot of :) ). Regards. -- Guillaume. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-www] [DOCS] 8.2.0 pdf
Hi Jim, On Fri, 2006-12-08 at 18:07 -0800, Jim Nasby wrote: > > http://www.gunduz.org/postgresql/texmf.cnf > > ISTM that info should be in CVS, maybe in the README. I was thinking something same. But I'd like to wait until I build a fine PDF. > Also, if PDF indexes depend on HTML, perhaps HTML should be a > dependency of PDF in the Makefile. Agreed... Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ signature.asc Description: This is a digitally signed message part
Re: [DOCS] Switching to XML
On Fri, 2006-12-08 at 13:26 -0800, Joshua D. Drake wrote: > Yes which is generated from our use of SGML which is the core of this > problem and the core of the question as a whole. > > SGML is making working with the documentation *harder*. >From a total outsider's point of view I have to disagree. It took me a couple of minutes to figure out how to make the tiny change I did the other day by looking at the rest of the sgml (managed to get the diff the wrong way around but not the sgml :/). > We have people that *DO NOT* contribute because of this SGML > requirement. They have what I consider extremely valid reasons, namely > it is dumb to require a writer to use emacs or write tags explictly. Again would have to disagree - surely if someone really wants to contribute they could provide their input in plain text, and someone on the list could then integrate those contribs. > Hell, the only reason I have even bothered to contribute what little I > have to the docs is because I wrote a book in SGML, thus it is a no > brainer to me. Others aren't so tortured as to have done the same. I would hate to hand edit the stuff generated by something like OpenOffice.org. > There is a long standing support within the community to move to XML > including: > > Josh Berkus > Josh Drake > Robert Treat > Andrew Dunslane > David Blewett > David Fetter > Devrim Gunduz > Darcy Buskermolen > > And that is just from #postgresql > > The french team also uses Docbook XML and they can generate a PDF in 30 > minutes... it takes us DAYS because of the SGML. Here I agree - 30 minutes vs days is a good reason - as long as editing with an ascii editor is not taken away. -- Regards Theo ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [DOCS] Switching to XML
Joshua D. Drake wrote: > Further, here is a real world problem that our toolset creates... > > I take 5 minutes, change the stylesheet for SGML. I want to see what > my changes will look like... 3 days later, I will know. > > That is stupid. If it was XML, it would be 30 minutes. That is a > workable timeframe. I feel like I'm talkling to a wall here, but I'm going to say this one last time: Any processing toolchain that you can use with DocBook XML you can use with DocBook SGML and vice versa. If you know of a way to create a PDF off DocBook XML in 30 minutes, please tell us. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgsql-www] [DOCS] 8.2.0 pdf
Jim Nasby wrote: > Also, if PDF indexes depend on HTML, perhaps HTML should be a > dependency of PDF in the Makefile. By that logic, HTML should also depend on HTML. I don't know how people would like that. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-www] [DOCS] 8.2.0 pdf
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Jim Nasby wrote: >> Also, if PDF indexes depend on HTML, perhaps HTML should be a >> dependency of PDF in the Makefile. > By that logic, HTML should also depend on HTML. I don't know how people > would like that. The real point is that the "jade" step needs to be done twice to have up-to-date indexes. It makes sense not to force that for html, because we use html for proofing. But perhaps we ought to run jade twice in the Makefile rule for producing pdftex output? I see that the Makefile forces three runs of TeX for similar reasons (which is probably way more time than the jade part anyway). regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [DOCS] Switching to XML
Josh Berkus writes: > As I said then, this is absolutely untrue. OpenOffice.org, for example, > works with DocBook XML but not SGML. There are also a plethora of XML > editing and publishing tools which can been used for Docbook XML which > are not available for SGML. A simple look at this page: > http://wiki.docbook.org/topic/DocBookAuthoringTools > shows that there are more than twice as many authoring tools which > support only XML as support SGML -- and that most of the tools which > support SGML are out-of-maintenance. This is confusing authoring tools (ie, stuff for more or less WYSIWYG editing of the document source) with output generation tools. As for authoring tools, show me one that produces SGML or XML that's reasonably readable, and I might worry about allowing people to use it. Most of the ones I've seen would render the doc sources unreadable for anyone not using an authoring tool (possibly even the very same authoring tool). We are not going to move in that direction because it would piss off the people who do the bulk of the work now. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [DOCS] Switching to XML
>> The french team also uses Docbook XML and they can generate a PDF in 30
>> minutes... it takes us DAYS because of the SGML.
Has anyone looked into actually fixing the performance problem?
oprofile results for jade trying to produce tex output from our docs are
suggestive of a localized performance issue:
samples %symbol name
2082917 98.5829
OpenJade_DSSSL::PairNodeListObj::nodeListFirst(OpenJade_DSSSL::EvalContext&,
OpenJade_DSSSL::Interpreter&)
9713 0.4597
OpenJade_DSSSL::PairNodeListObj::nodeListRest(OpenJade_DSSSL::EvalContext&,
OpenJade_DSSSL::Interpreter&)
5019 0.2375 OpenJade_DSSSL::AppendSosofoObj::traceSubObjects(Collector&)
const
3571 0.1690 Collector::collect()
1938 0.0917 OpenJade_DSSSL::FlowObj::traceSubObjects(Collector&) const
I attached to the process with gdb and found it nested four thousand (!)
call levels deep in OpenJade_DSSSL::PairNodeListObj::nodeListFirst and
OpenJade_DSSSL::PairNodeListObj::nodeListRest calls. Meanwhile, looking
at the output-so-far-emitted makes me think it was working on a fairly
large example. The last little bit is:
{asis}\def\InputWhitespaceTreatment%
{preserve}}\Seq%
{}\Seq%
{}\endSeq{}/*
\Seq%
{}\endSeq{}~*~testlibpq2.c
\Seq%
{}\endSeq{}~*~~Test~of~the~asynchronous~notification~interface
\Seq%
{}\endSeq{}~*
\Seq%
{}\endSeq{}~*~Start~this~program,~then~from~psql~in~another~window~do
\Seq%
{}\endSeq{}~*~~~NOTIFY~TBL2;
\Seq%
{}\endSeq{}~*~Repeat~four~times~to~get~this~program~to~exit.
\Seq%
{}\endSeq{}~*
\Seq%
{}\endSeq{}~*~Or,~if~you~want~to~get~fancy,~try~this:
\Seq%
{}\endSeq{}~*~populate~a~database~with~th
What it looks like to me is that there is some bit of stupidity that is
producing a deeply nested list representation of a
section, probably one list level per character in the text, making the
runtime O(N^2) or worse in the length of the . (The
particular example it's stuck on here is about 10K characters.)
Since jade does not go into this kind of spiral when producing html
output from the same sources, I suggest that it's not jade's fault,
but rather crummy coding in the sgml-to-tex conversion scripts it's
using. I don't know enough about those to know where to look, but maybe
someone here does?
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [DOCS] Switching to XML
> > > Hell, the only reason I have even bothered to contribute what little I > > have to the docs is because I wrote a book in SGML, thus it is a no > > brainer to me. Others aren't so tortured as to have done the same. > > I would hate to hand edit the stuff generated by something like > OpenOffice.org. As would I. > > > > The french team also uses Docbook XML and they can generate a PDF in 30 > > minutes... it takes us DAYS because of the SGML. > > Here I agree - 30 minutes vs days is a good reason - as long as editing > with an ascii editor is not taken away. I would never expect to take editing away.. I personally would likely just use bluefish, not Openoffice. Sincerely, Joshua D. Drake > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [DOCS] Switching to XML
> If you know of a way to create a PDF off DocBook XML in 30 minutes, > please tell us. See the post on this thread from : Guillaume Lelarge 10 minutes to generate a pdf. Sincerely, Joshua D. Drake > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] Switching to XML
Joshua D. Drake wrote: > > If you know of a way to create a PDF off DocBook XML in 30 minutes, > > please tell us. > > See the post on this thread from : > > Guillaume Lelarge > > 10 minutes to generate a pdf. Right. So why don't we just use that? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] Switching to XML
On Sun, 2006-12-10 at 00:32 +0100, Peter Eisentraut wrote: > Joshua D. Drake wrote: > > > If you know of a way to create a PDF off DocBook XML in 30 minutes, > > > please tell us. > > > > See the post on this thread from : > > > > Guillaume Lelarge > > > > 10 minutes to generate a pdf. > > Right. So why don't we just use that? How about the fact that we are putting undue burden on our fellow regional projects? How about it isn't in english? Joshua D. Drake > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [DOCS] Switching to XML
Joshua D. Drake wrote: > On Sun, 2006-12-10 at 00:32 +0100, Peter Eisentraut wrote: > > Joshua D. Drake wrote: > > > > If you know of a way to create a PDF off DocBook XML in 30 > > > > minutes, please tell us. > > > > > > See the post on this thread from : > > > > > > Guillaume Lelarge > > > > > > 10 minutes to generate a pdf. > > > > Right. So why don't we just use that? > > How about the fact that we are putting undue burden on our fellow > regional projects? > > How about it isn't in english? Well, I didn't actually find a post titled "10 minutes to generate a pdf." anywhere, so I assumed you referred to another one of his posts which described how they used FOP to build PDF documentation. That method does not burden anyone unduly and it is in English. But maybe we're not talking about the same thing. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [DOCS] Switching to XML
Tom Lane wrote: > Since jade does not go into this kind of spiral when producing html > output from the same sources, I suggest that it's not jade's fault, > but rather crummy coding in the sgml-to-tex conversion scripts it's > using. Right. I fixed that, so now it takes about 15 minutes to build the whole thing. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [DOCS] Switching to XML
Tom Lane wrote: As for authoring tools, show me one that produces SGML or XML that's reasonably readable, and I might worry about allowing people to use it. Most of the ones I've seen would render the doc sources unreadable for anyone not using an authoring tool (possibly even the very same authoring tool). We are not going to move in that direction because it would piss off the people who do the bulk of the work now. +1 With regards to the current setup discouraging contribution - I've done one (or maybe two) doc submissions and ISTR that it was not very difficult - even as a complete SGML newbie - to get up and running, make my changes and build the (HTML) docs. Cheers Mark ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [DOCS] Switching to XML
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Since jade does not go into this kind of spiral when producing html
>> output from the same sources, I suggest that it's not jade's fault,
>> but rather crummy coding in the sgml-to-tex conversion scripts it's
>> using.
> Right. I fixed that, so now it takes about 15 minutes to build the
> whole thing.
Actually, I just finished fixing what seems to be the underlying problem
in jade: it's got a spectacularly bad implementation of linked lists.
In PG-code terms, if the list is built by successive lappends(), then
both lfirst() and lnext() take O(N) time for an N-element list, thus
iterating through the list in the usual way is O(N^2) ... and not even
with a reasonably small multiplier, because it stresses the hell out of
memory allocation and garbage collection while it's at it. (Which may
well mean that it's really more like O(N^3), since the garbage collector
will iterate over every allocated object every so often.)
With the patch it takes me about 5 minutes to do the jade step of the
PDF build, using this morning's SGML sources. (I don't know how to set
the TeX configuration to get the pdfjadetex steps to go through, so I
dunno about total time.)
However, I have no idea what it'll take to get this patch propagated
into the copies people actually use, so your fix sounds good for the
short term.
regards, tom lane
diff -cr openjade-1.3.2.orig/style/ELObj.cxx openjade-1.3.2/style/ELObj.cxx
*** openjade-1.3.2.orig/style/ELObj.cxx Fri Jan 11 10:48:38 2002
--- openjade-1.3.2/style/ELObj.cxx Sat Dec 9 21:58:36 2006
***
*** 1044,1049
--- 1044,1054
return new (interp) ReverseNodeListObj(this);
}
+ NodeListObj *NodeListObj::nodeListAppend(NodeListObj *newTail, Interpreter
&interp)
+ {
+ return new (interp) HeadNodeListObj(this, newTail, interp);
+ }
+
long NodeListObj::nodeListLength(EvalContext &context, Interpreter &interp)
{
NodeListObj *nl = this;
***
*** 1217,1236
NodeListObj *PairNodeListObj::nodeListRest(EvalContext &context, Interpreter
&interp)
{
! if (!head_ || !head_->nodeListFirst(context, interp))
return tail_->nodeListRest(context, interp);
NodeListObj *tem = head_->nodeListRest(context, interp);
ELObjDynamicRoot protect(interp, tem);
! return new (interp) PairNodeListObj(tem, tail_);
}
NodeListObj *PairNodeListObj::nodeListChunkRest(EvalContext &context,
Interpreter &interp, bool &chunk)
{
! if (!head_ || !head_->nodeListFirst(context, interp))
return tail_->nodeListChunkRest(context, interp, chunk);
NodeListObj *tem = head_->nodeListChunkRest(context, interp, chunk);
ELObjDynamicRoot protect(interp, tem);
! return new (interp) PairNodeListObj(tem, tail_);
}
void PairNodeListObj::traceSubObjects(Collector &c) const
--- 1222,1260
NodeListObj *PairNodeListObj::nodeListRest(EvalContext &context, Interpreter
&interp)
{
! if (!head_)
! return tail_->nodeListRest(context, interp);
! if (!head_->nodeListFirst(context, interp)) {
! head_ = 0;
return tail_->nodeListRest(context, interp);
+ }
NodeListObj *tem = head_->nodeListRest(context, interp);
ELObjDynamicRoot protect(interp, tem);
! if (!tem || !tem->nodeListFirst(context, interp))
! return tail_;
! return tem->nodeListAppend(tail_, interp);
}
NodeListObj *PairNodeListObj::nodeListChunkRest(EvalContext &context,
Interpreter &interp, bool &chunk)
{
! if (!head_)
! return tail_->nodeListChunkRest(context, interp, chunk);
! if (!head_->nodeListFirst(context, interp)) {
! head_ = 0;
return tail_->nodeListChunkRest(context, interp, chunk);
+ }
NodeListObj *tem = head_->nodeListChunkRest(context, interp, chunk);
ELObjDynamicRoot protect(interp, tem);
! if (!tem || !tem->nodeListFirst(context, interp))
! return tail_;
! return tem->nodeListAppend(tail_, interp);
! }
!
! NodeListObj *PairNodeListObj::nodeListAppend(NodeListObj *newTail,
Interpreter &interp)
! {
! NodeListObj *tem = new (interp) PairNodeListObj(tail_, newTail);
! ELObjDynamicRoot protect(interp, tem);
! return new (interp) PairNodeListObj(head_, tem);
}
void PairNodeListObj::traceSubObjects(Collector &c) const
***
*** 1239,1244
--- 1263,1384
c.trace(tail_);
}
+ CellNodeListObj::CellNodeListObj(NodeListObj *head)
+ : head_(head), next_(0)
+ {
+ hasSubObjects_ = 1;
+ }
+
+ NodePtr CellNodeListObj::nodeListFirst(EvalContext &context, Interpreter
&interp)
+ {
+ if (head_) {
+ NodePtr nd(head_->nodeListFirst(context, interp));
+ if (nd)
+ return nd;
+ head_ = 0;
+ }
+ if (next_)
+ return next_->nodeListFirst(context, interp);
+ return NodePtr();
+ }
+
+ NodeListObj *CellNodeListObj::nodeListRest(EvalContext &context, Interpreter
&interp)
+ {
+ if (!head_) {
+ if (next_)
+ return next_->nodeList
Re: [DOCS] Switching to XML
I wrote: > With the patch it takes me about 5 minutes to do the jade step of the > PDF build, using this morning's SGML sources. Ooops, that was with an -O0 build for debugging. After rebuilding with the normal -O2 optimization, it takes about 70 seconds, just about exactly the same as for the HTML-output case. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [DOCS] Switching to XML
On Sun, 2006-12-10 at 03:13 +0100, Peter Eisentraut wrote: > Joshua D. Drake wrote: > > On Sun, 2006-12-10 at 00:32 +0100, Peter Eisentraut wrote: > > > Joshua D. Drake wrote: > > > > > If you know of a way to create a PDF off DocBook XML in 30 > > > > > minutes, please tell us. > > > > > > > > See the post on this thread from : > > > > > > > > Guillaume Lelarge > > > > > > > > 10 minutes to generate a pdf. > > > > > > Right. So why don't we just use that? > > > > How about the fact that we are putting undue burden on our fellow > > regional projects? > > > > How about it isn't in english? > > Well, I didn't actually find a post titled "10 minutes to generate a > pdf." anywhere, so I assumed you referred to another one of his posts > which described how they used FOP to build PDF documentation. That > method does not burden anyone unduly and it is in English. But maybe > we're not talking about the same thing. I meant, *their* xml file is not english. So it doesn't do any good. Remember this whole current thread started because we are trying to create print ready documentation, which we currently do not have. Sincerely, Joshua D. Drake > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [DOCS] Switching to XML
I wrote: > With the patch it takes me about 5 minutes to do the jade step of the > PDF build, using this morning's SGML sources. (I don't know how to set > the TeX configuration to get the pdfjadetex steps to go through, so I > dunno about total time.) OK, I read Peter's notes about suitable TeX configuration, and with that plus suitably patched openjade I get this from a standing start: $ time make postgres.pdf ... much output ... Output written on postgres.pdf (1670 pages, 13561269 bytes). Transcript written on postgres.log. real8m23.949s user8m14.263s sys 0m9.241s $ But my goodness it produces a lot of TeX warnings :-(. I can understand that no one was gonna look into those with a three-day turnaround time, but maybe now we can think about cleaning them up? Personally I haven't used TeX/LaTeX in anger in about ten years, but most of what scrolled past looked easily fixable, and at least some of it would translate to visible ugliness in the output. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [DOCS] Switching to XML
On Sat, 2006-12-09 at 09:21 +0100, Guillaume Lelarge wrote: > Joshua D. Drake a écrit : > > On Fri, 2006-12-08 at 21:58 +0100, Peter Eisentraut wrote: > >> Joshua D. Drake wrote: > >>> You can create, edit, convert, save, and open docbook xml in > >>> OpenOfice.org. > >> Sure, there are more editing options with DocBook XML. No one disputes > >> that. But the question at hand was about processing the DocBook. > > > > Yes which is generated from our use of SGML which is the core of this > > problem and the core of the question as a whole. > > > > SGML is making working with the documentation *harder*. > > > > +1 I believe this point is being overlooked is people's willingness to code a solution ;). Guillaume could you please tell us *why* you ported the SGML to XML before doing your translation and processing? Perhaps that will carry more weight to this discussion then my hand waving. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [DOCS] Switching to XML
On Fri, 2006-12-08 at 22:49 -0300, Mario wrote: > On 08/12/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote: > > There is a long standing support within the community to move to XML > > including: > > > > Josh Berkus > > Josh Drake > > Robert Treat > > Andrew Dunslane > > David Blewett > > David Fetter > > Devrim Gunduz > > Darcy Buskermolen > > > > And that is just from #postgresql > > > > And now in Chile, I wrote an app to translate postgres documentation > (l10n.postgresql.cl). I took SGML sources, transform to XML and to POT > files > > The results are good! but is it not the best. To move from SGML to > XML is a hard work. I believe this point is being overlooked is people's willingness to code a solution ;). Mario could you please tell us *why* you ported the SGML to XML before doing your translation and processing? Perhaps that will carry more weight to this discussion then my hand waving. Sincerely, Joshua D. Drake > > > > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [DOCS] Switching to XML
On Sat, Dec 09, 2006 at 09:21:12AM +0100, Guillaume Lelarge wrote: > Joshua D. Drake a écrit : > > On Fri, 2006-12-08 at 21:58 +0100, Peter Eisentraut wrote: > >> Joshua D. Drake wrote: > >>> You can create, edit, convert, save, and open docbook xml in > >>> OpenOfice.org. > >> Sure, there are more editing options with DocBook XML. No one disputes > >> that. But the question at hand was about processing the DocBook. > > > > Yes which is generated from our use of SGML which is the core of this > > problem and the core of the question as a whole. > > > > SGML is making working with the documentation *harder*. > > +1 Thanks to Peter and Tom for making the PDF build faster, but the more general problem, which is that the SGML does not actually do the same things that XML does, no matter how many times Peter so asserts, remains. In addition to the long-standing problem that there is no way to edit the SGML docs with any known GUI tool, we have a particular use case, namely producing a multi-volume set suitable for printing as books. > > We have people that *DO NOT* contribute because of this SGML > > requirement. They have what I consider extremely valid reasons, > > namely it is dumb to require a writer to use emacs or write tags > > explictly. Peter, if you have a working example of a GUI tool that can be used with the SGML source in its current form, the burden of proof is on you to demonstrate it. Another flat assertion from you of some kind of mathematical equivalence between SGML and XML will *not* do the trick. > > Hell, the only reason I have even bothered to contribute what > > little I have to the docs is because I wrote a book in SGML, thus > > it is a no brainer to me. Others aren't so tortured as to have > > done the same. > > I'm not so sure it will help you find more contributors. I'm part of > a project which aims to translate HOWTO from TLDP. They don't find > contributors and we too have really hard times to find contributors > despite the fact we try to only use DocBook XML (TLDP use DocBook > SGML, DocBook XML and LinuxDoc formats). > > Did you try to use OpenOffice.org with DocBook ? I tried once and it > was a complete disaster. But it was a long time ago. I will try > again this week-end. I gave it a try post-patches, and it's still a disaster 3284 pages of un-rendered XML. > > There is a long standing support within the community to move to XML > > including: > > > > Josh Berkus > > Josh Drake > > Robert Treat > > Andrew Dunslane > > David Blewett > > David Fetter > > Devrim Gunduz > > Darcy Buskermolen > > > > And that is just from #postgresql > > > > The french team also uses Docbook XML and they can generate a PDF > > in 30 minutes... it takes us DAYS because of the SGML. > > In fact, we need 15 minutes to build HTML files and 10 minutes to > build PDF file. To be completely honest, I don't seem to be able to > build PDF file for 8.2.0 release. I must have made a mistake (or > perhaps a lot of :) ). It'll be nice to have the document building cycle shorter, but the point here is that we need to enter the 21st century. That Tom found a need to fork a document tool, i.e. take ownership of a whole large piece of software, that being what forking means, is a neon sign that means, "we're stuck with broken tools." Cheers, D -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [DOCS] Switching to XML
> In addition to the long-standing problem that there is no way to edit > the SGML docs with any known GUI tool, we have a particular use case, > namely producing a multi-volume set suitable for printing as books. Well yes and no. There isn't really any good WYSIWYG tools, but there are plenty of graphical validating editors for Docbook XML. I actually don't agree with JoshBs argument on this one as most major FOSS (Gnome, KDE, Linux) have moved to Docbook XML without the need of graphical editors. I do think the tools in general can be a little daunting and perhaps a pgfoundry project that had a perl script that would download and configure a self contained jail of tools for working with the PostgreSQL docs would be good. > > > > We have people that *DO NOT* contribute because of this SGML > > > requirement. They have what I consider extremely valid reasons, > > > namely it is dumb to require a writer to use emacs or write tags > > > explictly. > > Peter, if you have a working example of a GUI tool that can be used > with the SGML source in its current form, the burden of proof is on > you to demonstrate it. Another flat assertion from you of some kind > of mathematical equivalence between SGML and XML will *not* do the > trick. I have to agree here, the reality is that the tools that are designed to work with XML work with XML. Yes you *can* in theory make them work with SGML, and some may work directly out of the box (Emacs would for editing for example), not all of them would. > > Did you try to use OpenOffice.org with DocBook ? I tried once and it > > was a complete disaster. But it was a long time ago. I will try > > again this week-end. > > I gave it a try post-patches, and it's still a disaster 3284 pages of > un-rendered XML. Well keep in mind that all XML is unrendered :). OpenOffice will do things like this: Hi Bye Which equates to: Hi Bye We don't do that in the PostgreSQL sgml (thank goodness) so it comes out really narly :). However it wouldn't take much to clean up small sections for people. > > In fact, we need 15 minutes to build HTML files and 10 minutes to > > build PDF file. To be completely honest, I don't seem to be able to > > build PDF file for 8.2.0 release. I must have made a mistake (or > > perhaps a lot of :) ). > > It'll be nice to have the document building cycle shorter, but the > point here is that we need to enter the 21st century. That Tom found > a need to fork a document tool, i.e. take ownership of a whole large > piece of software, that being what forking means, is a neon sign that > means, "we're stuck with broken tools." That is a big concern for me as well. I don't think Tom expects us to maintain the code, and we can certainly try to get the patch submitted to the open jade project which would definitely help. However, the movement of the open jade projects appears basically dead. Moving to XML based tools does give us a more modern and developed toolset. Sincerely, Joshua D. Drake > > Cheers, > D -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] Switching to XML
David Fetter <[EMAIL PROTECTED]> writes: > In addition to the long-standing problem that there is no way to edit > the SGML docs with any known GUI tool, The point not in evidence is that there exists a GUI tool we'd accept for editing XML-format docs. Can you point to some that don't mess up XML source code to the point of being unreadable? > ... That Tom found > a need to fork a document tool, i.e. take ownership of a whole large > piece of software, that being what forking means, is a neon sign that > means, "we're stuck with broken tools." Um, I spend all day every day on making sometimes-comparable improvements in Postgres. Will you abandon Postgres as soon as someone points out a(nother) serious performance bug in it? As for "fork", I have no intention of forking anything --- that patch is already submitted upstream. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
