Re: [DOCS] Authoring Tools WAS: Switching to XML
Bruce, > o WYSIWYG - this seems unattainable because such editors are > going to modify the surrounding XML, which will affect > hand-edited changes It would be more accurate to say that we have not identified a WYSWYG tool which does not mess up the source. There may be one, it would just take a fair amount of testing to find it. > o tag assistance - this seems possible, e.g. tag completion, > drop down list of tags available for this section Yes, and graphically-enhanced tag support using XML IDEs. Command-line tag completion is available via Emacs-SGML, but there are a lot more tools which do it for XML (including Emacs). -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [DOCS] Authoring Tools WAS: Switching to XML
On Thu, 2006-12-14 at 14:58, Josh Berkus wrote: > Bruce, > > > o WYSIWYG - this seems unattainable because such editors are > > going to modify the surrounding XML, which will affect > > hand-edited changes > > It would be more accurate to say that we have not identified a WYSWYG tool > which does not mess up the source. There may be one, it would just take a > fair amount of testing to find it. Is this strictly a question of indentation, or one of actually mangling tags and such? ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [DOCS] Authoring Tools WAS: Switching to XML
Scott Marlowe <[EMAIL PROTECTED]> writes: > On Thu, 2006-12-14 at 14:58, Josh Berkus wrote: >> It would be more accurate to say that we have not identified a WYSWYG tool >> which does not mess up the source. There may be one, it would just take a >> fair amount of testing to find it. > Is this strictly a question of indentation, or one of actually mangling > tags and such? What we need is something that does not change regions of the file that the user did not intend to modify. I think horizonal-white-space-only changes could be worked around if the user is careful to use diff --ignore-space-change when submitting the patch, but I suspect that an editor that thinks it can mangle whitespace will also figure that it can change line boundaries, and then diff will never be able to extract any signal from that noise. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] Authoring Tools WAS: Switching to XML
On Thu, 2006-12-14 at 15:34, Tom Lane wrote: > Scott Marlowe <[EMAIL PROTECTED]> writes: > > On Thu, 2006-12-14 at 14:58, Josh Berkus wrote: > >> It would be more accurate to say that we have not identified a WYSWYG tool > >> which does not mess up the source. There may be one, it would just take a > >> fair amount of testing to find it. > > > Is this strictly a question of indentation, or one of actually mangling > > tags and such? > > What we need is something that does not change regions of the file that > the user did not intend to modify. I think horizonal-white-space-only > changes could be worked around if the user is careful to use diff > --ignore-space-change when submitting the patch, but I suspect that an > editor that thinks it can mangle whitespace will also figure that it can > change line boundaries, and then diff will never be able to extract any > signal from that noise. A. I see. Well, I don't mind teaching myself some docbook, but the first time I looked at adding to the docs I was overwhelmed with what I didn't know, and didn't even see a starting point. I'll look in the appendices and see what I can see. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-www] [DOCS] 8.2.0 pdf
Tom Lane wrote: > 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). I have modified the sgml Makefile to run jade twice for PDF and PS output; patch attached and applied to HEAD and 8.2.X. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/Makefile === RCS file: /cvsroot/pgsql/doc/src/sgml/Makefile,v retrieving revision 1.84 diff -c -c -r1.84 Makefile *** doc/src/sgml/Makefile 10 Dec 2006 20:46:03 - 1.84 --- doc/src/sgml/Makefile 15 Dec 2006 00:18:52 - *** *** 137,155 --- 137,164 JADE.tex.call = $(JADE) $(JADEFLAGS) $(SGMLINCLUDE) $(CATALOG) -d $(srcdir)/stylesheet.dsl -t tex -V tex-backend -i output-print %-A4.tex-ps: %.sgml $(ALLSGML) stylesheet.dsl + # multiple runs are necessary to create proper index entries + $(JADE.tex.call) -V texdvi-output -V '%paper-type%'=A4 -o $@ $< $(JADE.tex.call) -V texdvi-output -V '%paper-type%'=A4 -o $@ $< %-US.tex-ps: %.sgml $(ALLSGML) stylesheet.dsl + # multiple runs are necessary to create proper index entries + $(JADE.tex.call) -V texdvi-output -V '%paper-type%'=USletter -o $@ $< $(JADE.tex.call) -V texdvi-output -V '%paper-type%'=USletter -o $@ $< %-A4.tex-pdf: %.sgml $(ALLSGML) stylesheet.dsl + # multiple runs are necessary to create proper index entries + $(JADE.tex.call) -V texpdf-output -V '%paper-type%'=A4 -o $@ $< $(JADE.tex.call) -V texpdf-output -V '%paper-type%'=A4 -o $@ $< %-US.tex-pdf: %.sgml $(ALLSGML) stylesheet.dsl + # multiple runs are necessary to create proper index entries + $(JADE.tex.call) -V texpdf-output -V '%paper-type%'=USletter -o $@ $< $(JADE.tex.call) -V texpdf-output -V '%paper-type%'=USletter -o $@ $< %.dvi: %.tex-ps @rm -f $*.aux $*.log + # multiple runs are necessary to create proper index entries jadetex $< jadetex $< jadetex $< *** *** 160,165 --- 169,175 %.pdf: %.tex-pdf @rm -f $*.aux $*.log $*.out + # multiple runs are necessary to create proper index entries pdfjadetex $< pdfjadetex $< pdfjadetex $< ---(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
I have applied the attached documentation patch to HEAD and 8.2.X to document the use of Tom's patch to openjade to get ouput in a reasonable amount of time. --- Tom Lane wrote: > 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.cxxSat Dec 9 21:58:36 2006 > *** > *** 1044,1049 > --- 1044,1054 -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/docguide.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/docguide.sgml,v retrieving revision 1.61 diff -c -c -r1.61 docguide.sgml *** doc/src/sgml/docguide.sgml 10 Dec 2006 20:46:03 - 1.61 --- doc/src/sgml/docguide.sgml 15 Dec 2006 02:39:37 - *** *** 115,120 --- 115,123 DSSSL stylesheets), as well as a number of related tools. Jade is now being maintained by the OpenJade group, no longer by James Clark. +(If generating Postscript or PDF output, you will need to +compile from source and use a special patch to get output +in a reasonable amount of time.) *** *** 295,300 --- 298,311 installed and you want to install the rest of the tool chain locally.) + + + OpenJade release 1.3.2 and perhaps earlier and later releases + have a known bug that causes Postscript and PDF output + generation to take days. This http://archives.postgresql.org/pgsql-docs/2006-12/msg00064.php";>patch + fixes the problem and generates output in a few minutes. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] Authoring Tools WAS: Switching to XML
On Thu, Dec 14, 2006 at 04:34:06PM -0500, Tom Lane wrote: > Scott Marlowe <[EMAIL PROTECTED]> writes: > > On Thu, 2006-12-14 at 14:58, Josh Berkus wrote: > >> It would be more accurate to say that we have not identified a > >> WYSWYG tool which does not mess up the source. There may be one, > >> it would just take a fair amount of testing to find it. > > > Is this strictly a question of indentation, or one of actually > > mangling tags and such? > > What we need is something that does not change regions of the file > that the user did not intend to modify. I think > horizonal-white-space-only changes could be worked around if the > user is careful to use diff --ignore-space-change when submitting > the patch, but I suspect that an editor that thinks it can mangle > whitespace will also figure that it can change line boundaries, and > then diff will never be able to extract any signal from that noise. Could post-processing with tidy clean this up? I'm pretty sure that tidy's output is deterministic, at least if the editor hasn't mangled tags... Cheers, D -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [DOCS] Authoring Tools WAS: Switching to XML
> > What we need is something that does not change regions of the file > > that the user did not intend to modify. I think > > horizonal-white-space-only changes could be worked around if the > > user is careful to use diff --ignore-space-change when submitting > > the patch, but I suspect that an editor that thinks it can mangle > > whitespace will also figure that it can change line boundaries, and > > then diff will never be able to extract any signal from that noise. > > Could post-processing with tidy clean this up? I'm pretty sure that > tidy's output is deterministic, at least if the editor hasn't mangled > tags... > Yes tidy makes things pretty darn clean. However, there is one thing that it won't do and that is remove extra tags. Thus something like OpenOffice is still a no-op. 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 4: Have you searched our list archives? http://archives.postgresql.org
