SVG Batik Lo spazio dei nomi dell'elemento radice non corrisponde a quello richiesto

Question

Poche settimane fa, funzionava perfettamente il mio SVG, ma in qualche modo ha smesso di funzionare e non conosco la causa perché l'errore sparato sul server non è stato utile. Succede quando ho trasferire il file in formato SVG al mio pdf:

Root element namespace does not match that requested: 
Requested: http://www.w3.org/2000/svg 
Found: null. Stacktrace follows: 
org.apache.batik.bridge.BridgeException: Root element namespace does not match that requested: 
Requested: http://www.w3.org/2000/svg 
Found: null 
    at org.apache.batik.bridge.BridgeContext.getReferencedNode(BridgeContext.java:780) 
    at org.apache.batik.bridge.BridgeContext.getReferencedElement(BridgeContext.java:796) 
    at org.apache.batik.bridge.CSSUtilities.convertClipPath(CSSUtilities.java:719) 
    at org.apache.batik.bridge.AbstractGraphicsNodeBridge.buildGraphicsNode(AbstractGraphicsNodeBridge.java:146) 
    at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(GVTBuilder.java:224) 
    at org.apache.batik.bridge.GVTBuilder.buildComposite(GVTBuilder.java:171) 
    at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(GVTBuilder.java:219) 
    at org.apache.batik.bridge.GVTBuilder.buildComposite(GVTBuilder.java:171) 
    at org.apache.batik.bridge.GVTBuilder.build(GVTBuilder.java:82) 
    at net.sf.jasperreports.renderers.BatikRenderer.ensureSvg(BatikRenderer.java:192) 
    at net.sf.jasperreports.renderers.BatikRenderer.getDimension(BatikRenderer.java:141) 
    at net.sf.jasperreports.engine.export.JRPdfExporter.exportImage(JRPdfExporter.java:1351) 
    at net.sf.jasperreports.engine.export.JRPdfExporter.exportElements(JRPdfExporter.java:774) 
    at net.sf.jasperreports.engine.export.JRPdfExporter.exportPage(JRPdfExporter.java:738) 
    at net.sf.jasperreports.engine.export.JRPdfExporter.exportReportToStream(JRPdfExporter.java:616) 
    at net.sf.jasperreports.engine.export.JRPdfExporter.exportReport(JRPdfExporter.java:364) 
    at com.scacp.operation.MonitoringWellController$_closure13.doCall(MonitoringWellController.groovy:749) 
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
    at java.lang.Thread.run(Thread.java:745) 

io non cosa vuol dire fare, il mio xml svg (sul sito web validatore XML) è un codice valido. Sto scrivendo in questo modo:

file.write('<?xml version="1.0" encoding="UTF-8"?> \n' 
+ '<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> \n' 
+ '<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" width="705px" height="1000px" viewBox="0 0 705 1000" enable-background="new 0 0 705 1000" xml:space="preserve"> \n' 
+ svgimage + '\n' 
+ '</svg>'); 

Lo svgimage variabile è un gruppo di g, defs, text, images, ecc (davvero grande, come 1k di linee)

Answer 1

ho avuto un sacco di lavoro per trovare la causa sopra + 1k di linee sul mio XML ed è un tag che SVG creato e w3 non ha riconosciuto, che è clipPath e clip-path e rimuovendole, funziona perfettamente :

<clipPath id="_ABSTRACT_RENDERER_ID_0"> //removed 
... 
</clipPath> 

<g clip-path="url(http://mypage.com/344#_ABSTRACT_RENDERER_ID_0)"> //remove the attribute clip-path 
... 
</g> 

In qualche modo, il non ha ancora riconosciuto la w3 url(...) semplicemente rimuovendo questo, funziona. Ed è strano, è sempre stato lì.

Answer 2

sto suggerendo questo, ma non comprendendo appieno il problema - il trasferimento in pdf funzionava a un certo punto e poi falliva improvvisamente.

Nella dichiarazione del tipo di documento: w3.org menziona utilizzando un DTD "piatto" nell'identificatore di sistema, che è un DTD singolo appiattito, anziché più file.

w3.org - SVG NampeSpace, Public Identifier and System Identifier :

"Notare che DTD elencato nel Sistema Identifier è un DTD modulare (cioè il suo contenuto sono disposte su più file), il che significa che un validatore può dover recuperare i moduli multipli per Per questo motivo, è disponibile un DTD singolo appiattito che corrisponde alla DTD modulare SVG 1.1, disponibile al numero http://www.w3.org/Graphics/SVG/1.1/DTD/svg11-flat.dtd. "