From: Ariel Constenla-Haile on
Hello Zak,

On Monday 28 December 2009, 09:33, Zak McKracken wrote:
> > Re-read the Java code.
>
> Hmm... Java is one of the languages I don't really know, but after
> re-reading it the (n+1)th time, I think I understand the error I made.
> what the export function expects is this:
> filename,
> array(PV("FilterName",filtername),PV("aFilterData",array(PV(option1,value),
> PV(option2,value)...) )
> while I tried to do this:
> filename,
> array(PV("FilterName",filtername),PV("FilterData",array(PV(option1,value),P
> V(option2,value)... )))
> the above probably isn't formally correct (sorry, I never learned this
> stuff properly), but I hope it's understandable.

I think simple OOo Basic would be simpler to understand:
http://arielch.fedorapeople.org/docs/PDF_export_FilterData_demo.odt

> > Try the Python code attached (needs to start OOo in listening mode,
> > instructions at the top of the file).

looking at the Python code more closely (it's part of some experiments, as I'm
working on updating the PDF export tutorial for OOo 3.2 release, that will
support the PDF export dialog in OOo Basic), the code has an issue and setting
the FilterData does not work (the PyUNO bridge is converting the
css.beans.PropertyValue tuple into a css::uno::Sequence<css::uno::Any> so the
filter code fails to convert this to a
css::uno::Sequence<css::beans::PropertyValue>
vid.
http://svn.services.openoffice.org/opengrok/xref/DEV300_m68/filter/source/pdf/pdffilter.cxx#71
)


> Do I understand the code right? You can either call
> xPDFConfig.setPropertyValues() and later xPDFConfig.commitChanges() or
> specify the export options in the actual exporter call after putting them
> in aMediaDescriptor. If I use xPDFConfig, I won't have to set those
> options everytime I call the pdf export.

You're right: you can set the export filter options
a) changing the filter configuration. This will be applied for every exported
document later on (if there is no FilterData information, the filter
configuration is then the default)
b) setting the export options per document in the FilterData. This applies
only to the current document you're exporting

> From a user's point of view: As a not-experienced-yet-enthusiastic python
> user I feel that the way of specifying the export options is a bit
> roundabout. There is quite probably a good reason for that (which I may or
> may not be able to understand), but I'd like to see something that just
> goes "OO.currentDoc.export(filename, filtername, [properties : values])".
> That would remove the need for arrays within arrays of things I need to go
> and call a separate routine for.
> Meaning: The UNO API sure is powerful, but it just as sure is confusing to
> the uninitiated.

The Python bridge seems to have some issues, I still have to figure out how to
set the FilterData so that the bridge does not convert it to an array of Any's
That's why I prefer strong-typed languages (like C++ and Java)... but even OOo
Basic seems to work better (or at least be more intuitive) than PyUNO in this
case...

Regards
--
Ariel Constenla-Haile
La Plata, Argentina

---------------------------------------------------------------------
To unsubscribe, e-mail: discuss-unsubscribe(a)openoffice.org
For additional commands, e-mail: discuss-help(a)openoffice.org