Thread: [Refdb-devel] new-document and doc-processing menu behavior
Status: Beta
Brought to you by:
mhoenicka
Menu
▾
▴
refdb-devel
|
From: Michael S. <sm...@xm...> - 2003-12-09 08:22:29
|
Hi Bruce, You wrote: > On Monday, December 8, 2003, at 10:07 AM, Michael Smith wrote: > > > 1. Add a "Create New Document..." menu item. > > > > Selecting that will fire up refdbnd (or some Emacs-based > > equivalent > > of that) and create the makefile for the document at the same > > time as the document is created. > > > > 2. Add a "Process Document" or "Generate Output" submenu, with "PDF", > > "HTML", "RTF" and "All" menu items. > > > > Selecting that will just call up the corresponding makefile for > > the > > document, and pass it the appropriate target name. > > With 2, could you then create the makefile if it didn't exist? Say you > have an existing document that wasn't created with the "Create New > Document" feature you outline: choose process document, and if there > was no makefile, user is prompted for the style file and it's created > and the transformation is run. Yeah, that's doable. Seems like that's the way it should work. Only alternative is to have Emacs just emit a "No makefile found" error with some kind of instructions about what to do in order to create the makefile (which of course would need to be something different than going to the Create New Document" menu), Come to think of it, I guess the flow for the case where a user hasn't specified a database should be similar: If no database has been set, the first time one is needed, users should be prompted for the name of one, and that will be used for all subsequent commands unless the user explicitly sets another db name. > > It seems like the "Process Document" submenu will either need to work > > from the assumption that there's only one document per directory, and > > it's associated with a file called "Makefile" in the same directory. Or > > it could work by looking for a file with the extension ".mk" and the > > same base name as the document in the current buffer. That'd allow you > > to have multiple documents in the same directory. > > I think I prefer the latter. OK. I guess this is also something that could be configurable. But I wonder a little why you'd need it, because from your description below, it seems that, in that directory, you've still got one logical document (dissent-book.xml) for which you want to generate an bibliography -- it's just broken up into separate physical files for each chapter. > Let me just tell you how my current project (a book) is set up: > > The source is all in one CVS-managed directory, called "dissent-book." > It looks like this: > > drwxr-xr-x 5 darcusb staff 170 Oct 2 17:41 CVS > -rw-r--r-- 1 darcusb staff 1362 Sep 2 20:23 dissent-book.xml > -rw-r--r-- 1 darcusb staff 516 Aug 17 15:44 > dissent-chapter1.xml > -rw-r--r-- 1 darcusb staff 15251 Oct 31 10:03 > dissent-chapter2.xml > -rw-r--r-- 1 darcusb staff 11756 Aug 18 16:33 > dissent-chapter2.xml‾ > -rw-r--r-- 1 darcusb staff 19622 Aug 17 15:44 > dissent-chapter3.xml > -rw-r--r-- 1 darcusb staff 91729 Aug 17 15:44 > dissent-chapter4.xml > -rw-r--r-- 1 darcusb staff 944 Aug 17 15:44 > dissent-chapter5.xml > -rw-r--r-- 1 darcusb staff 13229 Aug 17 15:44 > dissent-chapter6.xml > -rw-r--r-- 1 darcusb staff 1779 Aug 17 15:44 > dissent-chapter7.xml > drwxr-xr-x 5 darcusb staff 170 Sep 13 11:07 output > > The output directory is where I place the fo and pdf files and such. > > Here is the main file: > > <?xml version="1.0" encoding="utf-8"?> > <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" > > "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ > <!ENTITY bibliography SYSTEM "dbxtest.bib.xml"> > <!ENTITY chapter1 SYSTEM "dissent-chapter1.xml"> > <!ENTITY chapter2 SYSTEM "dissent-chapter2.xml"> > <!ENTITY chapter3 SYSTEM "dissent-chapter3.xml"> > <!ENTITY chapter4 SYSTEM "dissent-chapter4.xml"> > <!ENTITY chapter5 SYSTEM "dissent-chapter5.xml"> > <!ENTITY chapter6 SYSTEM "dissent-chapter6.xml"> > <!ENTITY chapter7 SYSTEM "dissent-chapter7.xml"> > ]> > <book> > <bookinfo> > <author> > <firstname>Bruce</firstname> > <surname>D'Arcus</surname> > </author> > <affiliation> > <orgname>Miami University</orgname> > <orgdiv>Geography Department</orgdiv> > <address> > <street>216 Shideler Hall</street> > <city>Oxford</city> > <state>Ohio</state> > <country>USA</country> > <email>da...@mu...</email> > </address> > </affiliation> > <title>Boundaries of Dissent</title> > <subtitle>Protest and State Power in the Media Age</subtitle> > <copyright> > <year>2003</year> > <holder>Bruce D'Arcus</holder> > </copyright> > </bookinfo> > > &chapter1; > &chapter2; > &chapter3; > &chapter4; > &chapter5; > &chapter6; > &chapter7; > > &bibliography; > </book> > > Aside: how to do this without entities? Use XInclude's and have RefDB call xsltproc to process those? > Since the book is broken up into pieces, I often just run a > transformation on an individual chapter (apart from refdb). I don't > know that it is necessary for RefDB to be involved there, but it might > be helpful (say I send a draft chapter to someone). > > This may be tricky though... Would you also be generating a biblography for an individual chapter? If not, since it seems like a main purpose of going through the RefDB toolchain is to generate the bibliography, maybe processing of the individual chapters is out of scope for RefDB Emacs integration. Or to put it another way, if it's not something you'd use the RefDB toolchain to do from the command line, it seems like it's probably not something that needs to be in the Emacs integration. |
|
From: Bruce D'A. <bd...@fa...> - 2003-12-09 14:26:21
|
On Dec 9, 2003, at 3:22 AM, Michael Smith wrote: >>> It seems like the "Process Document" submenu will either need to work >>> from the assumption that there's only one document per directory, and >>> it's associated with a file called "Makefile" in the same directory. >>> Or >>> it could work by looking for a file with the extension ".mk" and the >>> same base name as the document in the current buffer. That'd allow >>> you >>> to have multiple documents in the same directory. >> >> I think I prefer the latter. > > OK. I guess this is also something that could be configurable. But I > wonder a little why you'd need it, because from your description below, > it seems that, in that directory, you've still got one logical document > (dissent-book.xml) for which you want to generate an bibliography -- > it's just broken up into separate physical files for each chapter. Yes. I would prefer to group by directory, but I could imagine someone wanting to have more than one document in a directory. My bigger issue is to dump the output files in their own subdirectories (don't want a bunch of TeX files littering the doc directory). >> Aside: how to do this without entities? > > Use XInclude's and have RefDB call xsltproc to process those? Can RefDB already handle this Markus? I want to avoid using entities altogether. >> Since the book is broken up into pieces, I often just run a >> transformation on an individual chapter (apart from refdb). I don't >> know that it is necessary for RefDB to be involved there, but it might >> be helpful (say I send a draft chapter to someone). >> >> This may be tricky though... > > Would you also be generating a biblography for an individual chapter? Not at this stage. But when I get farther along, I could see sending out a draft chapter for comment that included RefDB-processed bibliography and citations. > If not, since it seems like a main purpose of going through the RefDB > toolchain is to generate the bibliography, maybe processing of the > individual chapters is out of scope for RefDB Emacs integration. Or to > put it another way, if it's not something you'd use the RefDB toolchain > to do from the command line, it seems like it's probably not something > that needs to be in the Emacs integration. This is a somewhat non-standard case that would be nice to accommodate if feasible, but not strictly necessary. Bruce |
|
From: Markus H. <mar...@mh...> - 2003-12-10 01:09:10
|
Bruce D'Arcus writes: > > Use XInclude's and have RefDB call xsltproc to process those? > > Can RefDB already handle this Markus? I want to avoid using entities > altogether. > I didn't follow this discussion. At which stage of the document processing would this come into play? regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Bruce D'A. <bd...@fa...> - 2003-12-10 01:18:14
|
On Dec 9, 2003, at 7:16 PM, Markus Hoenicka wrote: > Bruce D'Arcus writes: >>> Use XInclude's and have RefDB call xsltproc to process those? >> >> Can RefDB already handle this Markus? I want to avoid using entities >> altogether. > > I didn't follow this discussion. At which stage of the document > processing would this come into play? In other words, I want to process citations and bibs for my entire book project, which is assembled via xincludes in a document called book.xml. They serve the same function as the current entities that specify the chapter files. Bruce |
|
From: Michael S. <sm...@xm...> - 2003-12-10 03:09:16
|
Bruce D'Arcus <bd...@fa...> writes:
>
> On Dec 9, 2003, at 7:16 PM, Markus Hoenicka wrote:
>
> >Bruce D'Arcus writes:
> >>>Use XInclude's and have RefDB call xsltproc to process those?
> >>
> >>Can RefDB already handle this Markus? I want to avoid using entities
> >>altogether.
> >
> >I didn't follow this discussion. At which stage of the document
> >processing would this come into play?
>
> In other words, I want to process citations and bibs for my entire book
> project, which is assembled via xincludes in a document called
> book.xml. They serve the same function as the current entities that
> specify the chapter files.
It seems like nothing much actually needs to be changed in the RefDB
tool chain to support processing a doc that uses XIncludes.
I think the only toolchain fix needed is to change a couple lines in
refdbxml so that it always calls xsltproc with the "--xinclude" option.
Then, the docs could just be updated to mention using Xincludes; e.g.,
the tutorial doc would say:
... At a location where such a [div or bibliography] element is
valid, either include the external entity itself or an Xinclude
element that references the entity, like in the following chunk:
..
</chapter>
&bibliography;
</book>
or
..
</chapter>
<xi:include href="&bibliography;" xmlns:xi="http://www.w3.org/2001/XInclude"/>
</book>
And if you really wanted to do away with the bibliography entity
entirely in an XML doc, you could instead just reference the file name
of the bibliography directly, like this:
<xi:include href="refdbtest.bib.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
If you did that, and you're editing in nXML mode, you could also just drop
the document prologue entirely; otherwise, you could, if you wanted to, at
least get rid of the entity declaration in the internal subset.
--Mike
|
|
From: Markus H. <mar...@mh...> - 2003-12-10 22:39:57
|
Michael Smith writes: > It seems like nothing much actually needs to be changed in the RefDB > tool chain to support processing a doc that uses XIncludes. > > I think the only toolchain fix needed is to change a couple lines in > refdbxml so that it always calls xsltproc with the "--xinclude" option. > If this is all it takes, then it's a no-brainer. I assume it doesn't hurt to use the --xinclude option even if the file does not contain Xincludes? regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Bruce D'A. <bd...@fa...> - 2003-12-09 17:46:30
|
On Dec 9, 2003, at 3:22 AM, Michael Smith wrote: >> With 2, could you then create the makefile if it didn't exist? Say >> you >> have an existing document that wasn't created with the "Create New >> Document" feature you outline: choose process document, and if there >> was no makefile, user is prompted for the style file and it's created >> and the transformation is run. > > Yeah, that's doable. Seems like that's the way it should work. Only > alternative is to have Emacs just emit a "No makefile found" error with > some kind of instructions about what to do in order to create the > makefile (which of course would need to be something different than > going to the Create New Document" menu), Maybe the solution should also be suitable for changing output styles too? So then perhaps the new doc thing shouldn't specify and output style and create a makefile? Let's see: As with the database menu, styles are drawn from refdb. When one needs to process the document but no style is selected, go to the style, choose the output option, and the makefile is created, and run with the appropriate option. If later the user needs to change output styles, it involves the same process: a simple menu click. Menu structure might be: - Process Document - Style 1 - all - html - pdf - xhtml - Style 2 - all - html - pdf - xhtml I'd like output to be customizable. For example, I sent Bob S. some stylesheet customizations that use (x)html + css to fool MS Word into thinking it is importing a native doc file. It would be nice, then, for me to be able to customize RefDB and its menu so I could have a "MS Word" output option. Bruce |
|
From: Markus H. <mar...@mh...> - 2003-12-10 01:09:23
|
Bruce D'Arcus writes: > Maybe the solution should also be suitable for changing output styles > too? So then perhaps the new doc thing shouldn't specify and output > style and create a makefile? > I think it would be beneficial to always create a Makefile along with a new document. Otherwise the document processing is broke as soon as you leave Emacs. If you create a Makefile by default, you can always run "make pdf" or whatever from the command line and get some results. I feel the best way to specify the style from the RefDB menu is to pass this as an argument to the make command. > Let's see: > > As with the database menu, styles are drawn from refdb. When one needs > to process the document but no style is selected, go to the style, > choose the output option, and the makefile is created, and run with the > appropriate option. > > If later the user needs to change output styles, it involves the same > process: a simple menu click. > > Menu structure might be: > > - Process Document > - Style 1 > - all > - html > - pdf > - xhtml > - Style 2 > - all > - html > - pdf > - xhtml > If we ever get close to the journal support of the likes of RefMan or EndNote, we'd be looking at roughly 700 style entries in this menu, along with 5 submenus each. I don't think this is going to work. I'd rather have the user select the style and, separately from this, have him process the document. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Bruce D'A. <bd...@fa...> - 2003-12-10 01:16:34
|
On Dec 9, 2003, at 7:29 PM, Markus Hoenicka wrote: > I think it would be beneficial to always create a Makefile along with > a new document. Otherwise the document processing is broke as soon as > you leave Emacs. If you create a Makefile by default, you can always > run "make pdf" or whatever from the command line and get some results. Good point. > I feel the best way to specify the style from the RefDB menu is to > pass this as an argument to the make command. Not following. In any case, I think the ideal is to have some flexibility here. If I create a document on a non-refdb system with some other xml editor, I want to be able to easily move it to my refdb box fire up emacs, and process the document without hassling with the command line. > If we ever get close to the journal support of the likes of RefMan or > EndNote, we'd be looking at roughly 700 style entries in this menu, > along with 5 submenus each. I don't think this is going to work. I'd > rather have the user select the style and, separately from this, have > him process the document. Well, the styles would only be those loaded in the database, and so would be user-defined styles. A normal user would only ever have 5-10 would be my guess. I think we should open this stuff about user experience up to the user list for comment, BTW. Bruce |
|
From: Markus H. <mar...@mh...> - 2003-12-10 22:39:47
|
Bruce D'Arcus writes: > > I feel the best way to specify the style from the RefDB menu is to > > pass this as an argument to the make command. > > Not following. > > In any case, I think the ideal is to have some flexibility here. If I > create a document on a non-refdb system with some other xml editor, I > want to be able to easily move it to my refdb box fire up emacs, and > process the document without hassling with the command line. > I wouldn't mind having the menu code create a Makefile if there is none as soon as you attempt to process a document. I am arguing against modifying the Makefile each time you run this command. Switching styles is easier by passing the style name as an argument on the make command line. The Makefiles are specifically designed to facilitate this. This is absolutely transparent to the user and faster as you don't have to write the Makefile back to disk. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Michael S. <sm...@xm...> - 2003-12-10 23:50:57
|
Markus Hoenicka <mar...@mh...> writes: > Bruce D'Arcus writes: > > > I feel the best way to specify the style from the RefDB menu is to > > > pass this as an argument to the make command. > > > > Not following. > > > > In any case, I think the ideal is to have some flexibility here. If I > > create a document on a non-refdb system with some other xml editor, I > > want to be able to easily move it to my refdb box fire up emacs, and > > process the document without hassling with the command line. > > > > I wouldn't mind having the menu code create a Makefile if there is > none as soon as you attempt to process a document. I guess it's doable to have the menu code do it, but that seems like a RefDB feature that's useful outside of the menu and outside of Emacs. I think users working from the command line have the same need. I'm thinking of the menu mostly just as a user-friendly front-end to the existing command line tools. In this case, the Create Document menu will just call refdbnd and the Generate Output menu will call make and pass the appropriate target name (and variables, if needed) to that. But AFAICT, there is currently no way, from the command line, of having the RefDB command-line toolchain create a Makefile for an existing document. Seems like what's needed is a "new Makefile" script -- 'refdbnm' or whatever. I guess the way that would work is, it would prompt you for the same info that refdbnd does, with the addition of prompting to ask whether the document uses short or full notation (because it won't necessarily have the filename clue to go from). > I am arguing against modifying the Makefile each time you run this > command. Switching styles is easier by passing the style name as an > argument on the make command line. The Makefiles are specifically > designed to facilitate this. This is absolutely transparent to the > user and faster as you don't have to write the Makefile back to disk. I'm a 100 percent in agreement on this. It's easy enough to just pass the style variable to 'make' along with any target names. --Mike |
|
From: Markus H. <mar...@mh...> - 2003-12-11 00:03:05
|
Michael Smith writes: > But AFAICT, there is currently no way, from the command line, of > having the RefDB command-line toolchain create a Makefile for an > existing document. Seems like what's needed is a "new Makefile" script > -- 'refdbnm' or whatever. > It shouldn't be too hard to add a command-line switch to refdbnd that suppresses the creation of the skeleton document. This way you could create a Makefile for an existing document. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Michael S. <sm...@xm...> - 2003-12-11 00:12:14
|
Markus Hoenicka <mar...@mh...> writes: > Michael Smith writes: > > But AFAICT, there is currently no way, from the command line, of > > having the RefDB command-line toolchain create a Makefile for an > > existing document. Seems like what's needed is a "new Makefile" script > > -- 'refdbnm' or whatever. > > > > It shouldn't be too hard to add a command-line switch to refdbnd that > suppresses the creation of the skeleton document. This way you could > create a Makefile for an existing document. That makes sense. As I mentioned, I think also you might need to add some logic for asking whether the existing doc uses short or full notations, since there's not guarantee that the user has followed the '*.short.*' convention that the current generated Makefiles expect for short-notation documents. --Mike |
|
From: Markus H. <mar...@mh...> - 2003-12-11 21:03:41
|
Michael Smith writes: > That makes sense. As I mentioned, I think also you might need to add > some logic for asking whether the existing doc uses short or full > notations, since there's not guarantee that the user has followed the > '*.short.*' convention that the current generated Makefiles expect for > short-notation documents. > Ok, I'll rework the script along these lines. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Michael S. <sm...@xm...> - 2003-12-10 23:59:51
|
Bruce D'Arcus <bd...@fa...> writes: > On Dec 9, 2003, at 7:29 PM, Markus Hoenicka wrote: [...] > >If we ever get close to the journal support of the likes of RefMan or > >EndNote, we'd be looking at roughly 700 style entries in this menu, > >along with 5 submenus each. I don't think this is going to work. I'd > >rather have the user select the style and, separately from this, have > >him process the document. I agree here > Well, the styles would only be those loaded in the database, and so > would be user-defined styles. A normal user would only ever have 5-10 > would be my guess. The way I plan to handle selecting styles is through 'validated' Emacs completion against whatever list of styles a query to the database returns. That'll make it easy to use in that you won't need to remember style names, and won't need to worry about mis-typing a style name, because it will constrain you to just those style names that are actually in the db. How does that sound? > I think we should open this stuff about user experience up to the user > list for comment, BTW. That sounds like a good idea to me. --Mike |
|
From: Michael S. <sm...@xm...> - 2003-12-11 01:29:16
|
Bruce D'Arcus <bd...@fa...> writes:
> On Dec 9, 2003, at 3:22 AM, Michael Smith wrote:
>
> >>With 2, could you then create the makefile if it didn't exist? Say
> >>you
> >>have an existing document that wasn't created with the "Create New
> >>Document" feature you outline: choose process document, and if there
> >>was no makefile, user is prompted for the style file and it's created
> >>and the transformation is run.
> >
> >Yeah, that's doable. Seems like that's the way it should work. Only
> >alternative is to have Emacs just emit a "No makefile found" error with
> >some kind of instructions about what to do in order to create the
> >makefile (which of course would need to be something different than
> >going to the Create New Document" menu),
>
> Maybe the solution should also be suitable for changing output styles
> too? So then perhaps the new doc thing shouldn't specify and output
> style and create a makefile?
I guess I'm pretty much in agreement with Markus about the value of
keeping everything makefile-driven. Whatever ends up on the menu will
just be a front-end to the command-line toolchain. So, if it's something
that's doable from the command line -- in this case, doable by passing
different target names and variables to 'make' -- then it's something I
can probably have the menu code do also.
But if it's not something you can currently do from the RefDB
command-line toolchain, then I'm reluctant to add it.
But note that it is possible to have the menu code do stuff that would
take multiple steps from the command. For example, what the "Select
Database" does is eliminate the 'listdb' step you'd otherwise need to do
to see the list of available databases in order to know which name to
feed to the selectdb command.
That's probably not the best example (since, realistically, you probably
already know the name of the db you want to use), but you get the idea.
> Let's see:
>
> As with the database menu, styles are drawn from refdb. When one needs
> to process the document but no style is selected, go to the style,
> choose the output option, and the makefile is created, and run with the
> appropriate option.
>
> If later the user needs to change output styles, it involves the same
> process: a simple menu click.
>
> Menu structure might be:
>
> - Process Document
> - Style 1
> - all
> - html
> - pdf
> - xhtml
> - Style 2
> - all
> - html
> - pdf
> - xhtml
Well, I think I really don't want to put style names into the menu --
even if the list of styles is made customizable/extensible. I think it'd
be best just to handle it through Emacs completion.
> I'd like output to be customizable. For example, I sent Bob S. some
> stylesheet customizations that use (x)html + css to fool MS Word into
> thinking it is importing a native doc file. It would be nice, then,
> for me to be able to customize RefDB and its menu so I could have a "MS
> Word" output option.
That sounds great. But I don't have a very clear idea at all how you
could generate a custom output type using the current RefDB toolchain.
Can you describe the steps you're using to generate this output type
now ("fake" Word or whatever you call it)? Are you called refdbxml? Or
are you calling xsltproc or whatever directly? If so, how are you
generating the bibliography for it?
Getting back to the menut, it would be hard to make handle this from the
menu unless you had already created a Makefile for it that had an
additional target in it for your custom output type.
What I could do, I think, is an additional "Other Output Type..." menu
item to the "Generate Output" menu, so it'd look like this:
Generate Output
HTML
PDF
RTF
Other Output Type...
If you select "Other Output Type", Emacs then prompts you for the name
of the output type, which would need to be a custom target you've added
to your Makefile, and would need to be formatted exactly as it appears
in the Makekfile -- so "doc" or whatever you call the target.
hmm, but looking at the toolchain now, I see that it seems like the
transform scripts (refdbxml and refdbjade) would also need to be made
aware of the stylesheet for your custom output type...
Unless I'm missing something, it's starting to look to me like it'd be
difficult to generate a custom output type using the current RefDB
toolchain. It'll help me if you can explain how you're doing it now.
As far as this specific case goes, it seems to me like your "MS Word"
output type is something that ulimately maybe should be added to the
"standard" RefDB set of supported output types. I think that'd amount to
getting your stylesheet into the standard RefDB distro, and adjusting
the makefile template and maybe adjusting refdbxml.
--Mike
|
|
From: Michael S. <sm...@xm...> - 2003-12-11 00:06:48
|
Markus Hoenicka <mar...@mh...> writes: > Michael Smith writes: > > It seems like nothing much actually needs to be changed in the RefDB > > tool chain to support processing a doc that uses XIncludes. > > > > I think the only toolchain fix needed is to change a couple lines in > > refdbxml so that it always calls xsltproc with the "--xinclude" option. > > > > If this is all it takes, then it's a no-brainer. I assume it doesn't > hurt to use the --xinclude option even if the file does not contain > Xincludes? Right -- if you run it on a doc that doesn't actually have any Xincludes in it, it just processes it the same way it would have if you hadn't specified the --xinclude option at all. I guess it may have some small impact on performance, but I don't think most people care about that too much when generating output -- and xsltproc is already very fast. --Mike |
|
From: Markus H. <mar...@mh...> - 2003-12-11 21:03:36
|
Michael Smith writes: > > If this is all it takes, then it's a no-brainer. I assume it doesn't > > hurt to use the --xinclude option even if the file does not contain > > Xincludes? > > Right -- if you run it on a doc that doesn't actually have any Xincludes > in it, it just processes it the same way it would have if you hadn't > specified the --xinclude option at all. > Fine. I just added the switch to refdbxml. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Bruce D'A. <bd...@fa...> - 2003-12-11 02:27:10
|
On Dec 10, 2003, at 8:29 PM, Michael Smith wrote: > As far as this specific case goes, it seems to me like your "MS Word" > output type is something that ulimately maybe should be added to the > "standard" RefDB set of supported output types. I think that'd amount > to > getting your stylesheet into the standard RefDB distro, and adjusting > the makefile template and maybe adjusting refdbxml. Yeah, that might be good. For the record, I'm not using this stuff with RefDB yet, which is partly why I mention it (in case Markus has input on this issue). Indeed, a lot of my ideas may be more about RefDB than about its menu. So, I agree Mike: the menu should not go out of the way to do stuff for the user, but should just be a nice front-end for existing functionality. Markus, how would custom stylesheets be used with RefDB? In the Word example, all it does is use modified versions of the block and footnote xsl files, and then a special Word-tailored CSS file. I really wish this was included in the default DocBook (x)html stylesheets as a parameter option, frankly. More at: http://sourceforge.net/tracker/index.php? func=detail&aid=810043&group_id=21935&atid=373750 Bruce |
|
From: Markus H. <mar...@mh...> - 2003-12-11 21:03:45
|
Bruce D'Arcus writes: > Markus, how would custom stylesheets be used with RefDB? In the Word > example, all it does is use modified versions of the block and footnote > xsl files, and then a special Word-tailored CSS file. I really wish > this was included in the default DocBook (x)html stylesheets as a > parameter option, frankly. > Depends on whether you want to use the custom stylesheets as a default or just once in a while. The latter isn't that easy, but using them always amounts to pointing refdbxml to the modified versions instead of to the stock DocBook stylesheets. You just need to edit the marked section at the top of that script. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Bruce D'A. <bd...@fa...> - 2003-12-13 01:25:05
|
On Dec 11, 2003, at 3:26 PM, Markus Hoenicka wrote: > Michael Smith writes: >> That makes sense. As I mentioned, I think also you might need to add >> some logic for asking whether the existing doc uses short or full >> notations, since there's not guarantee that the user has followed the >> '*.short.*' convention that the current generated Makefiles expect for >> short-notation documents. > > Ok, I'll rework the script along these lines. Once support for the new biblioref element is added, the distinction between the two will evaporate; right? Bruce |
|
From: Markus H. <mar...@mh...> - 2003-12-13 21:15:37
|
Bruce D'Arcus writes: > Once support for the new biblioref element is added, the distinction > between the two will evaporate; right? > Basically yes. There's just the issue of first vs. subsequent citations of the same reference that I'll have to deal with in a different way. But Peter claims this is doable in XSLT, so this must work as well in DSSSL. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X