RendererFactory - hardcoded list of RendererMakers
Hi I was thinking about packaging a smaller subset of FOP with only those renderers inside that are necessary (in the end I decided against it for the moment since the size benefit didn't seem to warrant it). I noticed though that the type RendererFactory has a hardcoded list of RendererMakers in one of its initializers registerStandardRenderers() Since FOP apparently uses sun's Service API anyways I'd suggest to use it here as well. Just a thought, there might be something I'm missing. Applied patch adds the dynamic lookup in the factory and the necessary service definition file residing in META-INF. Regards Nils RendererFactoryUsingService.patch Description: 2874949806-RendererFactoryUsingService.patch
Re: custom properties on xsl:fo element possible?
Hi Andreas, Your point is definitely valid, and I think I'm going to apply this change. If no other devs object to this, that is... (Later we may add an 'else' to that 'if', to deal with possible extension properties.) sounds good to me - other devs is that o.k. to put in? Thanks Nils Die wohlfeilste Art des Stolzes hingegen ist der Nationalstolz. Denn er verrät in dem damit Behafteten den Mangel an individuellen Eigenschaften, auf die er stolz sein könnte ... Aber jeder erbärmliche Tropf ... ergreift das letzte Mittel, auf die Nation, der er gerade angehört, stolz zu sein ... Arthur Schopenhauer
Re: custom properties on xsl:fo element possible?
hi, me again I looked into this some more and it seems to me that if PropertyList would check attribute namespaces before trying to convert them this would be handled nicely (i figured out that fobj has a reference to the responsible element so accessing its namespace is easy). I might be going out on a limb - maybe logging unknown attributes is the right thing to do(?) But why would FOP even consider attributes out of a non-fo namespace? well, here's a patch that does the namespace check just FYI. Looking forward to hear what you guys think. Regards! Nils attribute-namespace-check.patch Description: 2848370949-attribute-namespace-check.patch
Re: System.err System.out
Hi Jeremias You sound as if using a System.out/err is a sacrilege. sorry, you're right - I should have checked the code whether the System.err/out make sense where left. Let me get back to you on that Thanks Nils
build.xml and if=junit.present
Hi could someone put this tiny patch in that makes target junit-layout-standard check if=junit.present? Otherwise build 'all' fails if no junit is present. Thanks Nils build_xml_patch.patch Description: 1591452348-build_xml_patch.patch
Re: problem with identity comparison in types inheriting from org.apache.fop.fo.FONode
Hi thanks for the quick response from everyone. Sounds reasonable to me--I think I should have done the validation that way to begin with (IIRC =='s are Not Good with Strings anyway yes, I think so as well. Since String.equals() does the == check first anyways there shouldn't be a performance impact. Using intern() by FO internally might or might not be beneficial as mentioned. Upfront cost vs. saving memory and comparison effort. I am personally pleased that FOP 1.0 is now activatible by directly instantiating FOTreeBuilder, i.e. one can avoid the apps package completely. This is because FOTreeBuilder now has all its needed business logic within it. That was exactly my thinking - I'm planning to embed FOP as well as xsl-docbook. Going through apps.FOP forces me to package stuff that I don't really need since it seems to be designed around running it from the command-line (forcing dependencies to CommandLineOptions and the avalon stuff). So embedding something like the FOTreeBuilder that operates on the xsl level is more intuitive. but FOTreeBuilder is within FOP's black box and may not be available/could be renamed agreed but for an embedded solution that's a risk I'm willing to take :) It would be nice if the layer below apps.Fop was a public supported API actually. Thanks for considering that change Regards Nils
