Page 1 of 1

Deactivate online validation schemas

Posted: Thu Feb 13, 2020 6:16 pm
by Frank Ralf
Hi,

When using Oxygen 21.1 for the first time I got asked whether Oxygen can fetch validation schemas from remote URLs. I have agreed to trust all sources but now want to change this because I'm using Oxygen in a restricted environment with no internet access. How can I do this?

Best regards,
Frank

Re: Deactivate online validation schemas

Posted: Fri Feb 14, 2020 12:53 am
by Radu
Hi Frank,

You can look in the Preferences->"Network Connection Settings / Trusted Hosts" page and remove from there the trusted hosts.

Regards,
Radu

Re: Deactivate online validation schemas

Posted: Mon Feb 17, 2020 6:47 pm
by Frank Ralf
Hi Radu,

Many thanks for the pointer!

Best regards,
Frank

Prevent FOP from validating SVG files

Posted: Fri Mar 20, 2020 7:22 pm
by Frank Ralf
Hi Radu,

I found out that the culprit isn't Oxygen but the FOP processor that tries to validate each SVG file against an online DTD.

Code: Select all

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
    "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd" [
I've found a post from Ixiasoft with a suggested solution. However, I haven't found out yet which XML catalog file to modify in our custom Oxygen framework or PDF plugin. Actually, I'm not even sure whether Apache FOP uses any of the XML catalog files from either Oxygen or the DITA-OT to resolve the SVG URN.

I suppose this is related to the following known issue:
external-graphic_src_uri.xml (Test case with HTTP URL):
Doesn't work behind a proxy which requires authorization.
Any pointer welcome.

Best regards,
Frank

Re: Deactivate online validation schemas

Posted: Sat Mar 21, 2020 9:23 am
by Radu
Hi Frank,

So you are using Apache FOP inside a DITA OT plugin to produce the PDF, right?
The <fop> task is defined in this build file:
DITA-OT/plugins/org.dita.pdf2.fop/build_fop.xml

Code: Select all

<fop format="${fop.formatter.output-format}" fofile="${pdf2.temp.dir}/topic.fo" basedir="${pdf2.temp.dir}"
         outfile="${outputFile}" messagelevel="info" relativebase="true" force="true"
         userconfig="${args.fo.userconfig}"/>
Looking at the parameter you can send to the FOP task:

https://xmlgraphics.apache.org/fop/2.4/anttask.html

there seems to be no parameter for XML catalog.

There are two things you could do:

1) Avoid having SVG documents with a DOCTYPE declaration inside them.
2) Replace in the build file the "<fop>" ANT task with a call to the FOP command line which does have an xml catalog parameter:
https://xmlgraphics.apache.org/fop/2.4/running.html

Regards,
Radu

Re: Deactivate online validation schemas

Posted: Fri Mar 27, 2020 1:44 pm
by Frank Ralf
Hi Radu,

Many thanks for your answer! That definitely spared me a wild goose chase ;-)

Best regards,
Frank

Re: Deactivate online validation schemas

Posted: Sun Mar 29, 2020 5:14 pm
by chrispitude
Hi Radu,

Is this SVG schema-checking issue resolved in PDF Chemistry?

I've removed DOCTYPE from our existing SVG files, but writers will create new ones over time.

Re: Deactivate online validation schemas: Batik Pretty Printer

Posted: Tue Mar 31, 2020 12:01 pm
by Frank Ralf
Hi,

I've seen that Apache Batik, the library for processing SVGs, comes with a Pretty Printer tool that could probably be used to modify or remove the doctype declaration of SVGs:
-doctype change | remove : Specifies whether the doctype should be changed or removed,
-publid-id string : Specifies the public ID to in the doctype declaration, when -doctype change is specified, and
-system-id string : Specifies the system ID to in the doctype declaration, when -doctype change is specified.
Best regards,
Frank

Re: Deactivate online validation schemas

Posted: Tue Mar 31, 2020 1:09 pm
by julien_lacour
Hello,

The problem is normally fixed in Oxygen 22.0, you can try on your side and see if the problem still occurs.

Regards,
Julien

Re: Deactivate online validation schemas

Posted: Tue Mar 31, 2020 1:10 pm
by Radu
Hi,

Julien's remark above is for the PDF publishing using CSS. The problem with the XSL-FO based publishing still remains.

Regards,
Radu