[
https://issues.apache.org/jira/browse/FOP-2495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14615173#comment-14615173
]
MH edited comment on FOP-2495 at 7/6/15 4:09 PM:
-------------------------------------------------
For the last font Problem I also found a very ugly workaround: I had to read
the configuration , get the value of font-base and set it during the
FopFactoryBuilder construction:
----------------------------------
/**
* Set up new FOP factory with a configuartion file.
*
* @param defaultBaseURI Base URI to read user config file (e.g.
"\\PC1\instDir\reports\xml\fonts").
* @param userConfigFile (e.g. "userconfig.xml")
* @param resolver Custom resolver.
* @param uri URI of current working path..
* @throws Exception on error.
*/
public final void setUserConfigFile(final File defaultBaseURI, final File
userConfigFile, final ResourceResolver resolver, final URI uri) throws
Exception {
if (userConfigFile != null) {
DefaultConfigurationBuilder cfgBuilder = new
DefaultConfigurationBuilder();
Configuration cfg = cfgBuilder.buildFromFile(userConfigFile);
//read font-base from configuration file:
URI fontBase = defaultBaseURI.toURI(); //default (e.g.
"file:////PC1/instDir/reports/xml/fonts/") - network shares doesn't work!
Configuration[] cfgs = cfg.getChildren();
for (final Configuration c : cfgs) { //e.g. "base", "font-base",
"source-resolution", "target-resolution", "default-page-settings", "renderers"
if ("font-base".equals(c.getName())) {
String v = c.getValue(); //has to be a URI!
fontBase = URI.create(v); //e.g.
"file:///K:/reports/xml/fonts/"
break;
}
}
if (resolver != null) {
builder = new FopFactoryBuilder(fontBase, resolver);
} else {
builder = new FopFactoryBuilder(fontBase);
}
builder.setConfiguration(cfg);
builder.setBaseURI(uri); //since FOP 2.0
//builder.setStrictFOValidation(false);
fopFactory = builder.build();
} else {
fopFactory = FopFactory.newInstance(new File(".").toURI());
}
foUserAgent = fopFactory.newFOUserAgent();
}//setUserConfigFile()
-----------------------------------
This is so ugly, I wonder how FOP 2.0 has so many things made worse! But it's
still not like FOP 1.0 - now we get lots of errors and warnings for some fonts,
e.g.
--------------
...
lte50058.AFM: named character 'quoteright' has an incorrect code point: 146.
Changed to 39
...
java.lang.RuntimeException: SVG graphic could not be built. Reason:
java.lang.RuntimeException: SVG error: The font PMN_Caecilia_45_Light.ttf is
not embeddable due to a licensing restriction.
...
-------------
that we didn't get with FOP 1.0 (for the very same font files, of course). I
also had to give up our windows networkshare names because FOP does vreak them
up: even thoug
URI fontBase = defaultBaseURI.toURI();
creates the correct and valid URI "file:////PC1/instDir/reports", we get errors:
----
java.io.FileNotFoundException: \PC1\instDir\reports\xml\fonts\LTe50327.ttf
(Das System kann den angegebenen Pfad nicht finden)
at java.io.FileInputStream.open0(Native Method)
at java.io.FileInputStream.open(FileInputStream.java:195)
at java.io.FileInputStream.<init>(FileInputStream.java:138)
at java.io.FileInputStream.<init>(FileInputStream.java:93)
at
sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:90)
at
sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:188)
at java.net.URL.openStream(URL.java:1038)
at
org.apache.fop.apps.io.ResourceResolverFactory$NormalResourceResolver.getResource(ResourceResolverFactory.java:224)
---------
If we use Windows paths with local letters like "K:/instDir/reports",
everything works. But this makes path configuration worse, as a Windows Share
directory can't be used anymore! As a workaround I have to copy the fonts
directory to each app server to be correctly read with windows letters. Is this
an open bug or is this another "not supported anymore" "feature" of FOP 2.0?
was (Author: mhilpert):
For the last font Problem I also found a very ugly workaround: I had to read
the configuration , get the value of font-base and set it during the
FopFactoryBuilder construction:
----------------------------------
/**
* Set up new FOP factory with a configuartion file.
*
* @param defaultBaseURI Base URI to read user config file (e.g.
"\\PC1\instDir\reports\xml\fonts").
* @param userConfigFile (e.g. "userconfig.xml")
* @param resolver Custom resolver.
* @param uri URI of current working path..
* @throws Exception on error.
*/
public final void setUserConfigFile(final File defaultBaseURI, final File
userConfigFile, final ResourceResolver resolver, final URI uri) throws
Exception {
if (userConfigFile != null) {
DefaultConfigurationBuilder cfgBuilder = new
DefaultConfigurationBuilder();
Configuration cfg = cfgBuilder.buildFromFile(userConfigFile);
//read font-base from configuration file:
URI fontBase = defaultBaseURI.toURI(); //default (e.g.
"file:////PC1/instDir/reports/xml/fonts/") - network shares doesn't work!
Configuration[] cfgs = cfg.getChildren();
for (final Configuration c : cfgs) { //e.g. "base", "font-base",
"source-resolution", "target-resolution", "default-page-settings", "renderers"
if ("font-base".equals(c.getName())) {
String v = c.getValue(); //has to be a URI!
fontBase = URI.create(v); //e.g.
"file:///K:/reports/xml/fonts/"
break;
}
}
if (resolver != null) {
builder = new FopFactoryBuilder(fontBase, resolver);
} else {
builder = new FopFactoryBuilder(fontBase);
}
builder.setConfiguration(cfg);
builder.setBaseURI(uri); //since FOP 2.0
//builder.setStrictFOValidation(false);
fopFactory = builder.build();
} else {
fopFactory = FopFactory.newInstance(new File(".").toURI());
}
foUserAgent = fopFactory.newFOUserAgent();
}//setUserConfigFile()
-----------------------------------
This is so ugly, I wonder how FOP 2.0 has so many things made worse! But it's
still not like FOP 1.0 - now we get lots of errors and warnings for some fonts,
e.g.
--------------
...
lte50058.AFM: named character 'quoteright' has an incorrect code point: 146.
Changed to 39
...
java.lang.RuntimeException: SVG graphic could not be built. Reason:
java.lang.RuntimeException: SVG error: The font PMN_Caecilia_45_Light.ttf is
not embeddable due to a licensing restriction.
...
-------------
that we didn't get with FOP 1.0 (for the very same font files, of course).
> Embedding: missing migration documentation from FOP 1.x
> -------------------------------------------------------
>
> Key: FOP-2495
> URL: https://issues.apache.org/jira/browse/FOP-2495
> Project: FOP
> Issue Type: Bug
> Components: documentation
> Affects Versions: 2.0
> Environment: WIndows, Java 8, FOP 1.0
> Reporter: MH
> Priority: Blocker
> Labels: documentation
>
> Because of bug FOP-2177 we couldn't upgrade form FOP 1.0 to FOP 1.1. FOP 2.0
> has solved this bug (tested with standalone FOP scripts).
> Now we would like to upgrade our Java code from FOP 1.0 to FOP 2.0. The
> Upgrading page (https://xmlgraphics.apache.org/fop/2.0/upgrading.html) says
> "You should encounter very few issues in upgrading from FOP 1.0, except as
> noted in the following: ...". The truth is completely different: starting by
> replacing fop.jar, our code gets dozens of compiler errors! Many methods are
> simply gone:
> FopFactory.newInstance()
> FoUserAgent.setBaseURL(String);
> FopFactory.getFontManager().setFontBaseURL(String)
> FopFactory.setURIResolver(URIResolver);
> etc.
> The javadocs from 1.1 to 2.0 simple changed - no deprecated methods, no hints
> how to replace old methods.
> The FOP 2.0 embedding page
> (https://xmlgraphics.apache.org/fop/2.0/embedding.html) just shows simple
> examples to start from the ground. I can't find any migration help how to
> replace old code.
> E.g. how can I set the font base?
> FopFactory.getFontManager().setFontBaseURL(String) is gone and I can't find
> any equivalent code for FOP 2.0!
> This is a major bug in FOP 2.0 as API changes are not documented to upgrade
> from FOP 1.x Java API to FOP 2.0!
> Now I just can search and try and experiment if I get our old code somehow
> running with all those undocumented API changes. Can you please state a
> migration documentation for all methods (method signatures) that don't exist
> anymore? We can't start coding all over again from scratch. Thank you very
> much!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
