xmlroff-list

[xmlroff] DocBook to PDF with xmlroff

[Tim W. <tw...@re...>]

So I managed to get a DocBook document converted to PDF using xmlroff
and the libfo-compat.xsl stylesheet (with the two modifications I
posted) applied to docbook-xsl output, and I'm really impressed.

The two immediately obvious things missing are:

* PNG graphics (@background-image)
* @white-space-treatment="preserve" for DocBook <screen> nodes

The only other thing wrong with the output for this document is that
an <orderedlist> comes out as a weird array of dots instead of any
text.  I haven't been able to make a smaller test case yet.

What steps are needed to add @background-image and
@white-space-treatment support?

Tim.
*/

Re: [xmlroff] DocBook to PDF with xmlroff

[Tony G. <Ton...@Su...>]

Tim Waugh <tw...@re...> writes:
> So I managed to get a DocBook document converted to PDF using xmlroff
> and the libfo-compat.xsl stylesheet (with the two modifications I
> posted) applied to docbook-xsl output, and I'm really impressed.

Music to my ears.

> The two immediately obvious things missing are:
>
> * PNG graphics (@background-image)
> * @white-space-treatment="preserve" for DocBook <screen> nodes
>
> The only other thing wrong with the output for this document is that
> an <orderedlist> comes out as a weird array of dots instead of any
> text.  I haven't been able to make a smaller test case yet.
>
> What steps are needed to add @background-image and
> @white-space-treatment support?

For @white-space-treatment="preserve", modify your whitespace munging
template to not apply to FOs with @white-space-treatment="preserve".
xmlroff preserves whitespace by default.

@background-image would probably be pretty simple (much simpler than
fo:external-graphic): in theory, you'd modify area-to-pdf.c to do the
FoDoc calls to render the background image before doing the FoDoc
calls to render the text.  You may also have to implement FoDocGP
functions to render the image, but how hard can that be?

Regards,


Tony.

Re: [xmlroff] DocBook to PDF with xmlroff

[Tim W. <tw...@re...>]

On Thu, Mar 10, 2005 at 04:41:49PM +0000, Tony Graham wrote:

> For @white-space-treatment="preserve", modify your whitespace munging
> template to not apply to FOs with @white-space-treatment="preserve".
> xmlroff preserves whitespace by default.

That's what I tried to start with, and it gets me a segfault. :-)

> @background-image would probably be pretty simple (much simpler than
> fo:external-graphic): in theory, you'd modify area-to-pdf.c to do
> the FoDoc calls to render the background image before doing the
> FoDoc calls to render the text.  You may also have to implement
> FoDocGP functions to render the image, but how hard can that be?

Oh, now that I look more closely, it's the fo:external-graphic ones I
wanted.  The background-image things were for 'draft'-type watermarks,
and they come from docbook-xsl.

So is that more difficult?

Tim.
*/

Re: [xmlroff] DocBook to PDF with xmlroff

[Tim W. <tw...@re...>]

On Thu, Mar 10, 2005 at 04:49:06PM +0000, Tim Waugh wrote:

> That's what I tried to start with, and it gets me a segfault. :-)

Here's where it faults, by the way:

#0  0x080bd4da in fo_area_size_request_default (child=0xa62ac18)
    at fo-area.c:1985
1985          while (return_child->next_part != child_original_next_part)

return_child is 0x0, child is 0xa62ac18 and child_original_next_part
is 0xa535e58.

Looks like it probably needs to be something like

while (return_child->next_part && return_child->next_part != ...)

Tim.
*/

Re: [xmlroff] DocBook to PDF with xmlroff

[Tony G. <Ton...@Su...>]

Tim Waugh <tw...@re...> writes:
> On Thu, Mar 10, 2005 at 04:49:06PM +0000, Tim Waugh wrote:
>
>> That's what I tried to start with, and it gets me a segfault. :-)
>
> Here's where it faults, by the way:
>
> #0  0x080bd4da in fo_area_size_request_default (child=0xa62ac18)
>     at fo-area.c:1985
> 1985          while (return_child->next_part != child_original_next_part)
>
> return_child is 0x0, child is 0xa62ac18 and child_original_next_part
> is 0xa535e58.
>
> Looks like it probably needs to be something like
>
> while (return_child->next_part && return_child->next_part != ...)

