Hi Vincent, feel free to improve as you see fit. I have no problem with any of your suggestions.
On 27.10.2009 11:40:21 Vincent Hennebert wrote: > Hi, > > Jeremias Maerki wrote: > > On 22.10.2009 19:36:14 Vincent Hennebert wrote: > >> Hi, > >> > >>> Log: > >>> Issue an error when attempting to render an intermediate XML file in > >>> accessibility mode, but that file wasn't generated with accessibility > >>> (i.e., does not contain the structure tree) > >>> > >>> Added: > >>> > >>> xmlgraphics/fop/branches/Temp_Accessibility/src/java/org/apache/fop/accessibility/AccessibilityEventProducer.java > >>> (with props) > >>> > >>> xmlgraphics/fop/branches/Temp_Accessibility/src/java/org/apache/fop/accessibility/AccessibilityEventProducer.xml > >>> (with props) > >> After creating the AccessibilityEventProducer.xml file and running ‘ant > >> resourcegen’ I discovered that an empty message had been added to > >> src/java/org/apache/fop/events/EventFormatter.xml. Why? > > > > Because the new files wasn't reflected in the build. All events not > > specifically directed into a special file go into the catch-all file in > > the events package. I've updated the build accordingly: > > http://svn.apache.org/viewvc?rev=828805&view=rev > > I have trouble seeing the necessity of adding something to the build > file I must say. (That build file, BTW, is already 1441 lines long. We > should think twice before adding anything to it IMO.) > > All eventResourceGenerator tasks are exactly the same. Couldn’t we set > the convention that the translation file corresponding to a certain > EventProducer interface must have the same name and be in the same > directory as the interface itself? > > Example: a PDFEventProducer.java file is found in the > org/apache/fop/render/pdf directory; a PDFEventProducer.xml file > containing the translation is expected in that same directory. > > Using a catch-all file kills the modularity of the thing IMO. Also, the > individual translation files are called *EventProducer.xml but the > catch-all file is called EventFormatter.xml!? > > > >> Also, after re-building FOP I regularly find myself with modified > >> *EventProducer.xml files, where the sole modification is an > >> added/removed line break. This is annoying. How can that be avoided? > > > > These are small differences in behaviour of XML serializers. I guess if > > that is so annoying, we'd have to make sure we always use the same > > serializer (make & version) somehow. We could also experiment with > > removing the XML declaration  at the beginning of the file. That > > might get rid of the problem but that's not for sure. I've stumbled over > > this myself a number of times but found it to be only a minor nuisance > > which is why I didn't do anything about it. > > > >  > > http://java.sun.com/j2se/1.4.2/docs/api/javax/xml/transform/OutputKeys.html#OMIT_XML_DECLARATION > > I can see the interest of filling the translation file with empty > messages having correct keys (those are not exactly trivial —although > necessary, I guess). However, there is IMO a non-negligible danger that > the user then forgets to fill in those messages appropriately. > > Also, I’m not sure I like having a file that is both manually edited and > automatically generated. That usually doesn’t go well together, as the > automatic generation usually messes up any manual formatting. The above > is an illustration. > > If there were the convention that the translation file must be put in > the same package as the EventProducer interface, the key wouldn’t need > to be fully qualified, only the method name would be necessary. Then > I think it’s reasonable to expect the user to fill in the translation > file accordingly, and just check at build time that both the interface > and the translation file are consistent. > > Is there anything wrong with that? > > Vincent Jeremias Maerki