Re: [xmlroff] libfo interface and PHP ext

[Mauro C. <inc...@ya...>]

--- Tony Graham <Ton...@Su...> ha scritto: 

> "Mauro C." <inc...@ya...> writes:
> > I'm continuing dev xmlroff php extension and study
> > libfo.
> 
> Great.
> 
> > my problem is that actualy the only way to work
> with
> > libfo is to write tmp file.
> >
> > I'agree the libfo abstract from xml
> implementation.
> >
> > I've found two solution:
> >
> > 1) include libxml in xmlroff php ext and then set
> > FoXmlDoc->xml_doc directly.
> > (I've seen fo-xml-doc-private.h).
> >
> > 2) change libfo interface and allow for examples
> > fo_xml_doc_parse_file and fo_xml_doc_parse_memory,
> and
> > generally the possibility to work with mem and/or
> > file.
> 
> Isn't there a third solution:
> 
> 3) Write an adapter such as
> fo_xml_doc_new_from_DOMXML(DOMXML), since you said
>    last week that DOMXML was the PHP wrapper on
> xmlDocPtr.

yes, i've to link ext to libxml.

> 
>    I don't know what the function name would look
> like as an PHP function
>    name, but you probably get the idea.

namespace is not a problem, PHP have heterogenous API
namespace :(

It's important that libfo public interface will be
homogenous

> 
>    That way, you could do any amount of work in your
> PHP program to arrive at
>    an XSL document that you want to format, and then
> just pass it to xmlroff.

The reason because I started to dev PHP ext!

> 
>    The downside is that such a function would work
> for PHP, but not for any
>    other scripting language, since each host
> scripting language would require
>    its own unique adapter function.

Perl and Python have a wrapper to libxml/libxslt:

http://xmlsoft.org/contribs.html

> 
>    The idea of a unique adapter function is counter
> to the promise of a SWIG
>    interface where a bit of SWIG magic would allow
> multiple scripting
>    languages to instantly support xmlroff.
> 
> I don't want to decide without further discussion. 
> Does anyone else have any
> input?
> 
> > I have the same problem with the output result:
> > where can I get a pointer to result doc
> > (FoDocGP->job)?
> 
> Yes, I guess so.
> 
> > is the output file written when fo_doc_gp_finalize
> is
> > invoked?
> 
> Yes, which really happens when you run:
> 
>    'g_object_unref (fo_doc);'
> 
> I am open for suggestions on how to change that.

my idea is to separate creation and file writing and
have to call explicitly function to generate and other
 one to get result or to write file.

not see all the source of libgnomeprint, but ther is:

GnomePrintJob->meta->buf

guchar *buf;

maybe the buffer used for the output result.

> 
> I don't want to expose the GnomePrintJob underneath
> FoDoc any more than I
> wanted to expose the xmlDocPtr under FoXmlDoc, but
> it's obvious that the
> current setup is not useful for your purposes.

good strategy to not expose implementation expecially
for libgnomeprint. so you can change print engine
without force to recompile apllication that rely on
libfo.

> 
> > actually ext has OO interface, but no error
> bubbling.
> > tested only with PHP 4.4.2.
> > configuration file incomplete.
> >
> > where can I release it? not possible to release it
> at
> > pecl.php.net due to licence incompatibility.
> 
> You could contribute it to xmlroff.

yes :)

this weekend I've tried to make a deb package but i've
to rebuild xmlroff using debian source package and not
tar.gz to resolve dependance. also require to make a
deb package for pangoxsl if is not included in
xmlroff.

> 
> Regards,
> 
> 
> Tony.
> 

ciao

Mauro casciari


	

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