xmlroff-list — xmlroff XSL formatter discussion list

Re: [xmlroff] stack overflow ?

[Stefan S. <se...@sy...>]

Tony Graham wrote:
> Stefan Seefeld <se...@sy...> writes:

>>and then seg faulted. The debugger revealed that (if my interpretation
>>is correct) the crash is due to a stack overlow that stems from
>>an infinite recursion:
> 
> 
> Yes.
> 
> xmlroff can't split an area.
> 
> It should just render the area as best it can, but obviously it doesn't do
> that yet.

I see.

>>PS: What does it take for xmlroff to fetch an external graphics' size from
>>    the graphic itself, instead of requiring it to be provided in the xml input ?
> 
> 
> The next version of xmlroff.

Great, can't wait to try it ! Though I still need to sort out how to work around
the area split problem, since the input was generated from stock docbook fo
stylesheets even with libfo-compat.xsl filtering.

Thanks,
		Stefan

Re: [xmlroff] stack overflow ?

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

Stefan Seefeld <se...@sy...> writes:
> I'v just updated my xmlroff sources and built in an attempt to
> try it on some docbook input. I preprocessed the fo that I obtained
> via Norm's fo stylesheets with your libfo-compat.xsl stylesheet,
> and then called 'xmlroff Tutorial.pdf Tutorial-compat.fo'.
>
> This generated *lots* of errors, all of the form
>
> (process:7926): libfo-CRITICAL **: fo_area_page_size_request:: Cannot split child:: page: FoAreaPage 
> (0x8d70668 : 2); child: FoAreaViewportReference (0x8d6ffd0 : 1)
>
>
> and then seg faulted. The debugger revealed that (if my interpretation
> is correct) the crash is due to a stack overlow that stems from
> an infinite recursion:

Yes.

xmlroff can't split an area.

It should just render the area as best it can, but obviously it doesn't do
that yet.

> ....
>
> #170319 0x002fc227 in fo_area_size_request (child=0x8c07610) at fo-area.c:1734
> #170320 0x00301e66 in fo_area_normal_size_request (child=0x8c298a0) at fo-area-normal.c:198
> #170321 0x002fc227 in fo_area_size_request (child=0x8c298a0) at fo-area.c:1734
> #170322 0x00303e23 in fo_area_page_size_request (child=0x8c0dfd0) at fo-area-page.c:731
> #170323 0x002fc227 in fo_area_size_request (child=0x8c0dfd0) at fo-area.c:1734
> #170324 0x002fc9ca in fo_area_size_request_default (child=0x8bd9ee8) at fo-area.c:1925
> #170325 0x002fc227 in fo_area_size_request (child=0x8bd9ee8) at fo-area.c:1734
> #170326 0x002fc9ca in fo_area_size_request_default (child=0x8c07610) at fo-area.c:1925
> #170327 0x002fc227 in fo_area_size_request (child=0x8c07610) at fo-area.c:1734
> #170328 0x00301e66 in fo_area_normal_size_request (child=0x8c298a0) at fo-area-normal.c:198
> #170329 0x002fc227 in fo_area_size_request (child=0x8c298a0) at fo-area.c:1734
> #170330 0x00315e76 in fo_list_item_area_new2 (fo_node=0x855b1c8, context=0xbff0c760, 
> error=0x8c298a0) at fo-list-item-area.c:119
>
> Segmentation fault
>
> Am I doing something stupid ? Let me know if you need more information.
>
> Thanks,
> 		Stefan
>
> PS: What does it take for xmlroff to fetch an external graphics' size from
>     the graphic itself, instead of requiring it to be provided in the xml input ?

The next version of xmlroff.

I will be adding an object for the graphic that can be used to get the size to
tell Pango.

(I have grander plans than that, but that will do for starters.)

Regards,


Tony.

[xmlroff] stack overflow ?

[Stefan S. <se...@sy...>]

Tony,

I'v just updated my xmlroff sources and built in an attempt to
try it on some docbook input. I preprocessed the fo that I obtained
via Norm's fo stylesheets with your libfo-compat.xsl stylesheet,
and then called 'xmlroff Tutorial.pdf Tutorial-compat.fo'.

This generated *lots* of errors, all of the form

(process:7926): libfo-CRITICAL **: fo_area_page_size_request:: Cannot split child:: page: FoAreaPage 
(0x8d70668 : 2); child: FoAreaViewportReference (0x8d6ffd0 : 1)


and then seg faulted. The debugger revealed that (if my interpretation
is correct) the crash is due to a stack overlow that stems from
an infinite recursion:

....

