xmlroff-list — xmlroff XSL formatter discussion list

[xmlroff] fo:external-graphic

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

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.

Regards,


Tony.

[xmlroff] [ANN] xmlroff 0.3.4

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

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

This is a snapshot of the current code.  The good news is that it has
some memory leak fixes and the option of specifying PostScript output.
The bad news is that I had to add the PostScript output because using
fo:external-graphic currently produces invalid PDF (according to
'acroread', anyway) but there's no graphic visible in the PostScript
output either.  More work is obviously required.

Regards,


Tony.

Changes between 0.3.3 and 0.3.4

* Add '--format' parameter for PDF or PostScript output
* Reduced memory leakage
* Partially re-implemented fo:external-graphic support
* Corrected whitespace handling in libfo-compat.xsl (Tim Waugh)
* Corrected "url()" handling
* 86% symbol docs coverage


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

	* === Released 0.3.4 ===

	* libfo-compat.xsl: Changed to removing all fo:external-graphic.
	
2005-07-07  Tony Graham  <ton...@us...>

	* NEWS: Updated for 0.3.4.

	* libfo/fo-libfo-context.c, libfo/fo-libfo-context.h: Added
	(unusable) SVG output format.

	* datatype/fo-uri-specification.c: Added some doc comments.

	* expr/fo-expr-eval.c: Stopped compiler error about return value
	from void function.

	* libfo/fo-doc-gp.c: Equating 'auto' format to 'pdf' for now.

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

	* libfo/fo-doc-gp-private.h, libfo/fo-doc-gp.c: Added setting
	output format from FoLibfoContext.  Removed some testing code.

	* fo/fo-external-graphic.c: Stopped offsetting image by
	content-height when placing image.

	* expr/fo-expr-eval.c: Corrected handling of quoted URLs.

	* xmlroff.fo: Added '--format' option.

	* libfo-compat.xsl: Removed munging of URLs in 'src' attributes.

2005-06-27  Tony Graham  <ton...@us...>

	* expr/fo-expr-env.c: Removed 'url' from list of functions.

	* expr/fo-expr-eval.c, expr/fo-expr-eval.h: Added handling
	'url(...)' instead of treating as a function.

	* expr/fo-expr-func.c, datatype/fo-uri-specification.c,
	datatype/fo-uri-specification.h: Changed to use
	fo_uri_specification_new_with_value().

	* libfo/fo-doc-gp-private.h, libfo/fo-doc-gp.c, libfo/fo-doc-gp.h:
	Trying to implement image rendering.

	* libfo/fo-libfo-context.c, libfo/fo-libfo-context.h: Added
	FO_ENUM_FORMAT_AUTO.

	* libfo/fo-libfo-basic.c, libfo/fo-doc-private.h, libfo/fo-doc.c,
	libfo/fo-doc.h: Added a FoLibfoContext argument to
	fo_doc_open_file().

	* xmlroff.c: Added '-format' parameter for setting output file
	format.

	* libfo/Makefile.am, libfo-0.3.pc.in, configure.in, Makefile.am:
	Added dependency on GdkPixbuf for handling external graphics.

2005-06-13  Tony Graham  <ton...@us...>

	* result-to-fo.c: Removed a commented-out #include.

	* area/fo-area-table-cell.c: Added workaround for '-0' max_height
	values.

	* datatype/fo-integer.c: Added getting integer value from FoNumber
	datatype.  Really should be a fo_datatype_get_integer_value()
	function.

	* property/fo-property-src.c, property/fo-property-src.h:
	Whitespace and copyright year changes only.

	* libfo-compat.xsl: Added template to quote unquoted content of
	'url(...)' in 'src' properties.

2005-06-12  Tony Graham  <ton...@us...>

	* libfo-compat.xsl: Added 'background-image' to set of unsupported
	properties.

	* libfo-compat.xsl: Fix for whitespace handling (Tim Waugh).

