Hi Vincent,

feel free to improve as you see fit. I have no problem with any of your

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 [1] 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.
> > 
> > [1] 
> > 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

Reply via email to