#170319 0x002fc227 in fo_area_size_request (child=0x8c07610) at fo-area.c:1734
#170320 0x00301e66 in fo_area_normal_size_request (child=0x8c298a0) at fo-area-normal.c:198
#170321 0x002fc227 in fo_area_size_request (child=0x8c298a0) at fo-area.c:1734
#170322 0x00303e23 in fo_area_page_size_request (child=0x8c0dfd0) at fo-area-page.c:731
#170323 0x002fc227 in fo_area_size_request (child=0x8c0dfd0) at fo-area.c:1734
#170324 0x002fc9ca in fo_area_size_request_default (child=0x8bd9ee8) at fo-area.c:1925
#170325 0x002fc227 in fo_area_size_request (child=0x8bd9ee8) at fo-area.c:1734
#170326 0x002fc9ca in fo_area_size_request_default (child=0x8c07610) at fo-area.c:1925
#170327 0x002fc227 in fo_area_size_request (child=0x8c07610) at fo-area.c:1734
#170328 0x00301e66 in fo_area_normal_size_request (child=0x8c298a0) at fo-area-normal.c:198
#170329 0x002fc227 in fo_area_size_request (child=0x8c298a0) at fo-area.c:1734
#170330 0x00315e76 in fo_list_item_area_new2 (fo_node=0x855b1c8, context=0xbff0c760, 
error=0x8c298a0) at fo-list-item-area.c:119

Segmentation fault

Am I doing something stupid ? Let me know if you need more information.

Thanks,
		Stefan

PS: What does it take for xmlroff to fetch an external graphics' size from
     the graphic itself, instead of requiring it to be provided in the xml input ?

Re: [xmlroff] xmlroff works on Cygwin

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

"Gerrit P. Haase" <ge...@fa...> writes:

> Tony Graham wrote:
>
>> "Gerrit P. Haase" <ge...@fa...> writes:
>>
>>>Tony Graham wrote:
>>>
>>>>"Gerrit P. Haase" <ge...@fa...> writes:
>> ....
>>
>>>>>I needed only two minor changes in Makefile.am to get a clean build
>>>>>(and of course reconfigury with the Cygwin autotools).
>>>>
>>>>What changes?
>>>
>>>Cygwin / Windows does not alllow to link binaries if the references
>>>to functions and other imports cannot be resolved.  Therefore
>>>libtool needs the flsg -no-undefined and all libraries used need to
>>>be added to the link command.
>> Please check the latest CVS version to see if it works for you.
>
> Looks good.  I have compiled the 0.35 release with exactly this change,
> works ok with the test .fo file.  BTW, it is safe to add -no-undefined
> unconditional, doesn't have an affect on platform that don't use it and
> IIRC also Macs need it.

I was following what Pango does, but from the description of -no-undefined, it
appears that you are correct:

