You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Dave Brondsema <da...@brondsema.net> on 2004/03/02 20:47:26 UTC
Re: skinconf validation (was: Gump TLP Site)
Quoting Juan Jose Pablos <ch...@che-che.com>:
>
> > What I really don't get is if the validation schema is embedded in the XML
> > document, how updates to forrest keep making this fail. I have to assume
> > that a validation is occurring against a separate forrest file. Could I be
> > pointed to that please?
>
> you are right, we should remove that one day. :-)
>
There is also a relaxng schema in context/resources/schema/relaxng/skinconf.rnc
Currently forrest validates the skinconf.xml against this schema.
I started working on moving the DTD out of the skinconf files but had some problems:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=forrest-dev@xml.apache.org&msgId=1372385
If I can get the <xmlproperty> task to work with an <xmlcatalog>, I'm planning
on removing the relaxng validation (no advantages) and use just an external DTD.
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
http://csx.calvin.edu - student org
Re: skinconf validation
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Juan Jose Pablos <ch...@che-che.com>:
> Dave Brondsema wrote:
> >
> > If I can get the <xmlproperty> task to work with an <xmlcatalog>, I'm
> planning
> > on removing the relaxng validation (no advantages) and use just an external
> DTD.
> >
>
> hold on here. I thought that relaxng is a requierement for the use of
> xhtml as intermediate format.
>
> If we only use the jing task to validate, why do we need all DTD
> information?
>
<snip src="http://www.w3.org/TR/xhtml2/">
This version includes an early implementation of XHTML 2.0 in RELAX NG
[RELAXNG], but does not include the implementations in DTD or XML Schema form.
Those will be included in subsequent versions, once the content of this language
stabilizes.
</snip>
DTDs are needed because DOCTYPE identifiers reference DTDs (not relaxng or
schema). DTDs are also the lowest common denominator and often the only
validation supported by editors. Apparently relaxng authors don't like the idea
of a DOCTYPE identifier at all.
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=forrest-dev@xml.apache.org&msgId=1372452
However the current issue is for skinconf, not source documents. So we can use
just a DTD for the skinconf and then use relaxng for xhtml2 when we move to it.
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
http://csx.calvin.edu - student org
Re: skinconf validation
Posted by Juan Jose Pablos <ch...@che-che.com>.
Dave Brondsema wrote:
>
> If I can get the <xmlproperty> task to work with an <xmlcatalog>, I'm planning
> on removing the relaxng validation (no advantages) and use just an external DTD.
>
hold on here. I thought that relaxng is a requierement for the use of
xhtml as intermediate format.
If we only use the jing task to validate, why do we need all DTD
information?
Cheers,
Cheche
Re: Forrest and batik SVG generation problem
Posted by Juan Jose Pablos <ch...@che-che.com>.
superbonbon@bluemail.ch wrote:
>>>So here is the question : Is there any plans to migrate to the
>>>latest and greatest of batik (1.5.1) for by example forrest 0.6
>>>to fix those nasty bugs ?
>>>
>>
>>I am happy to move when Batik gets a new release.
>
>
> so batik 1.5.1 is in the pipeline for forrest 0.6 ?
The problem raises because our dependency seems to be FOP that uses batik.
I have just test batik 1.5.1 and that worked for me, so If anyone has
not got any objection, I can upgrade forrest to use batik 1.5.1
Cheers
Cheche
Re: Forrest and batik SVG generation problem
Posted by su...@bluemail.ch.
>superbonbon@bluemail.ch wrote:
>> I know that such issues are related to batik and not forrest that
>> seems to ship batik 1.5b4. The -Djava.awt.headless=true issue with batik
>> seems to have been fixed with 1.5b5 release :
>
>I am not aware of any 1.5b5 release.
Sorry that was only a CVS tag
>> So here is the question : Is there any plans to migrate to the
>> latest and greatest of batik (1.5.1) for by example forrest 0.6
>> to fix those nasty bugs ?
>>
>
>I am happy to move when Batik gets a new release.
so batik 1.5.1 is in the pipeline for forrest 0.6 ?
Regards
SuperBonBon
Re: Forrest and batik SVG generation problem
Posted by Juan Jose Pablos <ch...@che-che.com>.
superbonbon@bluemail.ch wrote:
> I know that such issues are related to batik and not forrest that
> seems to ship batik 1.5b4. The -Djava.awt.headless=true issue with batik
> seems to have been fixed with 1.5b5 release :
I am not aware of any 1.5b5 release.
> So here is the question : Is there any plans to migrate to the
> latest and greatest of batik (1.5.1) for by example forrest 0.6
> to fix those nasty bugs ?
>
I am happy to move when Batik gets a new release.
Cheers,
Cheche
Forrest and batik SVG generation problem
Posted by su...@bluemail.ch.
Hi,
I'm currently using forrest 0.5 and I have some troubles
to generate SVG to JPEG's
My SVG is including a background image :
<image xlink:href="file://..." />
No problems to generate the SVG to JPEG or PNG with sun jdk
1.4.1 this is just working fine and no complaints so far.
first issue : when I switch to sun jdk 1.4.2, the background images is not
generated anymore, the is a blank image as background
second issue : when I set the -Djava.awt.headless=true to true forrest just
crash :
[java] * [0] 1.016s 0b images/btn_About_on_svg.jpeg
[java] java.lang.ExceptionInInitializerError
[java] at org.apache.batik.ext.awt.image.spi.ImageTagRegistry.getRegist
ry(ImageTagRegistry.java:273)
[java] at org.apache.batik.bridge.SVGImageElementBridge.createRasterIma
geNode(SVGImageElementBridge.java:280)
I know that such issues are related to batik and not forrest that
seems to ship batik 1.5b4. The -Djava.awt.headless=true issue with batik
seems to have been fixed with 1.5b5 release :
http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/ext/awt/image/spi/JDKRegistryEntry.java
see comments of revision 1.6 of the file.
I presume also that the latest version of batik fix the blank image
issue with jdk 1.4.2
So here is the question : Is there any plans to migrate to the
latest and greatest of batik (1.5.1) for by example forrest 0.6
to fix those nasty bugs ?
Thanks for your great work
Regards
SuperBonBon