Hi Adrian, Adrian Cumiskey a écrit : <snip/> >> - we may discuss about the interest of a separate/yet another parameter >> for validating the config file. I can understand both points of vue >> and, actually, I don't really care of which is chosen. That said, >> I think validation of the config file should be enabled by default (as >> strict FO validation, IIC) because this will be helpful to newbies. >> Power users will be clever enough to disable it if they want to. So >> I suggest you to change the default value to true in your patch. > > My thinking behind initially switching this option off was to not break > any existing configurations, but you are right its probably best to help > the newbies and not worry too much about initially upsetting some of the > power users. I take your point and will make this change.
Good point, in the future we might expect users complaining that their config files no longer work with FOP's latest release. Still, I think this is preferable for newcomers. Let's just get prepared, after the next release, to answering plenty of times the same question and creating a new FAQ entry about strict user config validation ;-) >> - the changes in src/documentation/content/xdocs/0.93/fonts.xml are >> a bit inexact. That's ok, you're probably still learning. But: >> - the examples you added have different noticeable behaviours: the >> first one gets the font's metrics through a beforehand generated XML >> file and won't embed the font in the PDF file, because it doesn't >> have access to the font file; the second ones computes the metrics >> on the fly and is able to embed the font in the PDF file. As those >> differences are not trivial and are explained further on the page >> I would leave the example as is. > > I will revert this change. > >> - if both files are specified the metrics-url won't take the >> precedence, at least not exactly. The metrics defined in this file >> will override the metrics in the font (if the user modified the file >> by hand after generating it), but the embed-url file will always be >> used to load and embed the font. > > I'm not sure this is the case (but maybe it should be..). All the > config fonts are loaded on demand by the LazyFont encapsulation. If you > look at org.apache.fop.fonts.LazyFont.load(), the metrics url does take > precedence over the embed url (see conditional tests on metricsFileName > and fontEmbedPath). Yes, but if you then look at PDFFactory.makeFontFile you will see that the font file is read there for embedding in the resulting PDF file. Your initial wording is essentially right, just a bit misleading: it's true that the data in the metrics file will be given the preference for any font-related computation (glyph placement, kerning, etc.), but finally that's the original font file which is put into the PDF. >> - AFAIK, kerning is available for PS and PDF outputs. >> - but as I said, thanks for updating the documentation! >> >> - I ask for other devs' opinions, but in strict user-config validation >> mode I would not also log an error when an exception is subsequently >> thrown. Reporting the problem just once is enough IMO. > > I will change this. > >> - In apps.FopFactory: >> - AFAIU the validatesStrictly() method is not related to user >> configuration, as the javadoc seems to imply > > This comment was added to the validatesStrictly method when Simon > Pepping commented that these configuration options should be separate > and I neglected to remove it. I will now remove this additional method > comment. > >> - setUserConfig doesn't throw SAXException or IOException, but >> FOPException > > I am at pains to modify public APIs so as to remain backwards compatible > and not break anything... There are three public setUserConfig methods, > two of which throws SAXException, IOException so I tried to leave these > as is - as a FopException is a subclass of SAXException anyways :). The > other method needed to be changed though to report an exception > (FopException) - instead of just logging it. Ah yes, I forgot that public API issue. Well, that's a bit problematic, then, because backward compatibility is broken anyway (a method which previously didn't throw any exception will now throw one). What's frustrating is that we know the FOPException will only be thrown in strict validation mode, but we must still declare it. So even if the user disabled strict validation, they would still have to catch the exception. Hmmmm. Personally I would declare a FOPException; if we are to break backward compatibility, we may as well be accurate. But I could understand that other devs don't agree with that. In which case there isn't really a clean solution: embed the FOPException into a RuntimeException, or log a fatal message. What do others think? Vincent
