Re: [docbook-apps] Image manipulation via XSLT extensions

[Colin Shapiro]

On 8/17/07, Tony Graham <[EMAIL PROTECTED]> wrote:

> An XSLT transform to read XML and generate a batch file or shell script
> is probably a common occurrence: I do it quite often.



You know, that's something I've never actually thought of before.  Just have
a stylesheet generate a shell script...

Here I am trying to come up with elaborate workarounds, and this is much
simpler.  Just match imagedata elements, and produce a line using the value
of @fileref.

Thanks, you gave me some good ideas to work with.

Colin

Re: [docbook-apps] Image manipulation via XSLT extensions

[Colin Shapiro]

Yes, I considered using my build system as well (in my case, a makefile) to
run ImageMagick commands before running the XSLT processor.  This is
definitely the easiest way I could run external programs.

However, the locations of the images (as given by the fileref attributes in
the XML document) are not known until processing time.  So, if I want to run
another command on these images before XSLT time, I would need to first
parse the XML document for the image locations with something like
XMLStarlet (or even just grep and sed), run the commands, then finally run
the XSLT processor.  That would work, but not as nicely as doing everything
at XSLT processing time.

Perhaps Ant might be a better build solution than make, however.  I will
look into it.

Colin

On 8/17/07, David Cramer <[EMAIL PROTECTED]> wrote:
>
>  We do what you propose, but use our build system (an ant script) to call
> batik http://xmlgraphics.apache.org/batik/ and rasterize the images when
> going to html. The way we have it set up, when you insert the svg image in
> XMetaL, a macro sees it's an svg and pops up a dialog asking if you want it
> rasterized. If so, it converts it to a png and displays the png (since
> XMetaL can't display svg !?!). The system also runs an xslt on svgs that
> come from Visio to workaround a Visio bug that causes arrowheads not to
> appear in pngs rasterized from Visio svg source.
>
> I understand that Inkscape http://www.inkscape.org/ can also convert svgs
> to other formats from the command line, but I haven't tried it.
>
> David
>
>  --
> *From:* Colin Shapiro [mailto:[EMAIL PROTECTED]
> *Sent:* Friday, August 17, 2007 10:24 AM
> *To:* docbook-apps@lists.oasis-open.org
> *Subject:* [docbook-apps] Image manipulation via XSLT extensions
>
> Hello,
>
> "Unfortunately, there is no single graphics file format that meets all
> needs."  - Bob
>
> Bob is right.  One of the biggest annoyances I have when writing documents
> is that, when I want to insert a graphic, I must reference and maintain
> multiple versions of the image file in order to accommodate the various
> types of output I am producing:
>
> 
>   
> 
>   
>   
> 
>   
> 
>
> Let's say I created a figure in SVG, as in the above example.  This SVG is
> my original image source, and in a perfect world, it would be all I'd need
> to carry around.  But, since we can't trust SVGs with our web browsers, I
> must convert it to PNG and carry around another version of the file for HTML
> output.
>
> What if I actually could only keep the SVG, and have the stylesheet
> somehow convert the image to alternate formats as needed?  If I run the HTML
> stylesheet, it sees an SVG, and calls an external program--say,
> ImageMagick--to convert the file to a PNG.
>
> This leads me to my question.  I know that with processors like Saxon and
> Xalan, you can write extensions in Java/JavaScript.  It seems to me that one
> would be able to write an extension to call ImageMagick as needed.  However,
> I have absolutely no experience with XSLT extensions, and don't really know
> where to start.
>
> I do know where to find resources on the subject.  However, I thought I
> would first post here to see if anyone has done anything similar, or thought
> about anything like this before.
>
> - Colin
>
>

[docbook-apps] Image manipulation via XSLT extensions

[Colin Shapiro]

Hello,

"Unfortunately, there is no single graphics file format that meets all
needs."  - Bob

Bob is right.  One of the biggest annoyances I have when writing documents
is that, when I want to insert a graphic, I must reference and maintain
multiple versions of the image file in order to accommodate the various
types of output I am producing:


  

  
  

  


Let's say I created a figure in SVG, as in the above example.  This SVG is
my original image source, and in a perfect world, it would be all I'd need
to carry around.  But, since we can't trust SVGs with our web browsers, I
must convert it to PNG and carry around another version of the file for HTML
output.

What if I actually could only keep the SVG, and have the stylesheet somehow
convert the image to alternate formats as needed?  If I run the HTML
stylesheet, it sees an SVG, and calls an external program--say,
ImageMagick--to convert the file to a PNG.

This leads me to my question.  I know that with processors like Saxon and
Xalan, you can write extensions in Java/JavaScript.  It seems to me that one
would be able to write an extension to call ImageMagick as needed.  However,
I have absolutely no experience with XSLT extensions, and don't really know
where to start.

I do know where to find resources on the subject.  However, I thought I
would first post here to see if anyone has done anything similar, or thought
about anything like this before.

- Colin

Re: [docbook-apps] Any source of Plain-text stylesheets?

[Colin Shapiro]

Hi,

I'm not quite sure what you're asking for.  If you want a stylesheet that
simply returns the text from an XML document and does nothing else, then I
believe something as simple as:


  


...would suffice.  Unless you want it in some specific format?  Please
elaborate a little further and I'm sure someone can help you more.

Colin

On 8/12/07, Tommy Nordgren <[EMAIL PROTECTED]> wrote:
>
> I need to find docbook stylesheets that can strip off xml markup, as
> well as any content that is not plaintext.
> Do someone on this list know of any such source.
> Alternately, do some one know of any grammar checker for the english
> language, hosted on Mac OS X,
> that retains xml markup.
>
> -
> This sig is dedicated to the advancement of Nuclear Power
> Tommy Nordgren
> [EMAIL PROTECTED]
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: [docbook-apps] Balanced last page in two column output

[Colin Shapiro]

I can confirm that Ken's solution works with FOP (I accidentally discovered
this myself):

"Yes, include an empty spanned block at the end of your flow. The formatter
will try to balance all of your columns on top of this empty block. Modulo
keeps, breaks, widows, orphans, etc."

With XEP, you can omit the empty spanned block and just use a flow-section
(one of the RenderX extensions).  The columns inside of your flow-section
will be balanced.

- Colin

On 7/31/07, David Cramer <[EMAIL PROTECTED]> wrote:
>
> I haven't tried this or looked into how you'd do it in the docbook xsls
> (or if it would work in fop), but I happened to remember that Ken has
> posted this on the xep list, so it was easy for me to find again:
> http://www.renderx.net/lists/xep-support/1119.html
>
> If you get it to work, please share the solution. It stuck in my mind
> because a writer had asked about it wrt to our two column indexes. I
> think it would be good default behavior for the stylesheets.
>
> Thanks,
> David
>
> > -Original Message-
> > From: Dick Hamilton [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, July 31, 2007 7:25 PM
> > To: docbook-apps@lists.oasis-open.org
> > Subject: [docbook-apps] Balanced last page in two column output
> >
> > I'm working on a stylesheet to transform a DocBook article
> > into the form the ACM uses for its SIG proceedings.  The
> > specification uses a two-column format and says, "Columns on
> > the last page should be made as close as possible to equal length."
> >
> > After searching around some, I couldn't find any good
> > references on how to do this.  Does anyone know if it can be
> > done, and if so, how to do it?
> >
> > If it makes any difference, I'm using DocBook 5.0, the 1.73.0
> > stylesheets, Saxon 6.5.3, and FOP 0.93 on Linux.
> >
> > Thanks,
> > Dick Hamilton
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

[docbook-apps] FO processors and box stacking (Z-axis layering)

[Colin Shapiro]

Hi,

I have noticed that different processors treat box stacking (the layering of
objects along the "Z-axis") differently when using positioned blocks.

FOP does not accept the z-index property, which means that you must be
careful how you place your blocks, as the order in which you write them will
determine how they stack.  For example:


  UNDER

OVER

When processed with FOP, the text "UNDER" appears underneath the text
"OVER".  However, when processed with XEP, the text "OVER" appears
underneath the text "UNDER".  With XEP, you must use the z-index property to
produce the desired output:


  UNDER

OVER

You can see some more complex examples here:
http://www.ecrion.com/Support/Resources/XSL-FOTutorial/AbsolutePositioning.xml.html.
If you were to process the examples there with XEP, you would not get the
same output that is pictured unless you added z-index properties.

I am wondering why XEP does not layer boxes based on the order in which they
are written, as FOP does (and presumably XF as well, given the examples
posted on Ecrion's site).  Of course, with XEP, you can use z-index to fix
this, but sometimes that is not ideal as you will then break FOP
compatibility.

I guess this isn't so much a question as it is an observation.  But perhaps
someone can give some insight, as I would like to write documents that are
compatible with more than one FO processor.

Colin

Re: [docbook-apps] Set an image as a full-page background

[Colin Shapiro]

Hi,

I have done this, but only in one specific way using XEP.  I did this using
a block-container with a fixed position, a hieght/width of the full page,
and a z-index value to ensure it is below everything else:


  


This can be placed anywhere in a customization layer.  I am not sure how
well this will work with another processor (I know that the z-index property
doesn't work in FOP, anyway).

Hope that helps a little.

Colin

On 7/27/07, Costin Stroie <[EMAIL PROTECTED]> wrote:
>
> Helo
>
> Is it possible to set an image as a full page background, with no margins
> around? It should be placed from the top margin to the bottom (even under
> header and footer) and from the left margin to the righ, not only under
> the content, but stretched on the entire page. For example, for A5 page,
> the image should have 210x148mm.
>
> --
> Costin STROIE
> Linux Technical Writer
> BitDefender
> ---
> E-mail: [EMAIL PROTECTED]
> Phone : (+402) 1 233 07 80
> Mobile: (+40) 722 46 23 79
> ---
> www.bitdefender.com
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

[docbook-apps] Re: [docbook] Element for an author's website URL

[Colin Shapiro]

[Note: I accidentally CCed the wrong list with the below message.
docbook-apps, feel free to ignore.]

"The link is a general purpose hypertext element."

The element I propose has nothing to do with hypertext.  It is simply
another part of an , same as , , etc.  It is another
bit of information about how to contact a person/organization.

If we already have , then why not  or ?  Also remember
that an email address can be displayed as hypertext as well (i.e. a mailto:
link in a web browser), but it doesn't have to be.  Same with a home page
URL.  We don't have to use  for an email address within .

Colin

On 7/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


Hi,

> [...]
> > Maybe I am missing something obvious, but why not use link?
>
> Because it's a link, not a URL

But a link can also be a URI/URL. According to the TDG[1]:

  »The link is a general purpose hypertext element. [...]
   If it has an xlink:href attribute, link is the equivalent of an
   HTML anchor () for cross reference
   with a Uniform Resource Identifier (URI).«

Maybe I didn't understand your argument. But why introduce
another element when there is already a general purpose element
for this issue? :-)


Bye,
Tom

--
[1] http://www.docbook.org/tdg5/en/html/link.html

[docbook-apps] Re: [docbook] Element for an author's website URL

[Colin Shapiro]

"The link is a general purpose hypertext element."

The element I propose has nothing to do with hypertext.  It is simply
another part of an , same as , , etc.  It is another
bit of information about how to contact a person/organization.

If we already have , then why not  or ?  Also remember
that an email address can be displayed as hypertext as well (i.e. a mailto:
link in a web browser), but it doesn't have to be.  Same with a home page
URL.  We don't have to use  for an email address within .

Colin

On 7/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


Hi,

> [...]
> > Maybe I am missing something obvious, but why not use link?
>
> Because it's a link, not a URL

But a link can also be a URI/URL. According to the TDG[1]:

  »The link is a general purpose hypertext element. [...]
   If it has an xlink:href attribute, link is the equivalent of an
   HTML anchor () for cross reference
   with a Uniform Resource Identifier (URI).«

Maybe I didn't understand your argument. But why introduce
another element when there is already a general purpose element
for this issue? :-)


Bye,
Tom

--
[1] http://www.docbook.org/tdg5/en/html/link.html

[docbook-apps] Re: Shading columns with a background color

[Colin Shapiro]

I decided to take a different approach with this problem.

I created an SVG image containing three vertical bars, and applied it as a
page background image.  Since my column count may vary, I also created
additional SVGs with different numbers of vertical bars, depending on the
column count.  My stylesheet then uses the column count to select the image,
i.e.


 url(../images/column_shading_
 
 .svg)


Kind of another hokey solution, but I can't figure out any better way to do
this.

Colin

On 7/20/07, Colin Shapiro <[EMAIL PROTECTED]> wrote:


Hi,

I have an XSL-FO document that uses a multi-column page layout.  I'd like
to shade the columns of the page with a background color - only the columns,
not the entire page.  See the attached image for a sketch of what I want the
output to look like.

Now, the simplest way to do this is to give the blocks containing the
running content a background color:


  Blah blah blah blah...


However, this only shades the columns to the point where the running
content stops.  Rather, I want the full length of the columns to be shaded
regardless of whether there is any running content.

I eventually came up with the following hokey solution.  It is a template
that calls itself recursively as many times as the number of columns, and
draws a block-container with absolute position for each column:






  

  


  

  



  



  

  

  

pt
  
  



  

  


This actually worked if I called this template before other templates that
generate running content.  This template would draw the colored bars, then
the content would be placed on top of them.

However, since I switched from FOP to XEP, this no longer works.  The
colored bars are drawn as expected, but they are drawn right over the
running content, making the content invisible.

Any clue how I could be doing this in a better, saner way?  All I want to
do is shade the columns with a background color.  If anyone has an idea,
please let me know.  Thanks.

[docbook-apps] Re: Shading columns with a background color

[Colin Shapiro]

My apologies, I had some typos in the code I posted.  Here it is again:






 
   
 


 
   
 



 



 

 
   
 
   
   pt
 
 
   

   
 
   
 

Re: [docbook-apps] FOP vs Saxon?

[Colin Shapiro]

Er... isn't Saxon an XSLT processor?

I know there are multiple versions of Saxon, so maybe I'm missing something,
but I do believe these two applications are for different purposes.

Colin

On 6/26/07, Linux Solutions <[EMAIL PROTECTED]> wrote:


Hello,

I'm using docbook5 and FOP 0.93 to generate PDF. I was wondering what the
differences between Saxon and FOP is and if Saxon will generate better
PDF's?

Any help is appreciated. Also, any ETA on docbook5-xsl 1.72.1? I see there
are a few fixes in there.

Thanks,
Josh

Re: [docbook-apps] How to center a table?

[Colin Shapiro]

I should add that this wasn't with DocBook that I used this method (I
replied without realizing), so this may not help you figure out how to
customize the DocBook templates.

Colin

On 5/25/07, Colin Shapiro <[EMAIL PROTECTED]> wrote:


Hi,

The method shown on the FOP website has worked for me in the past (using
FOP, of course):
http://xmlgraphics.apache.org/fop/fo.html#fo-center-table-horizon

Colin

On 5/25/07, Ellen Juhlin <[EMAIL PROTECTED]> wrote:
>
> Hello friendly list people,
>
>
> I know this topic has come up in the past a few times, but none of the
> solutions I've found seem to be working out. I'm trying to center a table
> horizontally on a page. I'm using the XSL stylesheets v.1.72, DocBook
> 4.4, and XEP 3.7.7.
>
> I've tried the method listed here:
> http://www.renderx.net/lists/xep-support/1444.html but it seems to
> create three equally-sized columns with my table left-aligned (and
> overflowing) in the middle column. I don't know if I'm "wrapping" the wrong
> template - I tried calsTable, table.layout, and make.table.content, all
> with either the same result, or no effect. I'm sure that I am just missing
> something very minor here... can someone point me in the right direction?
>
> 
> 
>
> 
> 
> 
>  "proportional-column-width(1)"/>
> 
>  "proportional-column-width(1)"/>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
> Please tell me what I am doing wrong!
>
> Thanks,
>
> Ellen
>
>
>  Product Specialist, LCS Series
> Meyer Sound Laboratories
>
>
>
>

Re: [docbook-apps] How to center a table?

[Colin Shapiro]

Hi,

The method shown on the FOP website has worked for me in the past (using
FOP, of course):
http://xmlgraphics.apache.org/fop/fo.html#fo-center-table-horizon

Colin

On 5/25/07, Ellen Juhlin <[EMAIL PROTECTED]> wrote:


Hello friendly list people,


I know this topic has come up in the past a few times, but none of the
solutions I've found seem to be working out. I'm trying to center a table
horizontally on a page. I'm using the XSL stylesheets v.1.72, DocBook 4.4,
and XEP 3.7.7.

I've tried the method listed here:
http://www.renderx.net/lists/xep-support/1444.html but it seems to create
three equally-sized columns with my table left-aligned (and overflowing) in
the middle column. I don't know if I'm "wrapping" the wrong template - I
tried calsTable, table.layout, and make.table.content, all with either the
same result, or no effect. I'm sure that I am just missing something very
minor here... can someone point me in the right direction?



























Please tell me what I am doing wrong!

Thanks,

Ellen


Product Specialist, LCS Series
Meyer Sound Laboratories

Re: [docbook-apps] Background image in header

[Colin Shapiro]

Hi,

The problem is that you're putting the background image attribute in the
header.content template, which is effectively applying it to a regular
fo:block.  Take a look at this fragment of code from the template
header.table.



 ...
 
   
 
 
 
 
   
 


So, everything in header.content is called inside of an fo:block.
Therefore, you're just producing:



and since the fo:block is only as tall as its content, it won't
automatically be as tall as $region.before.extent.

If you only want this background image to appear in the header of certain
types of pages (odd or even, etc.), one solution is to make a custom page
master (http://www.sagehill.net/docbookxsl/PageDesign.html) and apply the
background-image attribute to the fo:region-before element.  If you want it
to apply to the header of all pages, you can also customize the
header.tabletemplate and apply the background image to the fo:table
element.

I hope that's what you need.

Colin

On 5/24/07, Daniela Dänzer <[EMAIL PROTECTED]> wrote:


Dear list,

I want to place a background image in the header of my pdf-file.

I managed to put a image in the header and the text in front of it,
but the image is clipped at the top. I first thought, that this is due
to the region.before.extent-parameter not being big enough, but I set
region.before.extent to 50mm which ist definitely a lot greater than
the height of my background image, with no effect.
I also tried to reduce the space for page.margin.top and increasing
the space for body.margin.top, but this didn't work out either.
I already set the padding for the header table cell to 0 everywhere.

Any ideas what I'm doing wrong?

Thats the header.content-template of my customization-layer:


(...)

  resources/header_even_innen.png
  no-repeat
  0cm
  0cm
  0cm
  0cm
  0cm
  0cm
  0cm
  0cm
  right
  bottom
  Text Text Text

(...)


I'm using docbook-xsl 1.72.0, xsltproc and fop 0.93.

Thank you a lot for your help in advance.

Regards,
Daniela

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [docbook-apps] Docbook Editors

[Colin Shapiro]

How can XML editors be WYSIWYG, when there's no way to tell what a document
will look like after XSLT?

Or do they basically do "on-the-fly" transformations, to preview what it
will look like in HTML, in print, etc.?

Just curious.

On 5/14/07, David Cramer (Tech Pubs) <[EMAIL PROTECTED]> wrote:


XMetaL can be scripted to do anything, but it doesn't have many friendly
DocBook macros out of the box. The included demo Journalist DTD is
similar to DocBook and those macros and features can be converted by
renaming some elements. XMLMind's XXE and Syntext's Serna offer much
better DocBook support out of the box. I know Arbortext's Epic has
DocBook support, but I'm not sure what it has out of the box wrt
convenience macros. I think those are the main four commercial wysiwyg
editors these days.

David

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Chris Chiasson
> Sent: Monday, May 14, 2007 10:13 AM
> To: Eitan Zabari
> Cc: docbook-apps@lists.oasis-open.org
> Subject: Re: [docbook-apps] Docbook Editors
>
> XXE? XMetaL?
>
> On 5/14/07, Eitan Zabari <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > I would like to use an editor for writing Docbook,
> preferably WYSIWYG.
> > I used to write Latex with GVIM (non-wysiwyg), but trying to do the
> > same for Docbook XML is too much overhead, code wise.
> > Which editors are used with Docbook? Can anyone please
> recommend? Are
> > there free editors? Are there commercial editors that are good?
> >
> > Thank you in advance.
> >
> > __
> > Eitan Zabari
> > Technical Communicator
> >
> > Jungo Software Technologies
> > E-mail: [EMAIL PROTECTED]
> > Web: http://www.jungo.com
> > Phone: +972-9-8859365 ext. 224
> > Fax: +972-9-8859366
> > Mobile: +972-54-2271318
> >
> >
> >
> >
> -
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> >
> >
>
>
> --
> http://chris.chiasson.name/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [docbook-apps] Re: XML editor very slow with DocBook 5.0

[Colin Shapiro]

Hi George,

Thanks for this information; it's good to hear that this has been fixed.

Out of curiosity, was this a problem even when content completion and
automatic validation were turned off?  It still seemed to be slow even when
I disabled these features.

Thanks,
Colin

On 5/4/07, George Cristian Bina <[EMAIL PROTECTED]> wrote:


Hi Colin,

There is a performance problem indeed and that is caused from the way we
gather the annotations from the DocBook5 Relax NG Schema to be used for
content completion as documentation for the proposed elements,
attributes and values. This was fixed in the current development stream
and it will be available very shortly in version 8.2 (early next week).

Best Regards,
George
-
George Cristian Bina - http://aboutxml.blogspot.com/
 XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com


Colin Shapiro wrote:
> Almost forgot... I'm running the latest version of Oxygen (8.1).
>
> Colin
>
> On 5/3/07, Colin Shapiro <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> Maybe someone can give me a clue here.  I use the  XML editor,
>> and I recently started working with DocBook 5.0.  The software is
*very*
>> slow when working with db5 files.
>>
>> I installed a local copy of the 5.0CR3 schema, and made an entry at the
>> top of Oxygen's "Default Schema Associations" list which points to the
>> local
>> copy of the RNG schema.  I verified that it is using the local copy by
>> unplugging my network cable.  I tried turning off all content
completion
>> features.  Nothing seems to work.
>>
>> Oxygen does run fine with everything else. I have a number of custom
>> RELAX
>> NG schemas which I use (which aren't nearly as complex as DocBook),
>> and my
>> other XML documents validate quickly.  It's not as fast as vi, but it
>> runs
>> reasonably well for a big Java app.
>>
>> Also, I'm using the Sun JRE 6 on Windows.  Eats RAM like a beast, but I
>> have a decent amount (1 GB).
>>
>> Any ideas?
>>
>> Colin
>>
>

[docbook-apps] Re: XML editor very slow with DocBook 5.0

[Colin Shapiro]

Almost forgot... I'm running the latest version of Oxygen (8.1).

Colin

On 5/3/07, Colin Shapiro <[EMAIL PROTECTED]> wrote:


Hi,

Maybe someone can give me a clue here.  I use the  XML editor,
and I recently started working with DocBook 5.0.  The software is *very*
slow when working with db5 files.

I installed a local copy of the 5.0CR3 schema, and made an entry at the
top of Oxygen's "Default Schema Associations" list which points to the local
copy of the RNG schema.  I verified that it is using the local copy by
unplugging my network cable.  I tried turning off all content completion
features.  Nothing seems to work.

Oxygen does run fine with everything else. I have a number of custom RELAX
NG schemas which I use (which aren't nearly as complex as DocBook), and my
other XML documents validate quickly.  It's not as fast as vi, but it runs
reasonably well for a big Java app.

Also, I'm using the Sun JRE 6 on Windows.  Eats RAM like a beast, but I
have a decent amount (1 GB).

Any ideas?

Colin

[docbook-apps] XML editor very slow with DocBook 5.0

[Colin Shapiro]

Hi,

Maybe someone can give me a clue here.  I use the  XML editor, and
I recently started working with DocBook 5.0.  The software is *very* slow
when working with db5 files.

I installed a local copy of the 5.0CR3 schema, and made an entry at the top
of Oxygen's "Default Schema Associations" list which points to the local
copy of the RNG schema.  I verified that it is using the local copy by
unplugging my network cable.  I tried turning off all content completion
features.  Nothing seems to work.

Oxygen does run fine with everything else. I have a number of custom RELAX
NG schemas which I use (which aren't nearly as complex as DocBook), and my
other XML documents validate quickly.  It's not as fast as vi, but it runs
reasonably well for a big Java app.

Also, I'm using the Sun JRE 6 on Windows.  Eats RAM like a beast, but I have
a decent amount (1 GB).

Any ideas?

Colin

Re: [docbook-apps] FW: Re: [docbook] recommend a tag for user accounts in computer documentation?

[Colin Shapiro]

On 5/1/07, David O'Brien <[EMAIL PROTECTED]> wrote:


Hi Colin
How did you manage to nest the markup? Don't you need to escape the
double quotes around "protocol" somehow? My parser is complaining:



Sorry, my example had a typo.  I meant for the nested quotes to be single
quotes:

TCP">

Alternatively, you can swap the double and single quotes around:

TCP'>

Colin

START: test-en-US Wed May  2 11:47:38 EST 2007

tmp/en-US/xml/Release_Notes.ent:2: parser error : xmlParseEntityDecl:
entity httpd not terminated
httpd">

thanks a lot
David


Colin Shapiro wrote:
> Yeah, a minimalist approach has its benefits.  I've tried to take the
same
> approach, however I sometimes later realize that I could have used the
> extra
> markup that I chose to omit.
>
> Now, I do things a little more verbosely, but use many entities.to save
> time.  For example, I'd probably mark up TCP like this:
>
>  class="protocol">TCP">
> The protocol &tcp; is a communications protocol...
>
> My file containing these common entity definitions is shared among
> documents, so if I want to change the way a term is marked up, I can do
so
> across all applicable docs.  And since the bulk of the extra markup is
> removed from the main document, the source files are kept relatively
small.
>
> Just something to think about if you're interested in trying it.  It
works
> well for my needs.
>
> Colin
>
> On 4/30/07, David O'Brien <[EMAIL PROTECTED]> wrote:
>>
>> Colin Shapiro wrote:
>> > Yes, that works as well.
>> >
>> > There are several choices here, and what you actually use will
>> depend on
>> > the
>> > context and what you want to do with the document.  For example, if
all
>> you
>> > want to convey is that the item is a username, then this will
probably
>> > suffice:
>> >
>> > root
>> >
>> > However, if you want to convey that the item is a username *and*
>> that it
>> is
>> > user input, as in "Enter the username 'root' and log in", you may
want
>> to
>> > use one of the following instead:
>> >
>> > root
>> > root
>> >
>> > This is a problem that I frequently have with DocBook; there are
>> often a
>> > number of ways to do something, and I have to think about what I
really
>> > want
>> > to convey with the markup before I can figure out the approach to
use.
>> >
>> > Colin
>> >
>> > On 4/30/07, Skopik Pavel <[EMAIL PROTECTED]> wrote:
>> >>
>> >>
>> >>
>> >> You can also use „systemitem" element which has built-in class
>> >> „username".
>> >>
>> >>
>> >>
>> >> pavel
>> >>
>> >
>> Yes, I have the same trouble in other areas, where something should be
>> tagged as X but it's being used in a different context so it should
also
>> (or instead) be tagged as Y.
>>
>> I tend to take a minimalist or simplistic approach and tag by context,
>> avoiding nesting/multiple tags as much as I can. Case in point? TCP.
>> It's a protocol  but also an abbreviation
>> . I'm leaning away from using  because there is so much
>> of it in computer documentation. Same goes for .
>>
>> cheers
>>
>> --
>> /David
>>
>>
>>
>


--
/David

Re: [docbook-apps] FW: Re: [docbook] recommend a tag for user accounts in computer documentation?

[Colin Shapiro]

Yeah, a minimalist approach has its benefits.  I've tried to take the same
approach, however I sometimes later realize that I could have used the extra
markup that I chose to omit.

Now, I do things a little more verbosely, but use many entities.to save
time.  For example, I'd probably mark up TCP like this:

TCP">
The protocol &tcp; is a communications protocol...

My file containing these common entity definitions is shared among
documents, so if I want to change the way a term is marked up, I can do so
across all applicable docs.  And since the bulk of the extra markup is
removed from the main document, the source files are kept relatively small.

Just something to think about if you're interested in trying it.  It works
well for my needs.

Colin

On 4/30/07, David O'Brien <[EMAIL PROTECTED]> wrote:


Colin Shapiro wrote:
> Yes, that works as well.
>
> There are several choices here, and what you actually use will depend on
> the
> context and what you want to do with the document.  For example, if all
you
> want to convey is that the item is a username, then this will probably
> suffice:
>
> root
>
> However, if you want to convey that the item is a username *and* that it
is
> user input, as in "Enter the username 'root' and log in", you may want
to
> use one of the following instead:
>
> root
> root
>
> This is a problem that I frequently have with DocBook; there are often a
> number of ways to do something, and I have to think about what I really
> want
> to convey with the markup before I can figure out the approach to use.
>
> Colin
>
> On 4/30/07, Skopik Pavel <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> You can also use „systemitem" element which has built-in class
>> „username".
>>
>>
>>
>> pavel
>>
>
Yes, I have the same trouble in other areas, where something should be
tagged as X but it's being used in a different context so it should also
(or instead) be tagged as Y.

I tend to take a minimalist or simplistic approach and tag by context,
avoiding nesting/multiple tags as much as I can. Case in point? TCP.
It's a protocol  but also an abbreviation
. I'm leaning away from using  because there is so much
of it in computer documentation. Same goes for .

cheers

--
/David

Re: [docbook-apps] FW: Re: [docbook] recommend a tag for user accounts in computer documentation?

[Colin Shapiro]

Yes, that works as well.

There are several choices here, and what you actually use will depend on the
context and what you want to do with the document.  For example, if all you
want to convey is that the item is a username, then this will probably
suffice:

root

However, if you want to convey that the item is a username *and* that it is
user input, as in "Enter the username 'root' and log in", you may want to
use one of the following instead:

root
root

This is a problem that I frequently have with DocBook; there are often a
number of ways to do something, and I have to think about what I really want
to convey with the markup before I can figure out the approach to use.

Colin

On 4/30/07, Skopik Pavel <[EMAIL PROTECTED]> wrote:




You can also use „systemitem" element which has built-in class „username".



pavel

[docbook-apps] Re: [docbook] recommend a tag for user accounts in computer documentation?

[Colin Shapiro]

Hi,

I would probably use UserInput or Literal.  You can always add
role="username" to one of these if you want to do something special with
usernames in your document.

Colin

On 4/29/07, David O'Brien <[EMAIL PROTECTED]> wrote:


Hi
I'm looking for recommendations for a suitable tag for user account
names. By way of example:

"Log in as root and run the following command."
"This process runs as the user nobody on Solaris systems."

We're currently using docbook 4.3

Thanks a lot.
--
/David

Re: [docbook-apps] Images in PDF appear too large

[Colin Shapiro]

On 4/27/07, T.G. Mutato <[EMAIL PROTECTED]> wrote:


I think the bottom line here is that specifying pixel dimensions (if
you want to display an image "as-is") isn't too useful with FOP since
there's no way to way to tell FOP to ignore the dpi info. So far just
setting the dpi to 96 in the image files themselves seems to be the
only way to get them to display properly.



Have you tried changing the source-resolution and target-resolution values
in the FOP config file?


72

72

Not sure if this actually makes a difference here, but I've never changes
these settings, so I'm just curious.

Colin

On 4/27/07, Chris Chiasson <[EMAIL PROTECTED]> wrote:

> Assuming the matrix of pixels for an image is fixed, changing the dpi
> of the picture is like telling the receiving application that the
> image takes up different physical sizes:
>
> example:
> A 100 pixel by 100 pixel picture at 100 dpi (in both horizontal and
> vertical directions) = 1 inch by 1 inch picture.
>
> Supplying the same pixels and saying the picture is at 300 dpi will
> give a 1/3 inch by 1/3 inch picture.
>
> This doesn't happen in web browsers because they ignore picture dpi,
AFAIK.
>
> So, it makes sense that your 300 dpi picture is smaller if it has the
> same pixel content as the other pictures.
>
> I assume you already knew all of this and that the scaling attributes
> of DocBook are confusing to you. In that case, can we start over? I am
> lost.
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [docbook-apps] Images in PDF appear too large

[Colin Shapiro]

No, I meant pixels, as I wrote.  It works this way for an image of any size;
if my source image is 800px wide and 600px tall, then the FO



will render my image as 100px wide and 75px tall (preserving the
proportions).

Colin

On 4/26/07, T.G. Mutato <[EMAIL PROTECTED]> wrote:


>  content-width="scale-to-fit"/>

Was this for an image that is 100 pixels wide Colin? Or was the
example meant to say ..."width=100%"...?

Thanks,
tgm

On 4/26/07, Colin Shapiro <[EMAIL PROTECTED]> wrote:
> I'm currently working with a custom stylesheet I wrote from scratch (not
> DocBook) to generate FO from an XML document, and I'm using FOP v0.93
.  I've
> found that the image scaling does work.  If I use the following FO:
>
>  content-width="scale-to-fit"/>
>
> then the image is scaled properly to the given width, and the
proportions
> remain intact.
>
> I haven't looked at the FO produced by the DocBook stylesheets, so this
> doesn't necessarily answer the original poster's question, but FOP can
do
> image scaling in this manner.
>
> Colin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [docbook-apps] Images in PDF appear too large

[Colin Shapiro]

I'm currently working with a custom stylesheet I wrote from scratch (not
DocBook) to generate FO from an XML document, and I'm using FOP v0.93.  I've
found that the image scaling does work.  If I use the following FO:



then the image is scaled properly to the given width, and the proportions
remain intact.

I haven't looked at the FO produced by the DocBook stylesheets, so this
doesn't necessarily answer the original poster's question, but FOP can do
image scaling in this manner.

Colin

On 4/26/07, Chris Chiasson <[EMAIL PROTECTED]> wrote:


I have heard that fop is not so good at obeying the scaling commands.
I can't remember where, though.

On 4/26/07, T.G. Mutato <[EMAIL PROTECTED]> wrote:
> I've been trying to get inline images in a PDF file to appear
> correctly but they always seem to big. I've been following the advice
> in Bob's excellent book (also available at
> http://www.sagehill.net/docbookxsl/ImageSizing.html) and using
>
> 
>   
>  width="100%" contentdepth="100%"/>
>   
> 
>
> So far, no luck; they appear to be scaled bigger than they actually
> are (the actual image is 36 pixels wide by 14 pixels high and has a
> resolution of 72 dpi -- the image appears roughly  1.5 times larger
> than actual when looking at the document on screen or printed out).
> I'm using the XSL 1.72.0 stylesheets and FOP 0.93 on Windows.
>
> Any other ideas on configuration? Maybe I need to include something
> about resolution in the FOP configuration file?
>
> Thanks,
> tgm
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
http://chris.chiasson.name/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [docbook-apps] FOP 0.93 Span="inherit" warning

[Colin Shapiro]

Yeah, the default value of span is "none" (
http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#span).

So, by setting span="inherit" on a child object, you are effectively setting
its span attribute to "none" as well.

I think the FOP developers just designed FOP to output a warning whenever an
"inherit" value is encountered that isn't inheriting an explicitly set
property, even though it is still inheriting the default value as it
should.  Such a warning could be useful for debugging stylesheets.

Colin

On 4/26/07, T.G. Mutato <[EMAIL PROTECTED]> wrote:


I think your right Colin that it's nothing to worry about -- it's just
an annoyance. Interestingly, I manually removed the span="inherit"
from the fo file (it surrounds the Index title) -- the warning from
FOP went away and the PDF file looked ok too.

tgm

On 4/25/07, Colin Shapiro <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm not sure that this is really anything to worry about.  I just
checked
> the XSL spec out of curiosity, and it doesn't seem to say anything that
> indicates it is improper to use the "inherit" keyword on the property of
an
> FO object when its parent doesn't have the same property explicitly set.
>
> 5.9.10.1 inherit
> The property takes the same computed value as the property for the
> formatting object's parent object.
>
> That's all it really says.  Therefore, I assume that this is just a
warning
> that FOP generates, not necessarily indicating that the FO produced by
the
> DocBook XSL stylesheet is illegal.
>
> If anyone believes otherwise, please correct me.
>
> Colin
>
>
> On 4/25/07, T.G. Mutato <[EMAIL PROTECTED] > wrote:
> >
> > I've been using DocBook 4.5, XSL 1.72.0 and FOP 0.93 on Windows and
> > noticed that whenever I run FOP on my DocBook source, I get the
> > following:
> >
> > WARNING: span="inherit" on fo:block, but no explicit value found on
> > the parent FO.
> >
> > Here's a simple example that demonstrates the warning:
> >
> >  > "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd";>
> > 
> >   
> > My First Book
> >
> JaneDoe
> > 1998Jane
> Doe
> >   
> >   
> > 
> >   
> > a nice index entry
> >   
> >   Here's our Chapter Title
> > 
> > 
> >   
> > 
> >   anothter nice index entry
> > 
> > Here's our Section Title
> >   
> >   
> > Lorem ipsum dolor sit amet, consectetuer adipiscing elit. In
> > tortor nibh, facilisis ac, consectetuer eget, malesuada
> > molestie, augue. Etiam non nibh eget elit tincidunt commodo.
> >   
> > 
> >   
> >   
> > 
> >
> > Run the two commands:
> > xsltproc --output testbook.fo pdfdoc.xsl testbook.xml
> > fop.bat -fo testbook.fo -pdf testbook.pdf
> >
> > and you see the Warning output.
> >
> > The warning doesn't seem to be serious and I am not sure if it is an
> > issue with the FO stylesheets or with FOP. Is there a good way to turn
> > off the warning?
> >
> > Thanks,
> > tgm
> >
> >
> -
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail:
> [EMAIL PROTECTED]
> >
> >
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [docbook-apps] FOP 0.93 Span="inherit" warning

[Colin Shapiro]

Hi,

I'm not sure that this is really anything to worry about.  I just checked
the XSL spec out of curiosity, and it doesn't seem to say anything that
indicates it is improper to use the "inherit" keyword on the property of an
FO object when its parent doesn't have the same property explicitly set.

5.9.10.1 inherit
The property takes the same computed value as the property for the
formatting object's parent object.

That's all it really says.  Therefore, I assume that this is just a warning
that FOP generates, not necessarily indicating that the FO produced by the
DocBook XSL stylesheet is illegal.

If anyone believes otherwise, please correct me.

Colin

On 4/25/07, T.G. Mutato <[EMAIL PROTECTED]> wrote:


I've been using DocBook 4.5, XSL 1.72.0 and FOP 0.93 on Windows and
noticed that whenever I run FOP on my DocBook source, I get the
following:

WARNING: span="inherit" on fo:block, but no explicit value found on
the parent FO.

Here's a simple example that demonstrates the warning:

http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd";>

  
My First Book
JaneDoe
1998Jane Doe
  
  

  
a nice index entry
  
  Here's our Chapter Title


  

  anothter nice index entry

Here's our Section Title
  
  
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. In
tortor nibh, facilisis ac, consectetuer eget, malesuada
molestie, augue. Etiam non nibh eget elit tincidunt commodo.
  

  
  


Run the two commands:
xsltproc --output testbook.fo pdfdoc.xsl testbook.xml
fop.bat -fo testbook.fo -pdf testbook.pdf

and you see the Warning output.

The warning doesn't seem to be serious and I am not sure if it is an
issue with the FO stylesheets or with FOP. Is there a good way to turn
off the warning?

Thanks,
tgm

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[docbook-apps] Re: [docbook] Interesting possible HTML XSLT conversion

[Colin Shapiro]

Also driven by JavaScript: http://www.w3.org/2005/Talks/Tools/Slidy/slidy.js

It would be fairly easy to customize the HTML in this manner; it looks like
it's just divided up into a number of  elements.  DocBook
sections become .

But it relies on JavaScript for the "slideshow" effect, so XSLT would only
take you so far.

Colin

On 4/20/07, Seth Call <[EMAIL PROTECTED]> wrote:


I recently stumbled upon this 'powerpoint-lite' website.
http://www.w3.org/2005/Talks/1115-hh-k-ecows/#(1)

Hit the right or left arrows (or left-click) to navigate This very clean,
CSS-driven format is ideal for certain documents.


Just a thought.

Re: [docbook-apps] DocBook and OpenOffice

[Colin Shapiro]

Steve,

That's exactly what I am looking for.  Unfortunately, this is something I
need to start doing in the immediate future, so I need to come up with a
basic working solution pretty soon.

I really only need to utilize a few of the DocBook elements right now
(pretty much just para, section, title, programlisting, and the table
elements), so I may just work up some quick and simple stylesheets for
immediate use (looking at the OpenDocument XML, this basic functionality
should be fairly straightforward).  I'd like to have a more robust solution
in the long term, however, so your project is definitely something I will
keep my eyes on.

Thanks,
Colin

On 4/18/07, Steve Ball <[EMAIL PROTECTED]> wrote:


Hi Colin,

I'm currently working on the DocBook round-tripping system.  The aim
is to allow exactly what you are looking for: use a word processor as
a front-end editor for DocBook.  It has stylesheets to convert from
DocBook to a word processing format, and another set of stylesheets
that convert from word processing format back into DocBook without
loss of information.

At the moment MS Word 2003 and Apple Pages are supported.  I'm
working on adding OpenOffice support, and basic paragraph-based
styles work but there is still more work to do on tables and images.
The stylesheets haven't been checked-in to SVN yet because they're
not quite finished, but if you would like a sneak-peek then let me know.

Cheers,
Steve Ball

On 19/04/2007, at 6:55 AM, Colin Shapiro wrote:

> Hi all,
>
> I'm looking to use OpenOffice Writer as a temporary editor for
> DocBook documents.  Basically, I need to allow certain people to
> edit DocBook documents who have never worked with markup languages
> before, but are familiar with OpenOffice.
>
> I've played around with OpenOffice's built-in DocBook support in
> the past with only partial success.  I am guessing that the best
> way is to write a couple of stylesheets to transform DocBook to/
> from the OpenDocument format.  I don't need full interoperability,
> because I plan on cleaning up the end results myself before
> publishing.
>
> I've looked at the OpenDocument format and I'm pretty confident
> that I can write stylesheets to get the basic transformations that
> I need.  However, this will take time I'd rather not spend if I
> don't have to.  Has anyone else done something like this?  I've
> Googled a bit but haven't found anything usable.
>
> Colin

[docbook-apps] DocBook and OpenOffice

[Colin Shapiro]

Hi all,

I'm looking to use OpenOffice Writer as a temporary editor for DocBook
documents.  Basically, I need to allow certain people to edit DocBook
documents who have never worked with markup languages before, but are
familiar with OpenOffice.

I've played around with OpenOffice's built-in DocBook support in the past
with only partial success.  I am guessing that the best way is to write a
couple of stylesheets to transform DocBook to/from the OpenDocument format.
I don't need full interoperability, because I plan on cleaning up the end
results myself before publishing.

I've looked at the OpenDocument format and I'm pretty confident that I can
write stylesheets to get the basic transformations that I need.  However,
this will take time I'd rather not spend if I don't have to.  Has anyone
else done something like this?  I've Googled a bit but haven't found
anything usable.

Colin

[docbook-apps] Re: [docbook] should I use section or sect1, sect2, sect3 etc?

[Colin Shapiro]

Using sect[1-5] also makes it easier to customize things.  For example, if
you want sect2 to have a unique look, you can put a template in your
customization layer matching only sect2.  If you just use 
everywhere, it makes it harder to customize particular section levels (you
can of course use XPath to select specific nested elements, but it's just
not as intuitive as a simple template matching sect2).

Colin

On 4/13/07, Warren Young <[EMAIL PROTECTED]> wrote:


Scott Hudson wrote:
> I usually recommend using nested . It makes it easier to reuse
> content in different contexts if you need to.

That lack of context is also a disadvantage.  It means you can't look at
a section of the document and immediately tell where it fits in
logically with the rest of the structure.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [docbook-apps] section in sidebar?

[Colin Shapiro]

Perhaps I am not fully understanding this problem, but I fail to see why
this kind of content would *need* to be in a sidebar.

Would something like  really be inappropriate?
Take a look at the sidebar example from the Guide:


 Some narrative text.
 
   A Sidebar
   Sidebar content.
 
 The continuing flow of the narrative text, as if the sidebar was not
present.


Here, the sidebar content is understood to be outside of the narrative
flow.  Why would this be conceptually different on a larger scale...


 Some narrative text.
  Some more narrative text.



 Text outside of narrative flow.
 More text outside of narrative flow.



 The continuing flow of the narrative text, as if the sidebar was not
present.


...?

Then, put [EMAIL PROTECTED]'side-feature'] in a block-container or something
and position it as you please.

Maybe I'm still misunderstanding, though.

Colin

On 4/12/07, Keith Fahlgren <[EMAIL PROTECTED]> wrote:


On 4/11/07, Scott Hudson <[EMAIL PROTECTED]> wrote:
> Unfortunately, this is content that is outside the narrative flow of the
> main text, and is about a page or two long. It's more like a "feature"
> that you might see in many Trade publications...

Yeah, I immediately thought of the comparable material in some of our
more layout-intensive titles. Perhaps this sort of content would be a
good thing to discuss at the DocBook SubCommittee for Publishers


Keith

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [docbook-apps] Header out of alignment - space before graphic

[Colin Shapiro]

Ah, I forgot that there's another fo:block above what you put in
header.content:

   
 
   
   
   
   
 
   

You can disregard my previous reply, then.  Bob's solution is better :)

Colin

On 4/12/07, Bob Stayton <[EMAIL PROTECTED]> wrote:


Hi Paul,
Actually, it is the fo:block inside the cell that is applying the
inherited
font-size and line-height, probably from the header.content.properties
attribute-set, which is applied to the fo:block that contains the header
table.

In header.content, you should be able to use  elements as
the first thing in each  clause to apply attributes to the
fo:block containing that content.  Any xsl:attribute elements must come
first when a block is started, before any content.

  
0pt
0pt

To: <[EMAIL PROTECTED]>
Sent: Thursday, April 12, 2007 8:01 AM
Subject: Re: [docbook-apps] Header out of alignment - space before graphic


>
>
> Bob Stayton wrote:
>>
>> but I don't think those are the problem.  You might try adding a
>> background
>> color to the table cell, and add borders around the cell, block, and
>> external-graphic to see what is contributing the space.
>
> Hi Bob,
>
> Only got back to this problem now I tried your suggestion, and the
> result is at
> http://img175.imageshack.us/my.php?image=headerwithcolorle3.png. It just
> seems that something is forcing space before (and indeed, a small amount
> of
> space after) the left-hand graphic. (The yellow and blue colors indicate
> the
> left-most and right-most cells in the header table, respectively, while
> the
> left-hand pink indicates the background of the graphic). Nothing in the
> .fo
> file seemed to indicates where this space is from.
>
> Then I remembered an answer you gave to a previous question I had about
> unwanted space before graphics
> (http://www.nabble.com/forum/ViewPost.jtp?post=9620007&framed=y)  so I
> edited the .fo and, for the header cell containing the graphic, set both
> line-height and font-size to zero. That works! Result is here:
> http://img239.imageshack.us/img239/365/headerwithcolorafterxo6.png
>
> Unfortunately, I have _no_ idea how to do this in my custom layer.  The
> instructions at
> http://www.sagehill.net/docbookxsl/PrintHeaders.html#PrintHeadersText
> don't
> seem to indicate that such a problem might happen, and only describes
how
> to
> specify the content of the cells, and not the attributes of the cells
> themselves. Any ideas? Is there perhaps a setting in my custom layer
> which
> is causing this problem?
>
> Thanks,
>
> P.
> --
> View this message in context:
>
http://www.nabble.com/Header-out-of-alignment---space-before-graphic-tf3504806.html#a9962233
> Sent from the docbook apps mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [docbook-apps] Header out of alignment - space before graphic

[Colin Shapiro]

Hi Paul,

I have had this problem before, where I had to set the font-size to 0pt to
prevent unwanted space before and after images.

All that it requires is an fo:block with this property:



If you're customizing the header.content template, simply surround the
desired content with one of these fo:blocks; i.e:


 ...
 
   
 ...content...
   
 
 ...


I think that will be all that is necessary... by specifying font-size="0pt"
on a block within a header table cell, I don't think you will actually need
to do anything to the table-cell itself.  If you find that this doesn't
work, however, and you'd like to try customizing the table-cell itself, then
search pagesetup.xsl for the template called header.table.  Copy it to your
customization layer, and work with it as necessary.

I hope that helps.

Colin

On 4/12/07, Paul Moloney <[EMAIL PROTECTED]> wrote:




Bob Stayton wrote:
>
> but I don't think those are the problem.  You might try adding a
> background
> color to the table cell, and add borders around the cell, block, and
> external-graphic to see what is contributing the space.

Hi Bob,

Only got back to this problem now I tried your suggestion, and the
result is at
http://img175.imageshack.us/my.php?image=headerwithcolorle3.png. It just
seems that something is forcing space before (and indeed, a small amount
of
space after) the left-hand graphic. (The yellow and blue colors indicate
the
left-most and right-most cells in the header table, respectively, while
the
left-hand pink indicates the background of the graphic). Nothing in the
.fo
file seemed to indicates where this space is from.

Then I remembered an answer you gave to a previous question I had about
unwanted space before graphics
(http://www.nabble.com/forum/ViewPost.jtp?post=9620007&framed=y)  so I
edited the .fo and, for the header cell containing the graphic, set both
line-height and font-size to zero. That works! Result is here:
http://img239.imageshack.us/img239/365/headerwithcolorafterxo6.png

Unfortunately, I have _no_ idea how to do this in my custom layer.  The
instructions at
http://www.sagehill.net/docbookxsl/PrintHeaders.html#PrintHeadersTextdon't
seem to indicate that such a problem might happen, and only describes how
to
specify the content of the cells, and not the attributes of the cells
themselves. Any ideas? Is there perhaps a setting in my custom layer which
is causing this problem?

Thanks,

P.
--
View this message in context:
http://www.nabble.com/Header-out-of-alignment---space-before-graphic-tf3504806.html#a9962233
Sent from the docbook apps mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [docbook-apps] DocBook 4.5, XSL 1.72.0 and FOP 0.93 all working together?

[Colin Shapiro]

Hi,

Well, I use this very combination of tools that you describe, and I never
had such problems.

But I did copy your XML source and try it for myself.  Interestingly, I got
the same error:

SEVERE: Exception
java.lang.ClassCastException:
org.apache.fop.layoutmgr.inline.WrapperLayoutManager cannot be cast to
org.apache.fop.layoutmgr.BlockLevelLayoutManager

...until I commented out your  elements and tried it again.
Then, it worked fine.  I'll take another look at this and see if I can
figure out why.

On another note, regarding your hyphenation issues; have you set up a
hyphenation pattern?  If not, you should do so now; see
http://xmlgraphics.apache.org/fop/0.93/hyphenation.html for more
information.  The hyphenation pattern can be downloaded from
http://offo.sourceforge.net/hyphenation/index.html.

Colin

On 4/11/07, T.G. Mutato <[EMAIL PROTECTED]> wrote:


Hello,

Anyone had any luck getting DocBook 4.5, XSL 1.72.0 and FOP 0.93 all
working together to produce PDF output? I've found that even a very
simple DocBook file won't compile properly with the 0.93 version of
FOP from apache.org.

Here's the sample:





My First Book


JaneDoe
1998Jane
Doe


Here's our Chapter Title

a nice index entry


Here's our Section Title

anothter nice index
entry


Lorem ipsum dolor sit amet, consectetuer
adipiscing elit. In
tortor nibh, facilisis ac, consectetuer eget, malesuada
molestie, augue. Etiam non nibh eget elit
tincidunt commodo.






I'm building the fo file (on Windows) with the command:
xsltproc --nonet --xinclude --output testbook.fo pdfdoc.xsl testbook.xml

and then building (trying to) the pdf file with the command:
fop\fop.bat -fo testbook.fo -pdf testbook.pdf

FOP seems to have trouble with hyphenation so the pdfdoc.xsl file used
when building testbook.fo looks like:

http://www.w3.org/1999/XSL/Transform";
xmlns:fo="http://www.w3.org/1999/XSL/Format";
version="1.0">







Running fop produces:
SEVERE: Exception
java.lang.ClassCastException:
org.apache.fop.layoutmgr.inline.WrapperLayoutManager

The new FOP processor (0.93) is supposed to be quite a bit better than
the old 0.25 version but not if it doesn't work!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [docbook-apps] Dynamically creating an FO table based on content length

[Colin Shapiro]

I am currently working around this problem by using a multi-column layout in
my region-body, and setting the bottom body margin to a large value so it
puts a hard limit on the column height.  So, say that I am working with a
page that is 11in high; I'll give it four columns and set the margin-bottom
to 7in, so the columns never exceed a few inches in height.

Of course, this has shortcomings:
1) The number of columns must be controlled manually.  I initially wanted
the number of columns to be automatically determined by the amount of source
content.
2) Setting a large margin-bottom on region-body leaves a large portion of
the page outside of the flow region.  Thus, to put more content on the same
page, I need to use block-containers with absolute positioning.

This works for me for now, but I'm still going to research this.

Colin

On 4/3/07, Nelson, Dean <[EMAIL PROTECTED]> wrote:


 It seems that you could force that list to a multi-column block? Still,
that would be a significant customization.

Regards,

Dean Nelson
Enterprise Electronics Corp

 -Original Message-----
*From:* Colin Shapiro [mailto:[EMAIL PROTECTED]
*Sent:* Tuesday, April 03, 2007 3:29 PM
*To:* Nelson, Dean
*Cc:* docbook-apps@lists.oasis-open.org
*Subject:* Re: [docbook-apps] Dynamically creating an FO table based on
content length

Hi,

Yes, this is similar to what I am trying to do.  However, I don't believe
that this is a DocBook-specific problem, or a shortcoming of the DocBook DTD
/ XSL distribution itself.

I could be using my own custom DTD and I still wouldn't know how to write
XSLT that can predict the physical dimensions of printed text blocks after
they are generated by an FO processor.  That is the heart of my question.

Obviously, there is no way a stylesheet can know exactly what printed
output will look like, since the FO processor has yet to do its magic.  But
maybe there's a good way to predict the output, somehow.

If you wanted to go all-out, you could probably do the following:

1) Based on the font family, size, weight, and style that will be used,
calculate the final, printed widths of each possible character (or at least
letters/numbers) and store them in variables.
2) Use these values to calculate the total widths of the
paragraphs/listitems/whatever you want to output.
3) Use these total widths to calculate how many lines each
paragraph/listitem/whatever needs to occupy.
4) Use this information to determine how many columns are needed to
contain all the lines of text produced.

