Ah, my email client didn't thread this properly so only just saw it. Glad it's sorted!
On Sat, 29 Jan 2022 at 09:49, <xmlgraphics.d...@apconsult.de> wrote: > ok, I've found the problem. > > The svg Namespace is being corrupted. > > Someone, somewhere added xmlns="" to the <g> Element. The generated FO > was... > > <svg xmlns="http://www.w3.org/2000/svg"; <http://www.w3.org/2000/svg> > height="775" viewBox="0 0 1184 775" width="1184"> > <g xmlns="" style="fill-opacity:0;stroke-width:2;stroke:black"> > : : : > </g> > </svg> > > After explicitly adding the correct Namespace to the <g> Element... > ...someone, somewhere added xmlns="" to the <rect> Elements. The > generated FO was... > > <svg xmlns="http://www.w3.org/2000/svg"; <http://www.w3.org/2000/svg> > height="775" viewBox="0 0 1184 775" width="1184"> > <g style="fill-opacity:0;stroke-width:2;stroke:black"> > <rect xmlns="" height="99" width="254" x="2" y="2"/> > </g> > </svg> > > So I explicitly added the correct Namespace to all the <rect> Elements. > The generated FO was... > > <svg xmlns="http://www.w3.org/2000/svg"; <http://www.w3.org/2000/svg> > height="775" viewBox="0 0 1184 775" width="1184"> > <g style="fill-opacity:0;stroke-width:2;stroke:black"> > <rect height="99" width="254" x="2" y="2"/> > </g> > </svg> > > And that worked. 😎 > > My Stylesheet source now looks like this: > > <svg xmlns="http://www.w3.org/2000/svg"; > <http://www.w3.org/2000/svg> width="1184" height="775" viewBox="0 0 1184 > 775"> > <g xmlns="http://www.w3.org/2000/svg"; > <http://www.w3.org/2000/svg> > style="fill-opacity:0;stroke-width:2;stroke:black"> > <rect xmlns="http://www.w3.org/2000/svg"; > <http://www.w3.org/2000/svg> x="2" y="2" width="254" height="99"/> > </g> > </svg> > > So I guess that's a Bug in the XSLT Processor?? > > All the best, > Dave > > On 29/01/2022 08:38, xmlgraphics.d...@apconsult.de wrote: > > I have attached Server Logs for both. > > For each, the Server was restarted anew beforehand. > > To make them better comparable, I've redacted them as follows: > - Timestamps removed from beginning of lines > - blank lines inserted where differences occur > - Pretty-Printed the generated FO as XML > > There are Log-entries from our Resource-Resolver for the external-graphic, > but it simply delegates SVG's to the apache FOP DefaultResourceResolver. > > Looks to me as though both are generating an SVG? > > All the best, > Dave > > On 29/01/2022 06:16, xmlgraphics.d...@apconsult.de wrote: > > Hi Matt, > > we have a Stone Age Linux, but the rest is fairly up-to-date: > > SUSE Linux Enterprise Server 11.1 (x86_64)2.6.32.46-0.3-default > > openjdk version "17" 2021-09-14 > OpenJDK Runtime Environment (build 17+35-2724) > OpenJDK 64-Bit Server VM (build 17+35-2724, mixed mode, sharing) > > Apache FOP v2.6 > > As suggested on > https://xmlgraphics.apache.org/fop/trunk/graphics.html > I did start the server with... > -Djava.awt.headless=true > ...without really knowing what that does, but it made no difference. > > I wonder whether the headless remarks are historical in nature > & not relevant for current Batik releases? > (we are using the current Batik v1.14) > > I also went to great lengths to reproduce the exact same Classpath order > under Windows, > defining each Library individually & using a comparable JDK with Eclipse > 2021-09: > openjdk version "17.0.1" 2021-10-19 LTS > OpenJDK Runtime Environment Zulu17.30+15-CA (build 17.0.1+12-LTS) > OpenJDK 64-Bit Server VM Zulu17.30+15-CA (build 17.0.1+12-LTS, mixed > mode, sharing) > > What doesn't make sense to me is how FOP managed to render the external SVG > but inlining it, the SVG Graphic was not rendered. > (from the trace it looked like it was doing some SVG rendering) > > Surely, if it can render an external SVG, it must be able to render an > inline one?! > > All the best, > Dave > > On 28/01/2022 14:04, Matt Kynaston wrote: > > We render inline SVGs on linux (RHEL7 atm) all the time, without needing > to install anything special - although it does pull in a "headless" version > of openjdk. > > Which linux? Which java? Which version of FOP? > > Matt > > On Sun, 23 Jan 2022 at 14:01, <xmlgraphics.d...@apconsult.de> wrote: > >> Hi there, >> >> we are using Apache FOP to generate PDF's & have an issue with SVG's. >> >> To include an SVG we're using something like the following... >> >> <fo:block> >> <fo:external-graphic src="classpath:image/MyImage.svg" >> content-width="150mm"/></fo:block> >> >> The above works fine in all environments. >> >> Now I'm trying to inline an SVG in the Stylesheet, like this... >> >> <fo:block> >> <fo:instream-foreign-object content-width="272.6mm"> >> <svg xmlns="http://www.w3.org/2000/svg"; <http://www.w3.org/2000/svg> >> width="780" height="120" viewBox="0 0 780 120"> >> <g style="fill-opacity:0;stroke-width:2;stroke:black"> >> <rect x="2" y="2" width="254" height="99"/> >> <rect x="256" y="2" width="485" height="99"/> >> </g> >> </svg> >> </fo:instream-foreign-object></fo:block> >> >> That works OK under Windows, but when deployed on our Linux Server, seems >> to do nothing. >> >> I have read some comments on the Apache FOP Website about it using Apache >> Batik to render SVG's >> and that this requires a Graphical Environment, so will not work in many >> Unix configurations. >> >> What I don't understand is, how come the external SVG is working ok on >> the Unix Server & inline is not? >> >> Also, the Apache FOP Website recommends a Tool called PJA toolkit >> <https://www.eteks.com/pja/en/> to workaround this issue, >> but it looks very dated, so I wonder if its going to work with our JDK 17? >> (and indeed its developer, Emmanuel Puybaret, is quite surprised anyone >> would still be recommending use of this tool) >> >> I would be grateful if anyone has some Info about this. >> >> All the best, >> Dave >> > > > -- > > > Matt Kynaston > Lead Developer > Tel: +441225851666 > www.claritum.com > > Claritum Limited. Registered Office: 37 Great Pulteney Street, Bath, BA2 > 4DA Registered in England and Wales 3878694 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org > > > -- Matt Kynaston Lead Developer Tel: +441225851666 www.claritum.com Claritum Limited. Registered Office: 37 Great Pulteney Street, Bath, BA2 4DA Registered in England and Wales 3878694