2005-05-03  Tony Graham  <ton...@us...>

	* property/fo-property-font-family.c, property/fo-property-id.c,
	property/fo-property-inline-progression-dimension.c,
	libfo/fo-font-desc.c, property/fo-property-dominant-baseline.c,
	fo/fo-block-area.c, fo-context-util.c, result-to-fo.c: Fixed
	memory leaks.

	* property/fo-property-keep-with-next.c,
	property/fo-property-keep-with-previous.c,
	property/fo-property-keep-together.c, datatype/fo-keep.h,
	datatype/fo-length-range.c, datatype/fo-length-range.h,
	fo/fo-table.c, area/fo-area-spanning-table-cell.c,
	area/fo-area-table-cell.c, area/fo-area-table-continuation.c,
	area/fo-area-table.c, datatype/fo-keep.c, area/fo-area-area.c:
	Changed FoKeep and FoLengthRange to use FoEnum enums.

	* configure.in: Upped version to 0.3.4.

Re: [xmlroff] Advice for Windows Compilation

[becarios mx <bec...@ya...>]

Thanks for your answer, Mr. Graham. If I find a way to
achieve this, be sure I will be glad to share it with
the community.

Greetings,
Elsa.

----- Original Message -----
From: "Tony Graham" <Ton...@Su...>
To: xml...@li...
Date: Thu, 07 Jul 2005 22:09:14 +0100
Subject: Re: [xmlroff] Advice for Windows Compilation

> 
> becarios mx <bec...@ya...> writes:
> > I am interested in compile xmlroff 0.3.3 for
Windows,
> > and as I have been reading on this list, it seems
that
> > at least Mr. Jesper Stigberg has done it.
> >
> > I would like to have an advice of how can I
achieve
> > this or if there is a binary compilation
somewhere. I
> > would like to have it as a static library or
dinamic
> > if the first option is not possible.
> 
> Thank you for your interest in xmlroff.
> 
> I have no experience with compiling xmlroff under
Windows. Hopefully
> someone else can offer advice.
> 
> If you do find that you need to make changes to get
xmlroff to
> compile, you are welcome to submit patches so it's
easier for the next
> person who has to do it.
> 
> Regards,
> 
> 
> Tony.
> 
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With
Dual!' webinar 
> happening
> July 14 at 8am PDT/11am EDT. We invite you to
explore the latest in 
> dual
> core and dual graphics technology at this free one
hour event hosted by 
> HP, 
> AMD, and NVIDIA. To register visit
http://www.hp.com/go/dualwebinar
> _______________________________________________
> xmlroff-list mailing list
> xml...@li...
>
https://lists.sourceforge.net/lists/listinfo/xmlroff-list
>        


	
	
		
___________________________________________________________ 
Do You Yahoo!? 
La mejor conexión a Internet y <b >2GB</b> extra a tu correo por $100 al mes. http://net.yahoo.com.mx 

Re: [xmlroff] Advice for Windows Compilation

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

becarios mx <bec...@ya...> writes:
> I am interested in compile xmlroff 0.3.3 for Windows,
> and as I have been reading on this list, it seems that
> at least Mr. Jesper Stigberg has done it.
>
> I would like to have an advice of how can I achieve
> this or if there is a binary compilation somewhere. I
> would like to have it as a static library or dinamic
> if the first option is not possible.

Thank you for your interest in xmlroff.

I have no experience with compiling xmlroff under Windows.  Hopefully
someone else can offer advice.

If you do find that you need to make changes to get xmlroff to
compile, you are welcome to submit patches so it's easier for the next
person who has to do it.

Regards,


Tony.

[xmlroff] Advice for Windows Compilation

[becarios mx <bec...@ya...>]

Hello!

I am interested in compile xmlroff 0.3.3 for Windows,
and as I have been reading on this list, it seems that
at least Mr. Jesper Stigberg has done it.

I would like to have an advice of how can I achieve
this or if there is a binary compilation somewhere. I
would like to have it as a static library or dinamic
if the first option is not possible.

Thanks for your help.

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis! 
Regístrate ya - http://correo.yahoo.com.mx/ 

[xmlroff] Pango 1.9.0 adds Cairo support

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

See
http://mail.gnome.org/archives/gtk-i18n-list/2005-June/msg00018.html

If Pango supports Cairo, that will make it easier to make a FoDocCairo
variant that uses Cairo for drawing.

Regards,


Tony.

[xmlroff] [ xmlroff-Bugs-1222524 ] indexterm-related crash

[SourceForge.net <no...@so...>]

