StimVinsh / xdocreport

Automatically exported from code.google.com/p/xdocreport
0 stars 0 forks source link

No mailing list #6

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. visit xDocReport site
2. find objectives and content just what I 'need'
3. find on email, mailinglist or contact point to follow-up.
4. examine downloads, wiki, SVN source

What is the expected output? What do you see instead?

You need some kind of point of contact. Person, blog, wiki, etc.  For example; 
in the past I've set-up a special purpose yahoo group, google group or 
wordpress page for this kind of project.  

It doesn't need to be fancy.

What version of the product are you using? On what operating system?

I like what the project describes.  For me, I'm looking at merging documents 
and accessing web services like Google translate to 'massage' documents with 
foreign language quotes.

I agree that the templating tool is a good approach.  In fact I'm now 
rethinking my design architecture around freemarker whereas before I was going 
to re-use some ruby::MS Word code I had to generate documents.

Since I gather you are using XML document format and ODT, before seeing how you 
have gone so far - I'd recommend using XSLT transforms when possible and 
thinking about chaining XSLT-s.

My reason to make contact, is that the promise of this project is very much in 
line with the things I'm doing.  Not just translation/formatting.  So I'm 
interested in contributing in vacant capacities -- Testing: unit, beta, 
integration.  Some helper work like mailing lists and coordinating /filtering 
information bugs, etc.

I know there will be a lot of interest in this schema because I've been working 
in office automation since 1982 with PDP-8 and PDP-11 systems and few (if any) 
have got that much right (to date).

Bon chance,

      Will

Please provide any additional information below.

Original issue reported on code.google.com by William....@gmail.com on 23 Mar 2011 at 2:57

GoogleCodeExporter commented 8 years ago
William,

First of all sorry not to answer realier, we were simply unaware of your 
message.
we just create a google group which will server as mailing list for this 
project.

Here : http://groups.google.com/group/xdocreport

Feel free to asks questions, post comment and talk about further functionnality 
there

If you want to contribute, you are more than welcome : we need some feedback 
and some contibutors. Just let us know what you are likely to do.

For the time being, we are focusing on converter (docx or odt -> PDF or XHTML). 
Trying to reproduce the same look and feel as the original doc is quite time 
consuming... 

In my own experience, XML unmarshalling is way faster than XSL processing (and 
obviously more type-safe). Still there are some XSL-FO converer implementation 
for document transformation. Competition is not over among differents converter 
implementations.

Bests regards

Original comment by pascal.leclercq on 30 Mar 2011 at 1:27

GoogleCodeExporter commented 8 years ago
Hi William,

Thank a lot for your interesment about XDocReport. I'm totally agree with you, 
documentation is very very light and I have start to write WIKI for converter. 
Please see at http://code.google.com/p/xdocreport/wiki/Converters

I have started too write FAQ at http://code.google.com/p/xdocreport/wiki/FAQ
(not finished, but if you have some questions don't hesitate to tell me)

Thank a lot.

Regards Angelo

Original comment by angelo.z...@gmail.com on 30 Mar 2011 at 3:54

GoogleCodeExporter commented 8 years ago
Hi William,

To answer to your recommndation : 

"Since I gather you are using XML document format and ODT, before seeing how 
you have gone so far - I'd recommend using XSLT transforms when possible and 
thinking about chaining XSLT-s"

I have implemented ODT -> PDF with 2 means : 

* ODT -> XSL-FO -> FO -> FOP
* ODT -> ODFDOM (Java) -> IText

You can see that at http://code.google.com/p/xdocreport/wiki/ODFConverters

The first converter wich use XSL is less quick than  ODFDOM (Java) because 
there is a step (FO -> PDF) wich take time. I try to improve XSL (XSL-FO 
transformation wich use my XSL has well performance) by caching XSL Template 
computing, using xsl:key..., store in variable the needed another DOM than 
content.xml (styles.xml).

XSL is very powerfull if you have complex template match. In my case, template 
match is very easy. The basic idea is to loop for nodes of content.xml and 
generate FO. So I told me (and Pascal suggested me) why don't use Model Java 
(ex : DOM Java) and loop for nodes to generate directly IText structure? I have 
tried with ODFDOMCOnverter wich load ODT in ODFDOM structure (Java) (it load 
each XML files (content.xml, styles.xml) in a DOM) and loop for the ODT DOM 
nodes to create directly IText.

So my conclusion with XSL-FO vs ODFDOM for convert ODT 2 PDF is : 

* ODFDOM-Converter(Java) is more easy to develop. I prefer develop Java code 
than XSL. I can debug my Java code (I have tried XSLT Eclipse debugger which is 
cool but Java debugger is more performant).
* ODFDOM-Converter (Java) is very more performant than my XSL-FO.

If you wish study that, don't hesitate to see my code and suggest me improvment.

Regards Angelo

Original comment by angelo.z...@gmail.com on 1 Apr 2011 at 8:41

GoogleCodeExporter commented 8 years ago

Original comment by angelo.z...@gmail.com on 14 Apr 2011 at 9:45

GoogleCodeExporter commented 8 years ago

Original comment by angelo.z...@gmail.com on 14 Apr 2011 at 9:45