------------------------------------------------------------
`--no-undefined'
`-z defs'
     Report unresolved symbol references from regular object files.
     This is done even if the linker is creating a non-symbolic shared
     library.  The switch `--[no-]allow-shlib-undefined' controls the
     behaviour for reporting unresolved references found in shared
     libraries being linked in.
------------------------------------------------------------

I will change it soon.

Regards,


Tony.

Re: [xmlroff] xmlroff works on Cygwin

[Gerrit P. H. <ge...@fa...>]

Tony Graham wrote:

> "Gerrit P. Haase" <ge...@fa...> writes:
> 
>>Tony Graham wrote:
>>
>>>"Gerrit P. Haase" <ge...@fa...> writes:
> 
> ....
> 
>>>>I needed only two minor changes in Makefile.am to get a clean build
>>>>(and of course reconfigury with the Cygwin autotools).
>>>
>>>What changes?
>>
>>Cygwin / Windows does not alllow to link binaries if the references
>>to functions and other imports cannot be resolved.  Therefore
>>libtool needs the flsg -no-undefined and all libraries used need to
>>be added to the link command.
> 
> 
> Please check the latest CVS version to see if it works for you.

Looks good.  I have compiled the 0.35 release with exactly this change,
works ok with the test .fo file.  BTW, it is safe to add -no-undefined
unconditional, doesn't have an affect on platform that don't use it and
IIRC also Macs need it.

Thanks,
Gerrit

Re: [xmlroff] xmlroff works on Cygwin

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

"Gerrit P. Haase" <ge...@fa...> writes:
> Tony Graham wrote:
>> "Gerrit P. Haase" <ge...@fa...> writes:
...
>>>I needed only two minor changes in Makefile.am to get a clean build
>>>(and of course reconfigury with the Cygwin autotools).
>> What changes?
>
> Cygwin / Windows does not alllow to link binaries if the references
> to functions and other imports cannot be resolved.  Therefore
> libtool needs the flsg -no-undefined and all libraries used need to
> be added to the link command.

Please check the latest CVS version to see if it works for you.

Regards,


Tony.

Re: [xmlroff] xmlroff works on Cygwin

[Gerrit P. H. <ge...@fa...>]

Tony Graham wrote:
> "Gerrit P. Haase" <ge...@fa...> writes:
> 
>>Just fetched the 0.3.5 release with pangoxsl-1.6.0.1.
>>
>>It is actually working and producing a real PDF!
> 
> 
> That's good news.
> 
> 
>>I needed only two minor changes in Makefile.am to get a clean build
>>(and of course reconfigury with the Cygwin autotools).
> 
> 
> What changes?

Cygwin / Windows does not alllow to link binaries if the references
to functions and other imports cannot be resolved.  Therefore
libtool needs the flsg -no-undefined and all libraries used need to
be added to the link command.

diff -urN -x .build -x .inst -x .sinst xmlroff-0.3.5-orig/Makefile.am 
xmlroff-0.3.5/Makefile.am
--- xmlroff-0.3.5-orig/Makefile.am	2005-08-14 21:58:34.000000000 +0200
+++ xmlroff-0.3.5/Makefile.am	2005-08-19 20:05:59.430811900 +0200
@@ -37,7 +37,7 @@

  #-release $(VERSION)

-libfo_0_3_la_LDFLAGS = \
+libfo_0_3_la_LDFLAGS = -no-undefined \
  	-version-info $(LT_VERSION_INFO)

  libfo_0_3_includedir = $(includedir)/libfo-0.3
@@ -66,7 +66,15 @@
  	fo/libfo-fo.la			\
  	datatype/libfo-datatype.la	\
  	property/libfo-property.la	\
-	libfo/libfo-libfo.la
+	libfo/libfo-libfo.la \
+	$(PANGOXSL_LIBS) \
+	$(PANGO_LIBS) \
+	$(GNOMEPRINT_LIBS) \
+	$(LIBXSLT_LIBS) \
+	$(GOBJECT_LIBS) \
+	$(FREETYPE_LIBS) \
+	$(POPT_LIBS)	\
+	$(GDKPIXBUF_LIBS)

  xmlroff_SOURCES = \
  	xmlroff.c


Gerrit

Re: [xmlroff] xmlroff works on Cygwin

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

"Gerrit P. Haase" <ge...@fa...> writes:
> Just fetched the 0.3.5 release with pangoxsl-1.6.0.1.
>
> It is actually working and producing a real PDF!

That's good news.

> I needed only two minor changes in Makefile.am to get a clean build
> (and of course reconfigury with the Cygwin autotools).

What changes?

Regards,


Tony.

Re: [xmlroff] presentation

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

Ma Ca <inc...@ya...> writes:
> I'm new in this list.

Thank you for your interest in xmlroff, and welcome to the list.

> My name is Mauro Casciari and principally developing
> web application with open source like mysql, php,
> apache and using web standard (XML,XHML,CSS, etc.)
>
> I started with xmlroff 4 days ago.
> First I try to install it (0.3.4).

There's now xmlroff 0.3.5.

> I have had some troubles with .deb package.

I don't know anything about the .deb package.

What sort of problems are you experiencing?

> I'm thinking to use xmlroff mainly to produce PDF from
> web application.
> First call it from a shell cmd.
> Then my idea is to make a wrapper extension for PHP,
> if 
>  is it possible.
>
> now I can only test the application.
> From a quick view the stack under xmlroff is too big
> for active C\C++ develop.

What do you mean by "too big for active C\C++ develop"?

Regards,


Tony.

[xmlroff] xmlroff works on Cygwin

[Gerrit P. H. <ge...@fa...>]

Hello Tony,

Just fetched the 0.3.5 release with pangoxsl-1.6.0.1.

It is actually working and producing a real PDF!

I needed only two minor changes in Makefile.am to get a clean build
(and of course reconfigury with the Cygwin autotools).


Very good work!

Gerrit
-- 
http://xmlroff.org/

[xmlroff] presentation

[Ma Ca <inc...@ya...>]

Hi All,

I'm new in this list.

My name is Mauro Casciari and principally developing
web application with open source like mysql, php,
apache and using web standard (XML,XHML,CSS, etc.)

I started with xmlroff 4 days ago.
First I try to install it (0.3.4).
I have had some troubles with .deb package.

I'm thinking to use xmlroff mainly to produce PDF from
web application.
First call it from a shell cmd.
Then my idea is to make a wrapper extension for PHP,
if 
 is it possible.

now I can only test the application.
From a quick view the stack under xmlroff is too big
for active C\C++ develop.

Mauro Casciari



	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it

[xmlroff] [ANN] xmlroff 0.3.5

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

xmlroff 0.3.5 is now available from
http://sourceforge.net/projects/xmlroff/.

This release adds semi-real fo:external-graphic support.  It's "semi-real"
because you still need to specify 'content-height' and 'content-width'.

There's also automatic selection of the output format based on the output
file's extension and bug fixes and enhancements from Tim Waugh and Matthew
Daniel.


------------------------------------------------------------
Changes between 0.3.4 and 0.3.5

* fo:external-graphic works (but requires 'content-height' and
  'content-width')
* Stopped removing 'fo:external-graphic' in libfo-compat.xsl (Tim Waugh)
* Able to build in separate directory (Matthew Daniel)
* Default 'auto' output format determines format from output file extension
* Added conformance section to documentation


------------------------------------------------------------
2005-08-17  Tony Graham  <ton...@us...>

	* === Released 0.3.5 ===

	* libfo/fo-doc-gp.c: Restored clipping of layouts.

2005-08-16  Tony Graham  <ton...@us...>

	* NEWS: Updated for 0.3.5.

	* fo/fo-fo.c: Added some doc comments.

2005-08-14  Tony Graham  <ton...@us...>

	* Makefile.am: Added '$(srcdir)' to includes in $(INCLUDES) so can
	build in separate 'object directory'. (Matthew Daniel)

	* property/fo-property-role.c, property/fo-property-role.h:
	Updated to match latest spec-dump.

2005-07-30  Tony Graham  <ton...@us...>

	* xmlroff.fo: Added introductory paragraph.  Added 'auto' option
	for '--format'.

2005-07-29  Tony Graham  <ton...@us...>

	* libfo/fo-doc-gp.c: Added a comment.

2005-07-20  Tony Graham  <ton...@us...>

	* libfo-compat.xsl: Stopped removing fo:external-graphic. (Tim
	Waugh)

2005-07-10  Tony Graham  <ton...@us...>

	* libfo/fo-doc-gp.c: Finally got external graphics working okay.

2005-07-09  Tony Graham  <ton...@us...>

	* libfo/fo-doc-gp.c: Added initial support for 'auto' output
	format.

	* INSTALL.in: Added explanation of result of 'xmlroff xmlroff.fo'.

	* README: Updated dependencies.

	* configure.in: Upped version to 0.3.5.

Re: [xmlroff] cvs head build failure

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

Matthew L Daniel <md...@sc...> writes:
>> Please subscribe to the xmlroff-list if you want to continue to discuss
>> xmlroff.
>
> I didn't realize it was moderated until after I sent the message. That
> is one of many "Fridayisms," as we'll soon see.

It's not really moderated, it's just that only subscribers can post since that
stops (or has so far stopped) spam from reaching the list.

>> > ../fo-context.c:14:29: error: fo-all-property.h: No such file or directory
>> > In file included from ../fo-context.c:16:
>> > ../fo-context-private.h:15:25: error: fo-property.h: No such file or directory
>> 
>> property/fo-all-property.h and property/fo-property.h exist in CVS and should
>> have been checked out when you checked out the 'xmlroff' workspace.
>> 
>> Did you somehow not check out the 'property' subdirectory?
>
> I make a practice of building CVS projects in an "object directory," and
> usually automake projects already support this, so I didn't think about
> it before I posted. A simple `find . -name fo-property.h` would have
> immediately clarified what I did wrong, but I can only claim brain drain
> on this one. Sorry for the list noise.
>
> To atone for my silliness, here is a patch against Makefile.am that
> will correct this.

Committed, thank you, and now in xmlroff 0.3.5.

Regards,


Tony.

Re: [xmlroff] text-align: justify

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

Giacomo Cariello <jw...@bu...> writes:
> Tony Graham wrote:
>> You should set the justification in fo/fo-block-area.c, somewhere near
>> this comment:
>>
>>  /*
>>    FIXME: Pango does not justify.
>>  fo_layout_set_justify (pango_layout, TRUE);
>>  */
>>
>>(Although the variable should be 'fo_layout' now, not 'pango_layout'.)
>>
> Is there a safe way to get true text-align value from that point?

fo_enum_get_value (fo_property_get_value (fo_block_get_text_align (block)))

Regards,


Tony.

Re: [xmlroff] text-align: justify

[Giacomo C. <jw...@bu...>]

Tony Graham wrote:

> You should set the justification in fo/fo-block-area.c, somewhere near
> this
>
>comment:
>
>  /*
>    FIXME: Pango does not justify.
>  fo_layout_set_justify (pango_layout, TRUE);
>  */
>
>(Although the variable should be 'fo_layout' now, not 'pango_layout'.)
>  
>
Is there a safe way to get true text-align value from that point?

Re: [xmlroff] text-align: justify

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

Giacomo Cariello <jw...@bu...> writes:
> Dear xmlroff list,
> I'm posting here a brief summary of what I found out recently regarding
> justification of paragraphs (sorry Tony, I didn't notice your request at
> first, due to scrolling-hurry):

Thanks, Giacomo, for bringing this back to the list.

> 1) Since Pango didn't support justification natively, Damon Chaplin has
> written a patch which adds justification, however the initial patch had
> some problems, so he sent me a new one which should be almost final (in
> attachment). The full justification story can be found here:
> http://bugzilla.gnome.org/show_bug.cgi?id=64538
>
> 2) After applying the above patch, xmlroff could be modified to support
> justification, so I wrote a small patch (in attachment). Please notice
> that text-alignment and direction is still in early stage and most
> combinations aren't supported. I suppose xmlroff needs some kind of
> masterplan to face all the possible orientations/alignments. I'm willing
> to contribute, however I need some time and training on pango etc. ;-)
>
> 3) The result isn't completely satisfactory due to the following problem:
>
> (pseudo-quoting from a private mail to Tony Graham)
>
> ---> snip <---
>
> When a 3-line paragraph is compressed into a 2-line paragraph, the
> following assertion shows up:
>
> process:26210): libfo-CRITICAL **: fo_doc_gp_do_callbacks: assertion
> `line_last >= line_first && line_last <= g_slist_length
> (pango_layout_get_lines (layout)) - 1' failed
>
> (process:26210): libfo-CRITICAL **: fo_doc_gp_do_callbacks: assertion
> `line_last >= line_first && line_last <= g_slist_length
> (pango_layout_get_lines (layout)) - 1' failed
>
> and an empty line is
> showed after the paragraph. I suppose for some reason the real number of
> lines isn't updated correctly. Damon tells me that he doesn't experience
> the above problem using pango with GtkTextView widget, so could you
> please verify how/when lines count are fetched from pango and what
> actually happens if pango returns a shorter line count?
>
> ---> snip <---
>
> Tony answers that:
>
> ---> snip <---
...
> I suspect that xmlroff is getting a count of the lines before the
> justification code removes the last line.

You should set the justification in fo/fo-block-area.c, somewhere near this
comment:

  /*
    FIXME: Pango does not justify.
  fo_layout_set_justify (pango_layout, TRUE);
  */

(Although the variable should be 'fo_layout' now, not 'pango_layout'.)

You could presumably add add a parameter to configure.in to set a #define in
config.h to control an #ifdef in fo_layout_set_justify() to control whether
pango_set_justify() or pango_set_justification() would be called.

Any use of Damon's patch would have to be optional until such time as it
becomes part of Pango.  I have spent more time than I care to recall working
on modified versions of Pango and trying to keep them up to date with the real
Pango -- partly because of an original decision to use PDFlib because of
limitations in GNOME Print back in 2001 and partly because of trying out
additional XSL-specific properties -- always with the best of intentions of
getting my additions into core Pango.

The current PangoXSL attempts much less than did the original PangoPDF because
Pango and GNOME Print finally worked well together, and it's been a relief to
not have to maintain an almost-Pango.

It is also tempting to try adding a Cairo backend to xmlroff to use the new
Cairo support in Pango, and I have to keep telling myself that I need to work
on xmlroff rather than spend more time chasing changes in Pango.  However, if
someone else wants to work on it, I (and the other committers, I'm sure) would
be happy to accept patches.

Regards,


Tony.

[xmlroff] text-align: justify

[Giacomo C. <jw...@bu...>]

Dear xmlroff list,
I'm posting here a brief summary of what I found out recently regarding
justification of paragraphs (sorry Tony, I didn't notice your request at
first, due to scrolling-hurry):

1) Since Pango didn't support justification natively, Damon Chaplin has
written a patch which adds justification, however the initial patch had
some problems, so he sent me a new one which should be almost final (in
attachment). The full justification story can be found here:
http://bugzilla.gnome.org/show_bug.cgi?id=64538

2) After applying the above patch, xmlroff could be modified to support
justification, so I wrote a small patch (in attachment). Please notice
that text-alignment and direction is still in early stage and most
combinations aren't supported. I suppose xmlroff needs some kind of
masterplan to face all the possible orientations/alignments. I'm willing
to contribute, however I need some time and training on pango etc. ;-)

3) The result isn't completely satisfactory due to the following problem:

(pseudo-quoting from a private mail to Tony Graham)

---> snip <---

When a 3-line paragraph is compressed into a 2-line paragraph, the
following assertion shows up:

process:26210): libfo-CRITICAL **: fo_doc_gp_do_callbacks: assertion
`line_last >= line_first && line_last <= g_slist_length
(pango_layout_get_lines (layout)) - 1' failed