That, however, seems like a lot of work, and a very complicated
stylesheet.

Is there a better way?

Colin

On 4/3/07, Nelson, Dean <[EMAIL PROTECTED]> wrote:
>
>  This was something that I was wondering myself, just yesterday. I
> wanted to be able to do a list that had a certain height and would
> automatically wrap to the next column on the right when the height was
> exceeded. But atlas, this mere mortal failed and could not figure out how to
> do it with standard Docbook features.
>
> I think that this is a feature that could be added to the lists in
> Docbook?
>
> Regards,
>
> Dean Nelson
> Enterprise Electronics Corp
>
>  -Original Message-
> *From:* Colin Shapiro [mailto:[EMAIL PROTECTED]
> *Sent:* Tuesday, April 03, 2007 2:14 PM
> *To:* docbook-apps@lists.oasis-open.org
> *Subject:* [docbook-apps] Dynamically creating an FO table based on
> content length
>
> Hi all,
>
> I have a problem which I can't think of a good way to solve.  I realize
> that I am perhaps approaching this problem incorrectly, so I hope someone
> can point me in the right direction.
>
> Suppose that I have an arbitrary series of paragraphs in my source file,
> containing an arbitrary amount of content:
>
> This is some content.
> This is more content.
> This is even more content.
> This is a longer amount of content.
>
> Now, suppose that I want to format this source in an FO table with a
> single row of cells.  I want the table to have a fixed height--say, 2
> inches--so that the table never grows higher  than 2 inches.  I might do
> this by placing block-containers within the table cells, giving them height
> attributes.  Then, I distribute my content among the table cells
> accordingly:
>
> 
>   
>   
>
>   
> 
>   
> 
>   This is some content.
>   This is more content.
>   This is even more content.
> 
>   
>   
> 
>   This is a longer amount of content.
> 
>   
> 
>   
> 
>
> The problem, however, is that the source file can contain any number of
> paragraphs of various lengths, and this will not be known until processing
> time.  Since I never want my table exceed 2 inches in height, I may need to
> add mor

Re: [docbook-apps] Dynamically creating an FO table based on content length

[Colin Shapiro]

Hi,

Yes, this is similar to what I am trying to do.  However, I don't believe
that this is a DocBook-specific problem, or a shortcoming of the DocBook DTD
/ XSL distribution itself.

I could be using my own custom DTD and I still wouldn't know how to write
XSLT that can predict the physical dimensions of printed text blocks after
they are generated by an FO processor.  That is the heart of my question.

Obviously, there is no way a stylesheet can know exactly what printed output
will look like, since the FO processor has yet to do its magic.  But maybe
there's a good way to predict the output, somehow.

If you wanted to go all-out, you could probably do the following:

1) Based on the font family, size, weight, and style that will be used,
calculate the final, printed widths of each possible character (or at least
letters/numbers) and store them in variables.
2) Use these values to calculate the total widths of the
paragraphs/listitems/whatever you want to output.
3) Use these total widths to calculate how many lines each
paragraph/listitem/whatever needs to occupy.
4) Use this information to determine how many columns are needed to contain
all the lines of text produced.