Bugs item #1222524, was opened at 2005-06-17 10:43
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=536897&aid=1222524&group_id=73148

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: xmlroff executable
Group: v0.3.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Waugh (twaugh)
Assigned to: Tony Graham (tonygraham)
Summary: indexterm-related crash

Initial Comment:
Using today's CVS.

$ ~/xmlroff/xmlroff -d 255 input.fo

(process:6993): libfo-CRITICAL **: fo-fo-error: Cannot
rewrite fo:block content.Object path:
/FoTree[1]/root[1]/page-sequence[3]/flow[1]/block[1]/block[1]
(process:6993): libfo-DEBUG: get_text_attr_list:: block
text: 'book title'
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist: 0x898fde4
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist length: 11
(process:6993): libfo-DEBUG: FoLayoutGP (0x8a5d8c8 : 1)
(process:6993): libfo-DEBUG: get_text_attr_list:: block
text: ''
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist: (nil)
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist length: 0
(process:6993): libfo-DEBUG: FoLayoutGP (0x8a8ffb8 : 1)
(process:6993): libfo-DEBUG: get_text_attr_list:: block
text: 'book title'
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist: 0x898ffd0
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist length: 11
(process:6993): libfo-DEBUG: FoLayoutGP (0x8aa4378 : 1)
(process:6993): libfo-DEBUG: get_text_attr_list:: block
text: ''
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist: (nil)
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist length: 0
(process:6993): libfo-DEBUG: FoLayoutGP (0x8aee9f8 : 1)
(process:6993): libfo-DEBUG: get_text_attr_list:: block
text: 'Table of Contents'
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist: 0x89900b4
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist length: 11
(process:6993): libfo-DEBUG: FoLayoutGP (0x8b07258 : 1)
(process:6993): libfo-DEBUG: get_text_attr_list:: block
text: '1. chapter title  '
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist: 0x89902b8
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist length: 41
(process:6993): libfo-DEBUG: FoLayoutGP (0x8af7df0 : 1)
(process:6993): libfo-DEBUG: get_text_attr_list:: block
text: 'section title  '
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist: 0x89904c8
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist length: 41
(process:6993): libfo-DEBUG: FoLayoutGP (0x8b0f278 : 1)
(process:6993): libfo-DEBUG: get_text_attr_list:: block
text: 'Index  '
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist: 0x8b107c0
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist length: 41
(process:6993): libfo-DEBUG: FoLayoutGP (0x8b130e0 : 1)
(process:6993): libfo-DEBUG: get_text_attr_list:: block
text: 'Chapter?1.?chapter title'
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist: 0x8b10808
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist length: 11
(process:6993): libfo-DEBUG: FoLayoutGP (0x8b16bd0 : 1)
(process:6993): libfo-DEBUG: get_text_attr_list:: block
text: 'section title'
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist: 0x8b1097c
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist length: 11
(process:6993): libfo-DEBUG: FoLayoutGP (0x8b22e30 : 1)
(process:6993): libfo-DEBUG: get_text_attr_list:: block
text: ''
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist: (nil)
(process:6993): libfo-DEBUG: get_text_attr_list::
attr_glist length: 0
(process:6993): libfo-DEBUG: FoLayoutGP (0x8b27df0 : 1)

(process:6993): libfo-CRITICAL **:
fo_inline_fo_get_text_attr_list: assertion
`FO_IS_INLINE_FO (fo_inline_fo)' failed

(process:6993): libfo-CRITICAL **:
fo_property_common_font_get_pango_attrs: assertion
`FO_IS_PROPERTY_FONT_FAMILY (font_family)' failed