I would like to be able to say that in principle the return_child
should not be null, but it's been so long that I can't be sure.
Obviously it is null in that instance.

Can you send me your file, although I can't say when I will get to
look at it.

Regards,


Tony.

Re: [xmlroff] DocBook to PDF with xmlroff

[Tim W. <tw...@re...>]

On Thu, Mar 10, 2005 at 11:16:09PM +0000, Tony Graham wrote:

> I would like to be able to say that in principle the return_child
> should not be null, but it's been so long that I can't be sure.
> Obviously it is null in that instance.

FWIW, making the change I suggested does seem to fix the segfault,
although some parts of the output seem to be on the wrong page (in
particular a white-space-treatment='preserve' figure seems to have
been split across to pages, both parts being at the top of the page) .
Not sure if that's a separate problem.

> Can you send me your file, although I can't say when I will get to
> look at it.

[Sent in private mail.]

Tim.
*/

Re: [xmlroff] DocBook to PDF with xmlroff

[Tim W. <tw...@re...>]

FWIW, I still see this segfault with current CVS.

Tim.
*/

On Fri, Mar 11, 2005 at 11:06:48AM +0000, Tim Waugh wrote:

> On Thu, Mar 10, 2005 at 11:16:09PM +0000, Tony Graham wrote:
>=20
> > I would like to be able to say that in principle the return_child
> > should not be null, but it's been so long that I can't be sure.
> > Obviously it is null in that instance.
>=20
> FWIW, making the change I suggested does seem to fix the segfault,
> although some parts of the output seem to be on the wrong page (in
> particular a white-space-treatment=3D'preserve' figure seems to have
> been split across to pages, both parts being at the top of the page) .
> Not sure if that's a separate problem.
>=20
> > Can you send me your file, although I can't say when I will get to
> > look at it.
>=20
> [Sent in private mail.]
>=20
> Tim.
> */

Re: [xmlroff] DocBook to PDF with xmlroff

[Tony G. <Ton...@Su...>]

Tim Waugh <tw...@re...> writes:
> On Thu, Mar 10, 2005 at 04:41:49PM +0000, Tony Graham wrote:
..
> Oh, now that I look more closely, it's the fo:external-graphic ones I
> wanted.  The background-image things were for 'draft'-type watermarks,
> and they come from docbook-xsl.
>
> So is that more difficult?

Oh, yes.

The simple answer:

 - Implement the graphic handing in FoDocGP that used to be in
   FoDocPDF.

 - Modify PangoXSL to walk the PangoLayout after it's been rendered
   and call the callback for each graphic.

The correct answer:

 - Rewrite the "inline" FOs so they create areas (rather than, as at
   present, their containing FoBlock walks the FO tree to build a
   PangoAttribute list).

 - Make the FoAreaLayout walk its contained areas to build the
   PangoLayout.

 - Make an FoAreaGraphic that holds the callback for printing the
   graphic.

 - Modify PangoXSL to walk the PangoLayout after it's been rendered
   and call the callback for each graphic.

 - Submit a Pango enhancement request once the callback technique is
   shown to work so the callback handling goes into core Pango.

 - Make an FoImage datatype (or similar) so you don't have to have
   multiple copies of a graphic file when there's multiple references
   to the same external graphic.

Regards,


Tony.

Re: [xmlroff] DocBook to PDF with xmlroff

[Tony G. <Ton...@Su...>]

Tony Graham <Ton...@Su...> writes:
> Tim Waugh <tw...@re...> writes:
>> On Thu, Mar 10, 2005 at 04:41:49PM +0000, Tony Graham wrote:
> ..
>> Oh, now that I look more closely, it's the fo:external-graphic ones I
>> wanted.  The background-image things were for 'draft'-type watermarks,
>> and they come from docbook-xsl.
>>
>> So is that more difficult?
>
> Oh, yes.
>
> The simple answer:

