cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Starks <>
Subject Re: Not able to create and test cocoon2.2 webapp with maven/jetty
Date Thu, 21 Aug 2008 09:41:08 GMT
sorry, I forgot: perhaps it would be better to start a new thread about 
We are straying off topic a bit far!

Ken Starks wrote:

> Derek Hohls wrote:
>> Ken
>> I am very curious how you plan to get PDF output using
>> LaTeX and Cocoon - I have seen Hugh's page where he
>> generates GIF images from LaTeX equations
>> ( )
>> but this seems an order-of-magnitude more complex.
>> Derek
>>>>> On 2008/08/21 at 09:37, in message <>,
Ken Starks <> wrote:
>> Luca Morandini wrote:
>>> jantje wrote:
>>>> So on the internet I am searching ways to generate
>>>> cocoon webapp from my blocks. There I have found the install 
>>>> instruction and
>>>> the advice to use it.. So do you think there is a better way to 
>>>> generate a
>>>> webapp. And do you advice me not to install my seperate blocks?
>>> I'm not sure to get what you mean... but the idea is to create a 
>>> Cocoon webapp by using the cocoon-archetype-webapp and then declare 
>>> the needed blocks in its pom.xml, not to generate webapps from blocks.
>>> You may look at an example of said steps in:
>>> Regards,
>>> --------------------
>>>    Luca Morandini
>> Hello Luca,
>> My main interest is in making a wider variety of diagram than
>> those used in 'business graphics'. This is because there is quite a number
>> of utilities already in that corner of the market. But your
>> project is still of interest to me.
>> I was wondering whether you have an xml-schema, or a good bunch of
>> samples of the source XML files you use in Fins.
>> My interest would be to go to a PDF  edition of the charts without passing
>> through SVG, and using LaTeX and friends rather than FOP.
> TeXML. Its quite a thin wrapper round LaTeX.
> First you write a specimen LaTeX file of the kind you wish to have.
> Secondly you  rewrite it so the absolute maximum functionality is in 
> the header as
> \newcommand{....}[]{....},
> and the main body consists mainly of calls to these commands.
> You are then ready to write your  XSL-T file, (xml2texml.xsl) which is 
> what you put
> into cocoon.  It is easier, and also a better 'separation of concerns' 
> to make this file
> import your preamble than to generate it in situ.
> Let us say your source is Foo.xml;  you create a match for *.texml in 
> the usual way.
> As we are in cocoon at this stage, you can of course use any 
> generator. It doesn't
> have to be an xml file.
> You don't need to worry about the serializer really. The texml output 
> that you need
> from Cocoon is an xml format.
> A python script then downloads Foo.texml, turns it into Foo.tex. This 
> is a task that is to complex,
> as far as I know, for XSLT, but if someone wants to rewrite it in 
> java  and stick it in a
> cocoon block, I certainly won't stop them!
> When you run this tex file, it will import the preamble bit as usual, 
> so long as it is  in
> the right place, client-side.
> Now I would be the first to admit that TeXML is not easy to work 
> with.  You need
> all the usual lateX skills, plus tolleration for some pretty peculiar 
> syntax.
> But you  _do_  get a fully automatic path from xml to pdf  in the end, 
> and unlike
> most other systems you have the possibility of generating PDF-forms, 
> injecting
> javascript and so on, assuming you can already do that in LaTeX.

View raw message