(process:6993): libfo-CRITICAL **:
fo_property_text_property_new_attr: assertion `property
!= NULL' failed
Segmentation fault

I'll attach the original indexterm.xml DocBook XML; the
XSL-FO produced from docbook-xsl-1.68.1; and the input
to xmlroff, which is the XSL-FO passed through
libfo-compat.xsl.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=536897&aid=1222524&group_id=73148

[xmlroff] Trial posting of xmlroff bugs to xmlroff-list

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

FYI, I am trying out copying of new xmlroff bug reports to this list
to see if they generate any discussion or any response.

You are welcome to comment on the usefulness or otherwise of this
idea.

Regards,


Tony.

[xmlroff] No xmlroff release this month [Was: xmlroff release is delayed]

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

Tony Graham <Ton...@Su...> writes:
> But if you've been looking for it, you'd have realised that already.
>
> I had a bad sector on my Linux partition, so I moved to a Linux on a
> different partition, but now I have a font problem:
>
> ------------------------------------------------------------
> ./xmlroff xmlroff.fo
>
> (process:6569): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed
>
> (process:6569): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed
>
> ** (process:6569): CRITICAL **: _pango_engine_shape_shape: assertion `PANGO_IS_FONT (font)' failed
>
> ** ERROR **: file shape.c: line 75 (pango_shape): assertion failed: (glyphs->num_glyphs > 0)
> aborting...
> Aborted
> ------------------------------------------------------------
>
> It makes it a bit hard to test xmlroff.

Problem solved.  I recompiled and re-installed Pango 1.6.0 and the
problem went away.

However, since it is already the middle of this month, I will delay
the next release until "on or about" the first of next month.

Anyone wishing to use the recent memory leak fixes can do so by
getting the current code from CVS.

Regards,


Tony.

[xmlroff] [ xmlroff-Bugs-1220023 ] xmlroff should support unquoted url() values

[SourceForge.net <no...@so...>]

Bugs item #1220023, was opened at 2005-06-13 23:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=536897&aid=1220023&group_id=73148

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: property
Group: v0.3.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Graham (tonygraham)
Assigned to: Tony Graham (tonygraham)
Summary: xmlroff should support unquoted url() values

Initial Comment:
fo-expr-eval.c should be modified to test whether a
function name is 'url' and, if so, parse the "function"
content differently than for normal functions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=536897&aid=1220023&group_id=73148

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

Re: [xmlroff] [patch] libfo-compat.xsl and significant space

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

Tim Waugh <tw...@re...> writes:
> Here is a patch against current CVS that fixes whitespace handling in
> libfo-compat.xsl.

Committed.  Thank you.

Regards,


Tony.

[xmlroff] [patch] libfo-compat.xsl and significant space

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

Hi,

Here is a patch against current CVS that fixes whitespace handling in
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.9
diff -d -u -r1.9 libfo-compat.xsl
--- libfo-compat.xsl	1 May 2005 19:07:09 -0000	1.9
+++ libfo-compat.xsl	10 Jun 2005 17:07:53 -0000
@@ -50,9 +50,6 @@
=20
   <xsl:output method=3D"xml"/>
=20
-  <xsl:strip-space elements=3D"*"/>
-  <xsl:preserve-space elements=3D"fo:title fo:block fo:bidi-override fo:in=
line fo:leader fo:basic-link fo:multi-case fo:multi-toggle fo:wrapper fo:ma=
rker"/>
-
   <xsl:param name=3D"verbose" select=3D"false()"/>
=20
   <xsl:template match=3D"/">
@@ -62,6 +59,17 @@
     <xsl:apply-templates/>
   </xsl:template>
  =20
+  <xsl:template match=3D"text()">
+    <xsl:if test=3D"contains(' &#xA;',substring(.,1,1))">
+      <xsl:text> </xsl:text>
+    </xsl:if>
+    <xsl:value-of select=3D"normalize-space()"/>
+    <xsl:if test=3D"string-length() > 1 and
+                  contains(' &#xA;',substring(.,string-length(),1))">
+      <xsl:text> </xsl:text>
+    </xsl:if>
+  </xsl:template>
+
   <xsl:template match=3D"fo:list-item-label/text()">
     <xsl:if test=3D"$verbose">
       <xsl:message>Correcting text child of fo:list-item-label by removing=
 text</xsl:message>

Tim.
*/

Re: [xmlroff] [patch] libfo-compat.xsl and significant space

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

On Fri, Jun 10, 2005 at 05:17:43PM +0100, Tim Waugh wrote:

> FWIW, the current CVS libfo-compat.xsl still gets significant space
> wrong.

Oops, please ignore this.  I accidentally used the 0.3.3
libfo-compat.xsl instead of the CVS one.

Tim.
*/

Re: [xmlroff] [patch] libfo-compat.xsl and significant space

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

FWIW, the current CVS libfo-compat.xsl still gets significant space
wrong.

Tim.
*/

