DocBookInConTeXt customization?
Hi! I'm interested how one can customize output when using DocBookInConTeXt module? With XSL DocBook stylesheets, one can pass certain parameters or build his own customization layer on the stylesheets, and thereby customize output. In README file it is stated: "The mapping translates the XML file internally to a context ..", so I'm interested (pls. excuse me if it's a stupid question) is it possible to just convert DocBook input file into ConTeXt format or/and how isone supposed to tailor output according to his/her preferences? Sincerely, Gour -- Gour gour@mail.inet.hr Registered Linux User #278493
On Sunday, December 8, 2002, at 10:12 AM, Gour wrote:
it possible to just convert DocBook input file into ConTeXt format or/and how isone supposed to tailor output according to his/her preferences?
In my little experience with this, it seems you'd want a module (or is an environment better?) that specifies the formatting for the document (just as you would for any ConTeXt document). This works perfectly for those structures that ConTeXt supports, but not for those that it doesn't (author, subtitle, abstract, epigraph, etc., etc.). Bruce
Bruce D'Arcus (bdarcus@fastmail.fm) wrote:
In my little experience with this, it seems you'd want a module (or is an environment better?) that specifies the formatting for the document (just as you would for any ConTeXt document). This works perfectly for those structures that ConTeXt supports, but not for those that it doesn't (author, subtitle, abstract, epigraph, etc., etc.).
I'd like something like: dic* DocBook -------> ConTeXt ----> output *dic = DocBookInConTeXt module which is similar to XSL toolchain: xslt fop DocBook ------> XSL-FO -----> output with the exception that ConTeXt format is more user-friendly & capable than xsl-fo format, and produces best quality output. In this way, we have best of both worlds :-) ie. one can use & automatically process DocBook-authored documents to get high quality. If it is possible to get ConTeXt *.tex file after processing DocBook *.xml file with DocBookInConTeXt module (of course, for those structures that are supportedin it), I'd like to know how? Btw, I consider that providing DocBook (xml) as an input format will bring many more users to ConTeXt because high-quality output is what prevents many to use DocBook as an authoring tool (besides those who are rich enough to buy commercial FO engines - mostly corporate users). With time, one can also expect that DocBookInConText module will get more users' input and be able to map more DocBook elements. Sincerely, Gour -- Gour gour@mail.inet.hr Registered Linux User #278493
On Sunday, December 8, 2002, at 02:54 PM, Gour wrote:
If it is possible to get ConTeXt *.tex file after processing DocBook *.xml file with DocBookInConTeXt module (of course, for those structures that are supportedin it), I'd like to know how?
I think we'd need to use XSLT to get that. My understanding is that the module simply tells ConTeXt how to process the DocBook code. Maybe someone will correct me though... This is why I posted the note about tbook; thinking perhaps the XSL files from that project -- or from a similar project for DocBook that I vaguely remember -- could be tweaked to output ConTeXt code... Bruce
Bruce D'Arcus (bdarcus@fastmail.fm) wrote:
I think we'd need to use XSLT to get that. My understanding is that the module simply tells ConTeXt how to process the DocBook code. Maybe someone will correct me though...
In that case, without direct DocBook support in ConTeXt, I assume it would be more useful to have module just output ConTeXt code which can be further customized.
This is why I posted the note about tbook; thinking perhaps the XSL files from that project -- or from a similar project for DocBook that I vaguely remember -- could be tweaked to output ConTeXt code...
The only thing is that tbook does the opposite - it converts tbook code into DocBook :-( Sincerely, Gour -- Gour gour@mail.inet.hr Registered Linux User #278493
On Sunday, December 8, 2002, at 03:48 PM, Gour wrote:
This is why I posted the note about tbook; thinking perhaps the XSL files from that project -- or from a similar project for DocBook that I vaguely remember -- could be tweaked to output ConTeXt code...
The only thing is that tbook does the opposite - it converts tbook code into DocBook :-(
Well, it converts to LaTeX, XHTML and DocBook. In theory, then, you could modify the LaTeX XSLT files to output ConTeXt. Since you are interested in DocBook authoring, perhaps you could look at something similar with this: http://db2latex.sourceforge.net/ Bruce
Bruce D'Arcus (bdarcus@fastmail.fm) wrote:
Well, it converts to LaTeX, XHTML and DocBook. In theory, then, you could modify the LaTeX XSLT files to output ConTeXt. Since you are interested in DocBook authoring, perhaps you could look at something similar with this:
I know about this one. It is used as a frame for db2lyx stylesheets. However, seeing that LyX is going nowhere with XML, and because of many problems with clashing of LaTeX packages (and because I see the latest utf-8 support in ConTeXt), I'm definitely going ConTeXt way :-) Sincerely, Gour -- Gour gour@mail.inet.hr Registered Linux User #278493
On Sun, Dec 08, 2002 at 08:54:29PM +0100, Gour wrote:
I'd like something like:
dic* DocBook -------> ConTeXt ----> output
*dic = DocBookInConTeXt module
It is like you say at the top, but the context document is built on the fly, i.e., it only exists in memory, and it never exists in its entirety. It may be better to think of the XML file as the input file for context. This is possible because the < is an active character that invokes macro processing. Context's XML layer enables the conversion author to write a mapping from XML tag to context commands: when that tag is read, the corresponding context commands are invoked. As Hans replies in a later email in this thread, the best strategy is to map to existing context environments. I have done this as much as possible. Then you can customize that environment after reading the docbook module but before the XML file is input. For example, docbook tables are typeset using context's 'natural table' environment. So, if you would set \setupTABLE[background=color,backgroundcolor=red], you would get that (according to theory, I still have to test that). I test the docbook module with a tex file containing the following lines after inputing the docbook module: \setupinteraction[state=start,color=blue] \setupindenting[medium] \setupheadertexts[section][pagenumber] \setupheader[leftwidth=.7\hsize,style=slanted] \setuppagenumbering[location=] \setupitemize[each][packed][before=,after=,indentnext=no] The table element also shows that you cannot arbitrarily customize the output. The docbook module reads the colspec and col- and rowsep settings from the table in the XML file, and applies the appropriate settings, thus overwriting your settings. In this case that is appropriate, because the XML file has priority over your settings. I will try to document the customization options for the docbook module somewhere after Christmas.
which is similar to XSL toolchain:
xslt fop DocBook ------> XSL-FO -----> output
with the exception that ConTeXt format is more user-friendly & capable than xsl-fo format, and produces best quality output.
I am not sure that this is a good parallel. FO's are not customizable; the XSLT stylesheets may be. And context could serve as the FO processor, by the same mechanism of a mapping of FO's to context, if someone would write it. That is what PassiveTeX does for latex.
With time, one can also expect that DocBookInConText module will get more users' input and be able to map more DocBook elements.
That would be welcome. Regards, Simon -- Simon Pepping email: spepping@scaprea.hobby.nl
Simon Pepping (spepping@scaprea.hobby.nl) wrote:
It is like you say at the top, but the context document is built on the fly, i.e., it only exists in memory, and it never exists in its entirety. It may be better to think of the XML file as the input file for context. This is possible because the < is an active character that invokes macro processing. Context's XML layer enables the conversion author to write a mapping from XML tag to context commands: when that tag is read, the corresponding context commands are invoked.
It would be nice to just have an ability to output context's "on-the-fly" document.
I will try to document the customization options for the docbook module somewhere after Christmas.
That would be very hlepful.
which is similar to XSL toolchain:
xslt fop DocBook ------> XSL-FO -----> output
with the exception that ConTeXt format is more user-friendly & capable than xsl-fo format, and produces best quality output.
I am not sure that this is a good parallel. FO's are not customizable; the XSLT stylesheets may be. And context could serve as the FO processor, by the same mechanism of a mapping of FO's to context, if someone would write it. That is what PassiveTeX does for latex.
I agree it's not the best parallel, but there is lot of space to customize XSLT stylesheets which produce FO file. The point is that the first diagram should look like: dic ConTeXt DocBook -------> *.tex --------> output The point is clear: allow users which use DocBook, as an authoring tool, to havebenfit of Con(TeX)t typeset engine. I hoped that LyX would go this route to extend its usage for XML (DocBook), but at the moment developers are too occupied by GUI stuff. TeX & ConTeXt are great but they have some learning curve for average users, but by enabling DocBook authors to produce high-quality PDFs with some reasonable defaults, plus the ability to customize the output for power users (like XSLT DocBook customization layer), I'm sure it will drastically increase number of ConTeXt users and provide to new perspective to TeX publishing in general. The similar thing will happen with latest Hans' development and providing utf-8 support. Sincerely, Gour -- Gour gour@mail.inet.hr Registered Linux User #278493
On Tuesday, December 10, 2002, at 11:53 AM, Gour wrote:
TeX & ConTeXt are great but they have some learning curve for average users, but by enabling DocBook authors to produce high-quality PDFs with some reasonable defaults, plus the ability to customize the output for power users (like XSLT DocBook customization layer), I'm sure it will drastically increase number of ConTeXt users and provide to new perspective to TeX publishing in general.
The similar thing will happen with latest Hans' development and providing utf-8 support.
I agree all of these developments are really good things! For it to me more flexible and accessible, the end point ought to be (and I'm pretty sure it is): 1) Simon's project is more-or-less complete (as in, it supports most commonly used structures in DocBook, and does it reliably). 2) Hans adds the additional structures perviously discussed to ConTeXt, and provides standard modules for books and articles. 3) There is an easy way to run ConTeXt on a DocBook file and to have a switch for the formatting module, perhaps with options... Bruce
At 05:53 PM 12/10/2002 +0100, you wrote:
I am not sure that this is a good parallel. FO's are not customizable; the XSLT stylesheets may be. And context could serve as the FO processor, by the same mechanism of a mapping of FO's to context, if someone would write it. That is what PassiveTeX does for latex.
I agree it's not the best parallel, but there is lot of space to customize XSLT stylesheets which produce FO file.
i will look into that later; if fo's got implemented, they will definitely be configurable (beyond what fo currently offers) Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
On Tue, Dec 10, 2002 at 05:53:08PM +0100, Gour wrote:
Simon Pepping (spepping@scaprea.hobby.nl) wrote: The point is that the first diagram should look like:
dic ConTeXt DocBook -------> *.tex --------> output
The point is clear: allow users which use DocBook, as an authoring tool, to havebenfit of Con(TeX)t typeset engine.
That is against the idea; the tex document never exists really. I admit that formatting a document via environments that only exist on the fly and that you never get to see, is cumbersome, and for many users a no-go. Perhaps it may be made possible to write the generated commands to a tex file instead of executing them, although that will not be easy to achieve. It would help users to debug their customization. It would also help them to maintain the bad habit of always going the route of the explicit tex document and editing that. Such a bad habit would turn a process that is fast and efficient, into a process that is cumbersome and awkward. Regards, Simon -- Simon Pepping email: spepping@scaprea.hobby.nl
Simon Pepping (spepping@scaprea.hobby.nl) wrote:
It would also help them to maintain the bad habit of always going the route of the explicit tex document and editing that. Such a bad habit would turn a process that is fast and efficient, into a process that is cumbersome and awkward.
I must admit that I don't understand why having tex document is a bad habit? Those who are authoring in ConTeXt (not DocBook) have source file (*.tex) and they can tailor output according to their preferences. Otoh, DocBook document does not say much about the form - it's just a valid structure and therefore there are XSL stylesheets to enable one to customize his/her output. Without that, all the DocBook documents will look the same. So, I don't know what's wrong with the idea to customize the output when going via ConTeXt route :-[ Sincerely, Gour -- Gour gour@mail.inet.hr Registered Linux User #278493
On Thursday, December 12, 2002, at 05:34 AM, Gour wrote:
Otoh, DocBook document does not say much about the form - it's just a valid structure and therefore there are XSL stylesheets to enable one to customize his/her output. Without that, all the DocBook documents will look the same.
So, I don't know what's wrong with the idea to customize the output when going via ConTeXt route :-[
? As was already explained (a few times): You customize output just as you customize ANY ConTeXt output. There's no need for a tex output file. Bruce
Bruce D'Arcus (bdarcus@fastmail.fm) wrote:
As was already explained (a few times):
You customize output just as you customize ANY ConTeXt output. There's no need for a tex output file.
Ahh.. It seems that we have communication breakdown. When I say "*.tex" I mean ConTeXT input file, not TeX file and what I would like is that DocBookInConTeXt module produce valid ConTeXt file which is the result of applying mapping from DocBook to ConTeXt, ie. physical file not on-the-fly converting. The whole meaning of using ConTeXt (or LaTeX) is to avoid direct TeX typesetting and makes process easier, so I definitely never though about TeX output file. And the question remains: how to customize output when the translation is done internally? Sincerely, Gour ps. It seems I'm too stupid at the moment to understand the issue :-(( -- Gour gour@mail.inet.hr Registered Linux User #278493
On Thursday, December 12, 2002, at 08:29 AM, scarso luigi wrote:
Hence, the only way to specify formatting informations must be in a xml docbook document, not manipulating intermediate stylesheets that will corrupt the portability of a document.
Maybe I misunderstand, but I don't agree. You code for structure in DocBook, but you need the formatting handled externally: in a CSS file for HTML, and a ConTeXt environment/module (I'm not clear on the difference) for PDF via ConTeXt. If not, you lose flexibility. Like I say, though, perhaps I am missing your point... Bruce
Il gio, 2002-12-12 alle 14:49, Bruce D'Arcus ha scritto:
On Thursday, December 12, 2002, at 08:29 AM, scarso luigi wrote:
Hence, the only way to specify formatting informations must be in a xml docbook document, not manipulating intermediate stylesheets that will corrupt the portability of a document.
Maybe I misunderstand, but I don't agree. You code for structure in DocBook, but you need the formatting handled externally: in a CSS file for HTML, and a ConTeXt environment/module (I'm not clear on the difference) for PDF via ConTeXt. If not, you lose flexibility.
The module is xtag-docbook-literals-en.tex ( DocBookInConTeXt in my draw) luigi
On Thu, Dec 12, 2002 at 08:49:50AM -0500, Bruce D'Arcus wrote:
On Thursday, December 12, 2002, at 08:29 AM, scarso luigi wrote:
Hence, the only way to specify formatting informations must be in a xml docbook document, not manipulating intermediate stylesheets that will corrupt the portability of a document.
Maybe I misunderstand, but I don't agree. You code for structure in DocBook, but you need the formatting handled externally: in a CSS file for HTML, and a ConTeXt environment/module (I'm not clear on the difference) for PDF via ConTeXt. If not, you lose flexibility.
I agree with this point of view: formatting preferences are expressed by customizing style sheets. I will do my best to enable context's customizations in the docbook module. But it remains a virtual exercise: you customize a TeX file that is never written out. For experienced context users that may be easy. For others that is not a trivial task: They must visualize a file in a language that they do not know well. (In FO it is a bit the same; you do not usually see the FO file, although you can.) Regards, Simon -- Simon Pepping email: spepping@scaprea.hobby.nl
I agree with this point of view: formatting preferences are expressed by customizing style sheets.
Maybe an example can help: <imagedata> has width and height attributes that are, in my point of view, formatting preferences: a user should be use these and not manipulate the style sheet (for example by imposing a fit for every image in the style sheet). But, again for example, variations like bold etc are not into semantic of docbook: a xml document can use proc.instructions or role attr. (ex. <para role="bold" >) to carry this informations to (ConTeXt) engine, but they still remains specific for that engine with a style sheet and there are no guarantees that they will be understand by a different engine. This actually is a limit of docbook in portability : if a user make a xml document with a bold specification in somepoint (with role or proc.instr.) he may expect that bold will be renderer by every engine, but it's not true. Perhaps the questions is how to fill the empties in docbook (infact, we have got xml element for sectioning, tables, images etc) by a simple way for a normal user or, put in another way, if a feature is in xml DocBook you should be use it, if no ask yourself if it's needed and, if yes use a xml construct (from a standard set) to signalling this to ConTexT engine; but in the last case you loose portability. or not ? luigi
At 01:57 PM 12/13/2002 +0100, scarso luigi wrote:
Perhaps the questions is how to fill the empties in docbook (infact, we have got xml element for sectioning, tables, images etc) by a simple way for a normal user or, put in another way, if a feature is in xml DocBook you should be use it, if no ask yourself if it's needed and, if yes use a xml construct (from a standard set) to signalling this to ConTexT engine; but in the last case you loose portability.
a nice example is sectioning: you can map 'somedocbooksection' onto 'section', but better is to do something \definesection[dbksection][section] and map 'somedocbooksection' onto 'dkbsection' the advantage is that one can promote dbksection to chapter of degrade it to subsubsubsection, which is handy if you combine multiple docbooks into one. Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
On Fri, Dec 13, 2002 at 01:57:21PM +0100, scarso luigi wrote:
I agree with this point of view: formatting preferences are expressed by customizing style sheets.
But, again for example, variations like bold etc are not into semantic of docbook: a xml document can use proc.instructions or role attr. (ex. <para role="bold" >) to carry this informations to (ConTeXt) engine, but they still remains specific for that engine with a style sheet and there are no guarantees that they will be understand by a different engine.
I did not know what to do with such attributes as role, whose range of values is not constrained. Luigi's remark gives me an idea: I should put a hook in the stylesheet for the user's own formatting command. Something like \attributeaction[para][role]. The user could define such an action with something like \defineXMLattributeaction[para][role]. The attribute action should be invoked within a group in order to allow the user to change fonts etc. for this element. Therefore context cannot invoke the attribute action automatically, because it cannot know where it should do so. For example, some mappings for the opening tag invoke \egroup; if the attribute action had been invoked automatically, its scope would be ended immediately. Groeten, Simon -- Simon Pepping email: spepping@scaprea.hobby.nl
I did not know what to do with such attributes as role, whose range of values is not constrained. Luigi's remark gives me an idea: I should put a hook in the stylesheet for the user's own formatting command. Something like \attributeaction[para][role]. The user could define such an action with something like \defineXMLattributeaction[para][role].
The attribute action should be invoked within a group in order to allow the user to change fonts etc. for this element. Therefore context cannot invoke the attribute action automatically, because it cannot know where it should do so. For example, some mappings for the opening tag invoke \egroup; if the attribute action had been invoked automatically, its scope would be ended immediately. When I just start to play with xml/context, I realize a test for table (i'm still playing with it) in which I write something like
<table> <!-- ... other elements --> <row> <entry role="setupentry[nx=2,background=color,backgroundcolor=red]"> blahh blahh </entry> <!-- ... other elements --> </row> <!-- ... other elements --> </table> and define \defineXMLpickup [entry] [role=]% %%Open tag {\expanded{\beforesplitstring{\XMLpar{entry}{role}{}}}\at [\to\Type% % get ..options..] \expanded{\aftersplitstring{\XMLpar{entry}{role}{}}}\at [\to\rawOptions% % get ..options.. \expanded{\beforesplitstring{\rawOptions}}\at ]\to\Options% \doifelse{\Type}{setupentry}% {%then \expanded{\bTD[\Options]} }{%else \bTD% }}% %%Close tag {\eTD} Is your way, Simon ?
On Wed, Dec 18, 2002 at 06:42:00PM +0100, scarso luigi wrote:
When I just start to play with xml/context, I realize a test for table (i'm still playing with it) in which I write something like
<table> <!-- ... other elements --> <row> <entry role="setupentry[nx=2,background=color,backgroundcolor=red]"> blahh blahh </entry> <!-- ... other elements --> </row> <!-- ... other elements --> </table>
and define
\defineXMLpickup [entry] [role=]% %%Open tag {\expanded{\beforesplitstring{\XMLpar{entry}{role}{}}}\at [\to\Type% % get ..options..] \expanded{\aftersplitstring{\XMLpar{entry}{role}{}}}\at [\to\rawOptions% % get ..options.. \expanded{\beforesplitstring{\rawOptions}}\at ]\to\Options% \doifelse{\Type}{setupentry}% {%then \expanded{\bTD[\Options]} }{%else \bTD% }}% %%Close tag {\eTD}
Is your way, Simon ?
I remember this discussion. This is not my kind of XML file, the attribute value is too much written for context. It is useful if it is meant to be an input file for Context, but it is not useful if the XML file is meant to be formatter independent. And I think the code you have to write to use the attribute is too difficult as a user option. I was thinking more about the simple example <para type="rule"> and a simple user command like \defineattributeaction[para][type] {\doifsamestring{\XMLpar{para}{type}{}}{bold}{\bfa}} Regards, Simon -- Simon Pepping email: spepping@scaprea.hobby.nl
I was thinking more about the simple example <para type="rule"> and a simple user command like
\defineattributeaction[para][type] {\doifsamestring{\XMLpar{para}{type}{}}{bold}{\bfa}}
I agree with you and Hans (use of processing-instructions); my code is a dirty trick for last-minute corrections luigi
At 06:42 PM 12/18/2002 +0100, you wrote:
<entry role="setupentry[nx=2,background=color,backgroundcolor=red]">
a fuzzy way of using attributes how about using pi's: \starttext \startXMLdata \stopXMLdata \stoptext Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
On Thu, Dec 12, 2002 at 02:29:30PM +0100, scarso luigi wrote:
I just started to study <table> env. in DBinConTeXt, so what about <colspec> and <spanspec> ?
table(frame,colsep,rowsep), tgroup(align,colsep,rowsep), thead(align,colsep,rowsep), tbody(align,colsep,rowsep), tfoot(align,colsep,rowsep), colspec(colnum,align,colsep,rowsep), row(rowsep), entry(align,colsep,rowsep) all work. spanspec is not implemented. It is not in the soext table and so is considered to be outside the always implemented set of elements. Regards, Simon -- Simon Pepping email: spepping@scaprea.hobby.nl
At 10:32 AM 12/8/2002 -0500, you wrote:
On Sunday, December 8, 2002, at 10:12 AM, Gour wrote:
it possible to just convert DocBook input file into ConTeXt format or/and how isone supposed to tailor output according to his/her preferences?
In my little experience with this, it seems you'd want a module (or is an environment better?) that specifies the formatting for the document (just as you would for any ConTeXt document). This works perfectly for those structures that ConTeXt supports, but not for those that it doesn't (author, subtitle, abstract, epigraph, etc., etc.).
the best way is to map docbook things onto configurable context commands (i'll something like that with tei); once the docbook module is ready for such an overhaul, i'll look into it. [this is normally the way we map xml to tex; it gives you reasonable defaults, but complete configurability; time ...] Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
Hans Hagen (pragma@wxs.nl) wrote:
the best way is to map docbook things onto configurable context commands (i'll something like that with tei); once the docbook module is ready for such an overhaul, i'll look into it. [this is normally the way we map xml to tex; it gives you reasonable defaults, but complete configurability; time ...]
That will be great!! Patience, patience .. :-) Sincerely, Gour -- Gour gour@mail.inet.hr Registered Linux User #278493
participants (5)
-
Bruce D'Arcus -
Gour -
Hans Hagen -
scarso luigi -
Simon Pepping