For the record...

>  - Implement the graphic handing in FoDocGP that used to be in
>    FoDocPDF.

I.e., implement these commands from libfo/fo-doc-commands.h for
FoDocGP:

void          fo_doc_place_image     (FoDoc        *fo_doc,
				      gint          image,
				      gfloat        x,
				      gfloat        y,
				      gfloat        scale);
gint          fo_doc_open_image_file (FoDoc        *fo_doc,
				      const char   *imagetype,
				      const char   *filename,
				      const char   *stringparam,
				      gint          intparam);
void          fo_doc_close_image     (FoDoc        *fo_doc,
				      gint          image);

In practice, it would be okay to modify the fo-doc-commands.h commands
since these were based on PDFlib functions and PDFlib is no longer
used.

>  - Modify PangoXSL to walk the PangoLayout after it's been rendered
>    and call the callback for each graphic.

Actually, modify fo_doc_gp_render_layout_lines() to add something
similar to pangopdf_layout_lines() after the
gnome_print_pango_layout() call to iterate through each PangoAttribute
of each run of each line of fo_area_layout_get_layout (area_layout) to
find any callback attributes similarly to what was done in
pangopdflib.c in the PangoPDF project:

	  if (attr_type == pango_attr_callback_get_type ())
	    {
	      GValue values[1] = { { 0, } };

	      g_value_init (&values[0], G_TYPE_POINTER);
	      g_value_set_pointer (&values[0], pdf_doc);

#if 0
	      g_message ("Got a callback: callback: %p",
			 ((PangoAttrPointer *) attr)->pointer);
#endif

	      PDF_translate (pdf_doc,
			     ((float) x) / PANGO_SCALE,
			     ((float) y) / PANGO_SCALE);

	      g_closure_invoke (((GClosure *) ((PangoAttrPointer *) attr)->pointer),
				NULL,
				1,
				values,
				NULL);
	      PDF_translate (pdf_doc,
			     - (((float) x) / PANGO_SCALE),
			     - (((float) y) / PANGO_SCALE));
	    }

(See
http://cvs.sourceforge.net/viewcvs.py/pangopdf/pangopdf/pango/pangopdflib.c?rev=1.6&view=auto)

Regards,


Tony.

Re: [xmlroff] DocBook to PDF with xmlroff

[Tony G. <Ton...@Su...>]

Tim Waugh <tw...@re...> writes:
> FWIW, I still see this segfault with current CVS.

Part of the problem is that xmlroff currently doesn't cope if the URL
in 'src="url(...)"' is unquoted.  I modified libfo-compat.xsl to add
quotes when omitted since I've yet to work out the best way to modify
fo-expr-eval.c to handle this case.

The other remaining failed assertions are because xmlroff expects
'content-width' and 'content-height' to be integers since that was how
you had to specify the size of an fo:external-graphic.  Graphics don't
work at all now, so you'll also get a polite message telling you that
fo:external-graphic support is still being worked on.

So the next thing to do is work on fo:external-graphic support...

Regards,


Tony.

> Tim.
> */
>
> On Fri, Mar 11, 2005 at 11:06:48AM +0000, Tim Waugh wrote:
>
>> On Thu, Mar 10, 2005 at 11:16:09PM +0000, Tony Graham wrote:
>> 
>> > I would like to be able to say that in principle the return_child
>> > should not be null, but it's been so long that I can't be sure.
>> > Obviously it is null in that instance.
>> 
>> FWIW, making the change I suggested does seem to fix the segfault,
>> although some parts of the output seem to be on the wrong page (in
>> particular a white-space-treatment='preserve' figure seems to have
>> been split across to pages, both parts being at the top of the page) .
>> Not sure if that's a separate problem.
>> 
>> > Can you send me your file, although I can't say when I will get to
>> > look at it.
>> 
>> [Sent in private mail.]
>> 
>> Tim.
>> */
>
>

-- 
Tony Graham
Sun Microsystems Ireland                           Phone: +353 1 8199708
East Point Business Park, Dublin 3                   Internal: (70)19708