On Thu, Mar 10, 2005 at 04:21:13PM +0000, Tony Graham wrote:

> Tim Waugh <tw...@re...> writes:
>=20
> > On Thu, Mar 10, 2005 at 12:34:23AM +0000, Tony Graham wrote:
> >
> >> Thanks, but instead I added <xsl:preserve-space> and listed all the
> >> FOs with #PCDATA in their content model.  Please confirm whether or
> >> not that does the job.
> >
> > It doesn't.  I get things like this:
> >
> > press<fo:inline font-weight=3D"bold">F8</fo:inline>for the menu
> >
> > from a DocBook para fragment that had:
> >
> >     press <keycap>F8</keycap>
> >     for the menu
>=20
> This template rule may be the problem:
>=20
>   <xsl:template match=3D"text()">
>     <xsl:value-of select=3D"normalize-space()"/>
>   </xsl:template>
>=20
> The real problem, for xmlroff, is the whitespace at the beginning of
> the lines.
>=20
> I'll look again at your whitespace patch.
[...]

Re: [xmlroff] xmlroff release is delayed

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

Tony Graham wrote:

> Synopsis appears to have some interesting features, and I'd be more
> inclined to use it if all it took was a make target.

Point taken.

Regards,
		Stefan

Re: [xmlroff] xmlroff release is delayed

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

Stefan Seefeld <se...@sy...> writes:
> Tony Graham wrote:
>>>Speaking of which, do you have a tool to generate documentation from your
>>>source code ? Synopsis has a new C parser and I'm looking for a victim... :-)
>> gtk-doc.
>> Can Synopsis parse gtk-doc comments?
>
> yes, you can teach it to parse comments as you want, by means of python
> modules.

I'm sure someone could.  Once done, it would of course be usable by
any GTK+/GNOME-like project.

>> Can Synopsis included "static" documentation and annotations to the
>> generated documentation in the way that gtk-doc can?
>
> I'm not sure what you mean in detail, but it is certainly possible
> to either include links to external docs, or even mix in existing
> documents into a single generated document.

I hope that you have looked at the generated documentation at some
point...

The sections under "Things to know" are "static" documentation
generated from DocBook documents in the 'docs' directory.

The files in docs/tmpl are initially generated by gtk-doc, but it's
possible to add snippets of DocBook markup to them, and the snippets
will be included in the appropriate place in the generated HTML.

...
>> If you can modify configure.in to enable Synopsis documentation
>> generation (with no ill-effect if Synopsis is not present) just as
>> --enable-gtk-doc enables gtk-doc documentation, then you can check it
>> in.
>> Synopsis would have to be an option alongside gtk-doc, and for the
>> moment at least, the xmlroff distributions would still ship with
>> gtk-doc documentation.
>
> I'll have a look. If gtk-doc is already doing a fine job for what
> you want it to do there is no reason to change / add anything.

Synopsis appears to have some interesting features, and I'd be more
inclined to use it if all it took was a make target.

Regards,


Tony.

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] xmlroff release is delayed

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

Tony Graham wrote:

>>Speaking of which, do you have a tool to generate documentation from your
>>source code ? Synopsis has a new C parser and I'm looking for a victim... :-)
> 
> 
> gtk-doc.
> 
> Can Synopsis parse gtk-doc comments?

yes, you can teach it to parse comments as you want, by means of python
modules.

> Can Synopsis included "static" documentation and annotations to the
> generated documentation in the way that gtk-doc can?

I'm not sure what you mean in detail, but it is certainly possible
to either include links to external docs, or even mix in existing
documents into a single generated document.

Synopsis can also be used to create a cross-referenced view of the
source code itself, so you can navigate through the code by clicking
on variables and function calls, taking you to their respective
declaration/definition.

> If you can modify configure.in to enable Synopsis documentation
> generation (with no ill-effect if Synopsis is not present) just as
> --enable-gtk-doc enables gtk-doc documentation, then you can check it
> in.
> 
> Synopsis would have to be an option alongside gtk-doc, and for the
> moment at least, the xmlroff distributions would still ship with
> gtk-doc documentation.

I'll have a look. If gtk-doc is already doing a fine job for what
you want it to do there is no reason to change / add anything.

Regards,
		Stefan

