You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Felipe Rech Meneguzzi <fe...@cpts.pucrs.br> on 2004/06/28 16:18:13 UTC

Contributing to Batik

Hello Batik Developers,

 

            I would like to know how someone can submit contributions to batik.

The reason for my question is that we have created an implementation of an SVG to PS/EPS transcoder for Batik in our research lab and, if any one is interested in having it we would gladly give it to the community.

We implemented it mainly because we have not found any free SVG to EPS converter which did not transform text construct into complex path outlines in the resulting EPS, and thus creating unnecessarily large files.

 

If any one in the community is interested in it please send me an e-mail.

 

Regards,

 

_____________________________________________

M.Sc. Felipe Rech Meneguzzi

HYPERLINK "mailto:felipe@cpts.pucrs.br"felipe@cpts.pucrs.br

Project Administrator / Researcher

Centro de Pesquisa em Software Embarcado (CPSE)

_____________________________________________

 


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.710 / Virus Database: 466 - Release Date: 23/6/2004
 

Re: RES: Contributing to Batik

Posted by Jeremias Maerki <de...@greenmail.ch>.
Hello Felipe

On 28.06.2004 19:39:52 Felipe Rech Meneguzzi wrote:
> Hello Jeremias,
> 
> Well, it seems we looked in the wrong places for a solution :-),
> because some of the PS generation code we use was borrowed from FOP release
> 0.20.5. Now that you pointed out the correct place to look for the PS
> transcoder API in the redesign branch of FOP I see we really had a lot
> of unnecessary trouble to "reinvent" the wheel. Well, at least it was a
> good exercise, in particular with respect to modification in the Text
> Painter classes.

Yeah, that's a challenging piece. I've reworked a lot of that code over
time and I'm still not happy with it although it gradually gets better.
It would be nice to get help there.

> With regards to what our implementation can do, our main "test cases"
> were UML diagrams generated by Omondo UML (UML modeling tool for
> Eclipse), the reason for our implementation in the first place, which our
> implementation currently converts very neatly, using PS text primitives
> instead of using curves, and showing the correct bounding box even when
> the source SVG does not specify a media or clipping box size.
> 
> We have downloaded the classes you pointed out and we are currently
> trying our examples to see if there is anything in our implementation
> that could be useful as an addition to yours, if we find anything that
> can be of use we will post it here.

I'm looking forward to it.

Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org


RES: Contributing to Batik

Posted by Felipe Rech Meneguzzi <fe...@cpts.pucrs.br>.
Hello Jeremias,

	Well, it seems we looked in the wrong places for a solution :-), because some of the PS generation code we use was borrowed from FOP release 0.20.5. Now that you pointed out the correct place to look for the PS transcoder API in the redesign branch of FOP I see we really had a lot of unnecessary trouble to "reinvent" the wheel. Well, at least it was a good exercise, in particular with respect to modification in the Text Painter classes.

	With regards to what our implementation can do, our main "test cases" were UML diagrams generated by Omondo UML (UML modeling tool for Eclipse), the reason for our implementation in the first place, which our implementation currently converts very neatly, using PS text primitives instead of using curves, and showing the correct bounding box even when the source SVG does not specify a media or clipping box size.

	We have downloaded the classes you pointed out and we are currently trying our examples to see if there is anything in our implementation that could be useful as an addition to yours, if we find anything that can be of use we will post it here.

Regards,

_____________________
Felipe Rech Meneguzzi
felipe@cpts.pucrs.br
_____________________

-----Mensagem original-----
De: Jeremias Maerki [mailto:dev.jeremias@greenmail.ch] 
Enviada em: segunda-feira, 28 de junho de 2004 11:34
Para: batik-dev@xml.apache.org
Assunto: Re: Contributing to Batik

Hello Felipe,

it's unfortunate that you've gone through the pains of creating such a
transcoder. We already have one although it's not in Batik's codebase
but in FOP's. We needed SVG support for our PostScript renderer so we
implemented it there. By the way, it's already available in the latest
Batik release although it may be a bit hidden. Once we have the XML
Graphics project ramped up I plan to push the PDF and PostScript
transcoders to their own space that is shared between FOP and Batik
which will make maintenance easier and provide the two transcoders with
more visibility.

So, how advanced is your implementation? Ours is not quite finished but
quite usable. Maybe we could join forces.

Here's FOP's PS/EPS transcoder:
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/render/ps/

On 28.06.2004 16:18:13 Felipe Rech Meneguzzi wrote:
> Hello Batik Developers,
> 
>  
> 
> I would like to know how someone can submit contributions to batik.
> 
> The reason for my question is that we have created an implementation of
> an SVG to PS/EPS transcoder for Batik in our research lab and, if any
> one is interested in having it we would gladly give it to the community.
> 
> We implemented it mainly because we have not found any free SVG to EPS
> converter which did not transform text construct into complex path
> outlines in the resulting EPS, and thus creating unnecessarily large
> files.
> 
>  
> 
> If any one in the community is interested in it please send me an e-mail.


-- 
Jeremias Maerki <de...@greenmail.ch>
FOP committer


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org


---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.710 / Virus Database: 466 - Release Date: 23/6/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.710 / Virus Database: 466 - Release Date: 23/6/2004
 


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org


Re: Contributing to Batik

Posted by Jeremias Maerki <de...@greenmail.ch>.
Hello Felipe,

it's unfortunate that you've gone through the pains of creating such a
transcoder. We already have one although it's not in Batik's codebase
but in FOP's. We needed SVG support for our PostScript renderer so we
implemented it there. By the way, it's already available in the latest
Batik release although it may be a bit hidden. Once we have the XML
Graphics project ramped up I plan to push the PDF and PostScript
transcoders to their own space that is shared between FOP and Batik
which will make maintenance easier and provide the two transcoders with
more visibility.

So, how advanced is your implementation? Ours is not quite finished but
quite usable. Maybe we could join forces.

Here's FOP's PS/EPS transcoder:
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/render/ps/

On 28.06.2004 16:18:13 Felipe Rech Meneguzzi wrote:
> Hello Batik Developers,
> 
>  
> 
> I would like to know how someone can submit contributions to batik.
> 
> The reason for my question is that we have created an implementation of
> an SVG to PS/EPS transcoder for Batik in our research lab and, if any
> one is interested in having it we would gladly give it to the community.
> 
> We implemented it mainly because we have not found any free SVG to EPS
> converter which did not transform text construct into complex path
> outlines in the resulting EPS, and thus creating unnecessarily large
> files.
> 
>  
> 
> If any one in the community is interested in it please send me an e-mail.


-- 
Jeremias Maerki <de...@greenmail.ch>
FOP committer


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org