That, however, seems like a lot of work, and a very complicated stylesheet.

Is there a better way?

Colin

On 4/3/07, Nelson, Dean <[EMAIL PROTECTED]> wrote:


 This was something that I was wondering myself, just yesterday. I wanted
to be able to do a list that had a certain height and would automatically
wrap to the next column on the right when the height was exceeded. But
atlas, this mere mortal failed and could not figure out how to do it with
standard Docbook features.

I think that this is a feature that could be added to the lists in
Docbook?

Regards,

Dean Nelson
Enterprise Electronics Corp

 -Original Message-
*From:* Colin Shapiro [mailto:[EMAIL PROTECTED]
*Sent:* Tuesday, April 03, 2007 2:14 PM
*To:* docbook-apps@lists.oasis-open.org
*Subject:* [docbook-apps] Dynamically creating an FO table based on
content length

Hi all,

I have a problem which I can't think of a good way to solve.  I realize
that I am perhaps approaching this problem incorrectly, so I hope someone
can point me in the right direction.

Suppose that I have an arbitrary series of paragraphs in my source file,
containing an arbitrary amount of content:

This is some content.
This is more content.
This is even more content.
This is a longer amount of content.

Now, suppose that I want to format this source in an FO table with a
single row of cells.  I want the table to have a fixed height--say, 2
inches--so that the table never grows higher  than 2 inches.  I might do
this by placing block-containers within the table cells, giving them height
attributes.  Then, I distribute my content among the table cells
accordingly:


  
  

  

  

  This is some content.
  This is more content.
  This is even more content.

  
  

  This is a longer amount of content.

  

  


The problem, however, is that the source file can contain any number of
paragraphs of various lengths, and this will not be known until processing
time.  Since I never want my table exceed 2 inches in height, I may need to
add more columns as needed to get additional cells.  The idea here is that
the first cell will accommodate 2-inches-worth of content, then whatever
overflows will spill into the next cell, which will in turn accommodate 2
inches of content, etc., and this will continue until all content is
displayed.

I'd like a stylesheet to automatically handle this.  It will determine how
much content there is, how many table columns are needed, and distribute the
content accordingly.  However, this seems rather difficult to do, since the
stylesheet has no way of knowing what the final print output will look like,
how large the fonts will be, etc.

I might be able to do something with string lengths.  Calculate the length
of each paragraph, calculate the capacity of a table cell, and output the
paragraphs in table cells where they fit.  But this would be based on
character counts only, which hold no bearing on the final print output when
a variable-width font is used; i.e., if the string "abcde" has a length of
"5", that doesn't tell me anything about how much physical space the text
"abcde" will occupy when printed in Helvetica font at size 12pt.

Does what I'm getting at make sense?  I hope I am being clear about my
problem; let me know if I am not.

Thanks,
Colin

[docbook-apps] Dynamically creating an FO table based on content length

[Colin Shapiro]

Hi all,

I have a problem which I can't think of a good way to solve.  I realize that
I am perhaps approaching this problem incorrectly, so I hope someone can
point me in the right direction.

Suppose that I have an arbitrary series of paragraphs in my source file,
containing an arbitrary amount of content:

This is some content.
This is more content.
This is even more content.
This is a longer amount of content.

Now, suppose that I want to format this source in an FO table with a single
row of cells.  I want the table to have a fixed height--say, 2 inches--so
that the table never grows higher  than 2 inches.  I might do this by
placing block-containers within the table cells, giving them height
attributes.  Then, I distribute my content among the table cells
accordingly:


 
 

 
   
 
   
 This is some content.
 This is more content.
 This is even more content.
   
 
 
   
 This is a longer amount of content.
   
 
   
 


The problem, however, is that the source file can contain any number of
paragraphs of various lengths, and this will not be known until processing
time.  Since I never want my table exceed 2 inches in height, I may need to
add more columns as needed to get additional cells.  The idea here is that
the first cell will accommodate 2-inches-worth of content, then whatever
overflows will spill into the next cell, which will in turn accommodate 2
inches of content, etc., and this will continue until all content is
displayed.

I'd like a stylesheet to automatically handle this.  It will determine how
much content there is, how many table columns are needed, and distribute the
content accordingly.  However, this seems rather difficult to do, since the
stylesheet has no way of knowing what the final print output will look like,
how large the fonts will be, etc.

I might be able to do something with string lengths.  Calculate the length
of each paragraph, calculate the capacity of a table cell, and output the
paragraphs in table cells where they fit.  But this would be based on
character counts only, which hold no bearing on the final print output when
a variable-width font is used; i.e., if the string "abcde" has a length of
"5", that doesn't tell me anything about how much physical space the text
"abcde" will occupy when printed in Helvetica font at size 12pt.

Does what I'm getting at make sense?  I hope I am being clear about my
problem; let me know if I am not.

Thanks,
Colin

Re: [docbook-apps] Carriage Return/Line Feed within informaltable cells on PDF

[Colin Shapiro]

That's a lot simpler than the way I had done it in the past.  Thanks.

Colin


On 3/29/07, Ron Catterall <[EMAIL PROTECTED]> wrote:


 It's very easy to put in an extra fo block to act as a line break





 Does this help?

Ron



I have personally never been able to get any kind of line breaks to work
by attempting to insert them into a source file.

Instead, I have had to do things with a customization layer in XSLT, to
produce separate fo:block elements to break lines.

I can post an example if you'd like, but in the meantime I'd like to know
if anyone else has a better solution.

Colin

On 3/29/07,* D_A_U* <[EMAIL PROTECTED]> wrote:


Hello,

I am new here and especially new with using Docbook. I want to create
Reports with results of softwaretests.
I used an informaltable. Within the tablecells I have text with includes a
char(10) --> Carriage return.
The PDF result ignores these CR/LF.
Does someone know to solve this? I can also transform the chr(10) to an
other character before converting.

Thanks
--
View this message in context:
http://www.nabble.com/Carriage-Return-Line-Feed-within-informaltable
-cells-on-PDF-tf3488163.html#a9740072
Sent from the docbook apps mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--

Ron Catterall, Phd, DSc email: [EMAIL PROTECTED]
Prolongacion de Hidalgo 140
http://catterall.net/
San Felipe del Aguatel: +52 951
520 1821
Oaxaca  68020  Mexico  fax: +1 530 348 8309

Re: [docbook-apps] Carriage Return/Line Feed within informaltable cells on PDF

[Colin Shapiro]

I have personally never been able to get any kind of line breaks to work by
attempting to insert them into a source file.

Instead, I have had to do things with a customization layer in XSLT, to
produce separate fo:block elements to break lines.

I can post an example if you'd like, but in the meantime I'd like to know if
anyone else has a better solution.

Colin

On 3/29/07, D_A_U <[EMAIL PROTECTED]> wrote:



Hello,

I am new here and especially new with using Docbook. I want to create
Reports with results of softwaretests.
I used an informaltable. Within the tablecells I have text with includes a
char(10) --> Carriage return.
The PDF result ignores these CR/LF.
Does someone know to solve this? I can also transform the chr(10) to an
other character before converting.

Thanks
--
View this message in context:
http://www.nabble.com/Carriage-Return-Line-Feed-within-informaltable-cells-on-PDF-tf3488163.html#a9740072
Sent from the docbook apps mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [docbook-apps] Text style and color

[Colin Shapiro]

Hi Xavier,

I think you're going to be stuck with writing a customization layer to do
any of this.  I'm not quite sure what you mean by "customizing text color
... without developing it in my customization layer."  You simply can't
customize such properties without putting them in a customization layer.

If you need to have new elements such as  and  in your DocBook
document, then you will have to first customize DocBook to add them.  See
the relevant chapter of the Definitive Guide:
http://docbook.org/tdg/en/html/ch05.html.

Then, you will have to write a stylesheet customization layer to treat these
elements accordingly:


 
   
 



 
   
 
   
   
 
   
   
 
   
 


Note: this is assuming you're using XSL-FO, and this may not be exactly how
you want to do it, but it's an example.

Hope this helps... let me know if I've misinterpreted your question.

Colin

On 3/26/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


Hi all,

I have to produce documents with a complex presentation for some part of
the
text.

My toolchain consists in :
XML (with owner format) --|XSLT|--> DocBook --|docbook-xsl|--> PDF

In my source XML document, there is some data where format description is
part
of the data.
eg.


blue
underline
A part of


black
normal
 a text for xxx



In my final PDF document, I want to display xxx elements with a pretty
format
representing a concatenation of txt (taking into account color and style
sub-elements).

For this purpose, I think I have two choices, but I'm not sure the first
is
possible :

1/ Generating a docbook document with color and style inside. I don't find
any
documentation about customizing text color in docbook (i.e. without
developping
it in my customization layer). Is it possible to do this ?

2/ Generating a docbook document with "xxx" elements inside and treating
them in
the presentation layer. This means that my docbook format is extented with
the
"xxx" element. Regarding the reference schema of DocBook publishing
model(http://nwalsh.com/docbook/procdiagram/) I guess it is possible. Is
there a
documentation guide for extending DocBook format with owner elements ?

Thanks in advance.

Xavier


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [docbook-apps] Creating HTML Links that Open in a New Window

[Colin Shapiro]

Hi Raymond,

If I was faced with this problem, I'd try solving it through a customization
layer.

You could copy the template that matches "ulink" in xref.xsl, and add an
attribute to the html element  (as I have written on the last line in the
below example):


 
 
   
 
   
 
   
 
 
 _blank
 ...

Or, if you don't want this behavior for all of your links, you could make a
new template that matches a ulink with a given role attribute:



Hope this helps.

Colin



If I was faced with this problem, I would

On 3/17/07, Raymond <[EMAIL PROTECTED]> wrote:


How does one create links than open in a new window for html output of

external link
or
external link

in DocBook 5?

http://www.w3.org/1999/xlink";>
...
...
external
link
...
...


does not produce the desired result (no new window)

Using most current releases of docbook-xml (rng) and docbook-xsl

Raymond






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[docbook-apps] Best online reference for XSL-FO?

[Colin Shapiro]

This should be trivial, but I'm having a hard time finding a good, complete
XSL-FO reference.  I normally turn to W3 Schools for stuff like this, but
their XSL-FO reference
seems sparse...
the examples are shallow and some of the attributes are not
described.

Which online resources do you use?  I'm not adverse to buying a book,
either, but an online resource is just more convenient.

Thanks,
Colin

Re: [docbook-apps] Re: Different numbers of columns on a single page?

[Colin Shapiro]

Bob,

Thanks for that tip, it was very helpful.  I'm sure I'd be pulling my hair
out later when the span attribute refused to work after I put it in a nested
fo:block.

I just tried it to see what would happen with FOP v0.93, and it doesn't work
unless it's in a direct child of fo:flow.  And there are no errors
indicating what the problem is.

Thanks,
Colin

On 2/28/07, Bob Stayton <[EMAIL PROTECTED]> wrote:


 Hi Colin,
It is the only way to do it, so it had better be the best way.  8^)

Depending on your XSL-FO processor, span may or may not work in all
contexts.  The XSL-FO spec says a spanned block must be a direct child of
fo:flow.  But DocBook uses nested fo:block elements for sections to apply
section properties.  That can be worked around, if you need it.

Bob Stayton
Sagehill Enterprises
DocBook Consulting
[EMAIL PROTECTED]



- Original Message -
*From:* Colin Shapiro <[EMAIL PROTECTED]>
*To:* docbook-apps@lists.oasis-open.org
*Sent:* Wednesday, February 28, 2007 10:20 AM
*Subject:* [docbook-apps] Re: Different numbers of columns on a single
page?

Ah, I just discovered the "span" attribute.  So, I can make my entire page
three-columns, and then use span="all" on the FO objects that I want to span
across these columns.

Can someone just confirm that this is the best way to do what I am after?

Thanks,
Colin

On 2/28/07, Colin Shapiro <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> Simple question that may not have a simple answer:
>
> I understand how to set up custom page masters for FO output with
> different numbers of columns, but what if I want to change the column layout
> mid-page?  Say, for example, that I want half a page to have three columns,
> and the other half to have one column.
>
> Is this possible?
>
> Thanks,
> Colin
>

[docbook-apps] Re: Different numbers of columns on a single page?

[Colin Shapiro]

Ah, I just discovered the "span" attribute.  So, I can make my entire page
three-columns, and then use span="all" on the FO objects that I want to span
across these columns.

Can someone just confirm that this is the best way to do what I am after?

Thanks,
Colin

On 2/28/07, Colin Shapiro <[EMAIL PROTECTED]> wrote:


Hello,

Simple question that may not have a simple answer:

I understand how to set up custom page masters for FO output with
different numbers of columns, but what if I want to change the column layout
mid-page?  Say, for example, that I want half a page to have three columns,
and the other half to have one column.

Is this possible?

Thanks,
Colin

[docbook-apps] Different numbers of columns on a single page?

[Colin Shapiro]

Hello,

Simple question that may not have a simple answer:

I understand how to set up custom page masters for FO output with different
numbers of columns, but what if I want to change the column layout
mid-page?  Say, for example, that I want half a page to have three columns,
and the other half to have one column.

Is this possible?

Thanks,
Colin