(process:26210): libfo-CRITICAL **: fo_doc_gp_do_callbacks: assertion
`line_last >= line_first && line_last <= g_slist_length
(pango_layout_get_lines (layout)) - 1' failed

and an empty line is
showed after the paragraph. I suppose for some reason the real number of
lines isn't updated correctly. Damon tells me that he doesn't experience
the above problem using pango with GtkTextView widget, so could you
please verify how/when lines count are fetched from pango and what
actually happens if pango returns a shorter line count?

---> snip <---

Tony answers that:

---> snip <---

The assertion happens in the xmlroff code in libfo/fo-doc-gp.c:

------------------------------------------------------------
static void
fo_doc_gp_do_callbacks (GnomePrintContext *context,
            PangoLayout       *layout,
            gint              line_first,
            gint              line_last,
            gint              x,
            gint              y)
{
  PangoLayoutIter *iter;
 
  g_return_if_fail (context != NULL);
  g_return_if_fail (PANGO_IS_LAYOUT (layout));
  g_return_if_fail (line_first >= 0);
  g_return_if_fail (line_last >= line_first &&
            line_last <= g_slist_length (pango_layout_get_lines
(layout)) - 1);

  iter = pango_layout_get_iter (layout);

  gint line_number = -1;
  do
    {
      PangoRectangle   logical_rect;
      PangoLayoutLine *line;
      int              baseline;
     
      line_number++;

      if (line_number < line_first)
    {
      continue;
    }

      line = pango_layout_iter_get_line (iter);
     
      pango_layout_iter_get_line_extents (iter, NULL, &logical_rect);
      baseline = pango_layout_iter_get_baseline (iter);
     
      fo_doc_gp_do_line_callbacks (context,
                   line,
                   x + logical_rect.x,
                   y - baseline);

      if (line_number >= line_last)
    {
      break;
    }
    }
  while (pango_layout_iter_next_line (iter));

  pango_layout_iter_free (iter);
}
------------------------------------------------------------

The assertion is to stop you trying to lay out more lines than are in the
PangoLayout.

xmlroff handles printing subsets of the lines in a PangoLayout since a
PangoLayout may be broken across a page.

I suspect that xmlroff is getting a count of the lines before the
justification code removes the last line.

I would expect that the do-while in the function only iterates for as many
lines as there are in the PangoLayout and that what you're seeing as an
extra
line is because xmlroff is leaving enough room for the original 3-line block
and not the current 2-line block.

---> snip <---

I suppose that's about all.

Sincerely,

- Giacomo Cariello

Re: [xmlroff] text-align justify

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

Giacomo,

Thank you for your interest in xmlroff, but please post from the email address
by which you are subscribed.

Giacomo Cariello <jw...@ph...> writes:
> I've recently started using xmlroff for document generation purposes and
> I found out that text-align="justify" property doesn't work as expected.
> I've read somewhere that justify value isn't supported by Pango. Is this
> true? Can anyone give me some hints on the problem (what files/routines
> should be patched, etc.)?

The documentation for Pango's pango_layout_set_justify() [1] still includes:

   Note that as of Pango-1.4, this functionality is not yet implemented.

The GNOME bugzilla bug report about Pango and 'justify' is at [2].

Regards,


Tony.

[1] http://cvs.gnome.org/viewcvs/pango/pango/pango-layout.c?rev=1.140&view=markup
[2] http://bugzilla.gnome.org/show_bug.cgi?id=64538

[xmlroff] text-align justify

[Giacomo C. <jw...@ph...>]

Dear list,
I've recently started using xmlroff for document generation purposes and
I found out that text-align="justify" property doesn't work as expected.
I've read somewhere that justify value isn't supported by Pango. Is this
true? Can anyone give me some hints on the problem (what files/routines
should be patched, etc.)?

- Giacomo Cariello

[xmlroff] infinite loop

[Matthew L D. <md...@sc...>]

I don't claim to be any less tired, but I am tried to make this post
more intelligent than my last. :-)

I build today's CVS to try out the external-graphic support. I have a
simple "hello, world" xhtml page that I transformed into xsl-fo using
the xhtml2fo.xsl from http://www.antennahouse.com. 

I understand there will be lots of warnings and errors about unsupported
properties and such, but in this case, xmlroff goes into an infinite
loop on the attached fo file. The last two lines in the attached log
repeat for as long as I let the program run.

I am going to craft an xml-fo "by hand" and see if I can produce a more
realistic test, but I figured you would want to know about this.

  -- /v\atthew

Re: [xmlroff] cvs head build failure

[Matthew L D. <md...@sc...>]

> Please subscribe to the xmlroff-list if you want to continue to discuss
> xmlroff.

I didn't realize it was moderated until after I sent the message. That
is one of many "Fridayisms," as we'll soon see.

> > ../fo-context.c:14:29: error: fo-all-property.h: No such file or directory
> > In file included from ../fo-context.c:16:
> > ../fo-context-private.h:15:25: error: fo-property.h: No such file or directory
> 
> property/fo-all-property.h and property/fo-property.h exist in CVS and should
> have been checked out when you checked out the 'xmlroff' workspace.
> 
> Did you somehow not check out the 'property' subdirectory?

I make a practice of building CVS projects in an "object directory," and
usually automake projects already support this, so I didn't think about
it before I posted. A simple `find . -name fo-property.h` would have
immediately clarified what I did wrong, but I can only claim brain drain
on this one. Sorry for the list noise.

To atone for my silliness, here is a patch against Makefile.am that
will correct this.

  Sorry about that,
  -- /v\atthew

Re: [xmlroff] cvs head build failure

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

Matthew,

Thank you for your interest in xmlroff.

Please subscribe to the xmlroff-list if you want to continue to discuss
xmlroff.

Matthew L Daniel <md...@sc...> writes:
> I saw that CVS has support for fo:external-graphic and wanted to try it
> out. I received the following build failure. I suspect it means I have
> to re-run spec-dump but wanted to check before I started down that path.
>
>   Thank you,
>   -- /v\atthew
>
>  gcc -DHAVE_CONFIG_H -I. -I.. -I. -DG_LOG_DOMAIN=\"libfo\"
> -I/usr/include/libxml2 -Iarea -Iexpr -Ifo -Idatatype -Iproperty -Iutil
> -O2 -g -pipe -m64 -I/usr/include/pangoxsl -I/usr/include/pango-1.0
> -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
> -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
> -I/usr/lib64/glib-2.0/include -I/usr/include/libgnomeprint-2.2
> -I/usr/include/libart-2.0 -I/usr/include/glib-2.0
> -I/usr/lib64/glib-2.0/include -I/usr/include/libxml2
> -I/usr/include/pango-1.0 -I/usr/include/freetype2 -Wall -MT
> fo-context.lo -MD -MP -MF .deps/fo-context.Tpo -c ../fo-context.c  -fPIC -DPIC -o .libs/fo-context.o
> ../fo-context.c:14:29: error: fo-all-property.h: No such file or directory
> In file included from ../fo-context.c:16:
> ../fo-context-private.h:15:25: error: fo-property.h: No such file or directory

property/fo-all-property.h and property/fo-property.h exist in CVS and should
have been checked out when you checked out the 'xmlroff' workspace.

Did you somehow not check out the 'property' subdirectory?

You do not have to copy anything from spec-dump into xmlroff: when updates are
necessary, I or someone else checks the updated files into the 'xmlroff'
workspace.

Regards,


Tony.

[xmlroff] cvs head build failure

[Matthew L D. <md...@sc...>]

I saw that CVS has support for fo:external-graphic and wanted to try it
out. I received the following build failure. I suspect it means I have
to re-run spec-dump but wanted to check before I started down that path.

  Thank you,
  -- /v\atthew

 gcc -DHAVE_CONFIG_H -I. -I.. -I. -DG_LOG_DOMAIN=\"libfo\"
-I/usr/include/libxml2 -Iarea -Iexpr -Ifo -Idatatype -Iproperty -Iutil
-O2 -g -pipe -m64 -I/usr/include/pangoxsl -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/include/libgnomeprint-2.2
-I/usr/include/libart-2.0 -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/include/libxml2
-I/usr/include/pango-1.0 -I/usr/include/freetype2 -Wall -MT
fo-context.lo -MD -MP -MF .deps/fo-context.Tpo -c ../fo-context.c  -fPIC -DPIC -o .libs/fo-context.o
../fo-context.c:14:29: error: fo-all-property.h: No such file or directory
In file included from ../fo-context.c:16:
../fo-context-private.h:15:25: error: fo-property.h: No such file or directory

Re: [xmlroff] fo:external-graphic

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

Tim Waugh <tw...@re...> writes:
> On Sun, Jul 10, 2005 at 11:58:48PM +0100, Tony Graham wrote:
>> The code now in CVS formats fo:external-graphic with the GNOME Print
>> backend as well as used to be done with the PDFlib backend.  I.e.,
>> fo:external-graphic works, but you need to specify content-width and
>> content-height to get space allocated for the graphic.
>> 
>> Can someone try it out to see if it works for them?  If it does, I'll
>> then make a 0.3.5 and announce that on the external lists rather than
>> 0.3.4.
>
> Works here in that I get pictures included in the output (yay!),
> except of course you need to make this change to libfo-compat.xsl:

Committed, thanks.

...
> A couple of things seem wrong though:
>
> * Transparency seems to come out as black though -- is that something
>   that's easy to fix?

Presumably it would be fixed by some combination of GdkPixbuf and
libgnomeprint and/or your viewer/printer.

xmlroff is just opening the file with GdkPixbuf and handing it to
libgnomeprint.

There is undoubtedly scope for me to have added bugs, but AFAICT it's just the
standard usage of those two libraries.

I have a vague memory of seeing something about something like that on the
gnome-print-list, but I could be imagining it.

> * My captions seem to disappear, perhaps underneath the image.  I'm
>   using DocBook XML like this:
>
>     <figure id="fig-scale">
>       <title>Scale image using <application>The GIMP</application></title>
>       <mediaobject>
>         <imageobject>
>           <imagedata fileref="figs/photos-scale-en.png" format="PNG"
> 		     contentwidth="3in" contentdepth="4in"/>
>         </imageobject>
>       </mediaobject>
>     </figure>
>
>   I can see the caption in the XSL-FO, but not in the resulting PDF.
>   Known issue with external-graphic placement?

Not previously known, anyway.

Pango is supposed to be told the size of the space to leave, but I expect that
the title is in a separate fo:block in the FO anyway.

Two things come to mind:

 - The graphic is being rendered at the wrong resolution and is therefore too
   big; or

 - You have a small, fixed line-height and the graphic is overflowing that and
   overwriting the next block area.

Of course the other thing that comes to mind is that the graphic (and all
inline FO) handling still needs major work.  I have a week off work next month
so I should have time for xmlroff then.

Regards,


Tony.

Re: [xmlroff] fo:external-graphic

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

On Sun, Jul 10, 2005 at 11:58:48PM +0100, Tony Graham wrote:

> The code now in CVS formats fo:external-graphic with the GNOME Print
> backend as well as used to be done with the PDFlib backend.  I.e.,
> fo:external-graphic works, but you need to specify content-width and
> content-height to get space allocated for the graphic.
>=20
> Can someone try it out to see if it works for them?  If it does, I'll
> then make a 0.3.5 and announce that on the external lists rather than
> 0.3.4.

Works here in that I get pictures included in the output (yay!),
except of course you need to make this change to libfo-compat.xsl:

Index: libfo-compat.xsl
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/xmlroff/xmlroff/libfo-compat.xsl,v
retrieving revision 1.14
diff -d -u -r1.14 libfo-compat.xsl
--- libfo-compat.xsl	8 Jul 2005 12:36:06 -0000	1.14
+++ libfo-compat.xsl	20 Jul 2005 15:32:18 -0000
@@ -150,12 +150,6 @@
     </fo:block>
   </xsl:template>
=20
-  <xsl:template match=3D"fo:external-graphic">
-    <xsl:if test=3D"$verbose">
-      <xsl:message>Removing 'fo:external-graphic'.</xsl:message>
-    </xsl:if>
-  </xsl:template>
-
   <xsl:template match=3D"fo:region-body/@region-name">
     <xsl:if test=3D"$verbose">
       <xsl:message>Removing 'fo:region-body' region-name attribute.</xsl:m=
essage>

A couple of things seem wrong though:

* Transparency seems to come out as black though -- is that something
  that's easy to fix?

* My captions seem to disappear, perhaps underneath the image.  I'm
  using DocBook XML like this:

    <figure id=3D"fig-scale">
      <title>Scale image using <application>The GIMP</application></title>
      <mediaobject>
        <imageobject>
          <imagedata fileref=3D"figs/photos-scale-en.png" format=3D"PNG"
		     contentwidth=3D"3in" contentdepth=3D"4in"/>
        </imageobject>
      </mediaobject>
    </figure>

  I can see the caption in the XSL-FO, but not in the resulting PDF.
  Known issue with external-graphic placement?

Tim.
*/