Re: [xmlroff] xmlroff release is delayed

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

Stefan Seefeld <se...@sy...> writes:
> Stefan Seefeld wrote:
>> Tony Graham wrote:
>>
>>> But if you've been looking for it, you'd have realised that already.
>> Indeed. :-)
>> I'm in the middle of a release of my own right now (synopsis 0.8),
>> and
>> I was trying to build pdf documentation, which reminded me. :-)
>
> Speaking of which, do you have a tool to generate documentation from your
> source code ? Synopsis has a new C parser and I'm looking for a victim... :-)

gtk-doc.

Can Synopsis parse gtk-doc comments?

Can Synopsis included "static" documentation and annotations to the
generated documentation in the way that gtk-doc can?

If you can modify configure.in to enable Synopsis documentation
generation (with no ill-effect if Synopsis is not present) just as
--enable-gtk-doc enables gtk-doc documentation, then you can check it
in.

Synopsis would have to be an option alongside gtk-doc, and for the
moment at least, the xmlroff distributions would still ship with
gtk-doc documentation.

Regards,


Tony.

Re: [xmlroff] xmlroff release is delayed

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

Stefan Seefeld wrote:
> Tony Graham wrote:
> 
>> But if you've been looking for it, you'd have realised that already.
> 
> 
> Indeed. :-)
> 
> I'm in the middle of a release of my own right now (synopsis 0.8), and
> I was trying to build pdf documentation, which reminded me. :-)

Speaking of which, do you have a tool to generate documentation from your
source code ? Synopsis has a new C parser and I'm looking for a victim... :-)

(see http://synopsis.fresco.org/boost/ for documentation I generated from
the boost python library (C++) )

Regards,
		Stefan

Re: [xmlroff] xmlroff release is delayed

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

Stefan Seefeld <se...@sy...> writes:
> Tony Graham wrote:
>> The simple answer, which I didn't have before, is
>> gdk_pixbuf_new_from_file().
>> Once the miminum of having graphics again actually works, then as you
>> note, there's all the interrelated graphics properties to take care
>> of.
>
> I can't wait !!

So you're volunteering?

Regards,


Tony.

Re: [xmlroff] xmlroff release is delayed

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

Tony Graham wrote:

> The simple answer, which I didn't have before, is
> gdk_pixbuf_new_from_file().
> 
> Once the miminum of having graphics again actually works, then as you
> note, there's all the interrelated graphics properties to take care
> of.

I can't wait !!

Regards,
		Stefan

Re: [xmlroff] xmlroff release is delayed

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

Stefan Seefeld <se...@sy...> writes:
> Tony Graham wrote:
>> But if you've been looking for it, you'd have realised that already.
>
> Indeed. :-)

It's nice to know that someone is looking for it.

> I'm in the middle of a release of my own right now (synopsis 0.8), and
> I was trying to build pdf documentation, which reminded me. :-)
>
> What should we expect from the next release ? How is the work on

That depends on whether I get my system working soon and package what
I have as the next release or wait until next month and somehow find
some time to work on xmlroff.

The only changes so far are plugged memory leaks: formatting
xmlroff.fo leaks less than 50% of what it used to.  There's still a
lot of leaks and a lot of unreleased memory to go, however.

> external graphics going ? While fop does support them, there are all

The simple answer, which I didn't have before, is
gdk_pixbuf_new_from_file().

Once the miminum of having graphics again actually works, then as you
note, there's all the interrelated graphics properties to take care
of.

> kinds of issues with scaling and bounding box calculation (or something
> similar), so I was hoping that xmlroff would get to that soon. (I'm
> looking for support for external png and svg, in particular.)
>
> Good luck with your system !

Thanks.

Regards,


Tony.

Re: [xmlroff] xmlroff release is delayed

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

Tony Graham wrote:
> But if you've been looking for it, you'd have realised that already.

Indeed. :-)

I'm in the middle of a release of my own right now (synopsis 0.8), and
I was trying to build pdf documentation, which reminded me. :-)

What should we expect from the next release ? How is the work on
external graphics going ? While fop does support them, there are all
kinds of issues with scaling and bounding box calculation (or something
similar), so I was hoping that xmlroff would get to that soon. (I'm
looking for support for external png and svg, in particular.)

Good luck with your system !

Stefan