maxwell at umiacs.umd.edu wrote: > I've attached the file in question (there are no graphics files), also our > munged fontconfig.properties file.
Problem solved. Explanations follow: * Your document was not really a DocBook one so I had to replace <!DOCTYPE book PUBLIC "-//Normal Walsh//DTD XWEB V1.0 in DocBook XML V4.2//EN" "http://docbook.sourceforge.net/release/litprog/current/dtd/ldocbook.dtd"> by an equivalent DocBook DOCTYPE to have a styled view, a "Convert Document" menu, etc. * Your document contains one ``alien'' element: <src:fragment id="CaseSlot"><InflectionalSlot> <InflectionalAffix form="<phrase lang="ben">-????????????</phrase>" gloss="-NOM"> <MorphosyntacticFeatures> <FeatureStructure> <FeatureValues> <Value name="CASE" feature="nominative"/> <Value name="NUMBER" feature="plural"/> <Value name="ANIMATE" feature="+"/> </Features> </FeatureStructure> </MorphosyntacticFeatures> </InflectionalAffix> </InflectionalSlot></src:fragment> Now I remember that Saxon always crashes when the prefix of a namespace is not declared (brutal, isn't it?). So, after adding xmlns:src="http:///www.acme.com/ns" to the <src:fragment> element, that is, <src:fragment xmlns:src="http:///www.acme.com/ns" id="CaseSlot">... I managed to convert this document to HTML (though this takes a while; I don't understand why). * I doubt that namespace prefix "src" is properly declared in ldocbook.dtd. Please, check this because the clean way to solve your problem is to declare an xmlns:src attribute with the proper fixed value for element src:fragment in ldocbook.dtd. * Shouldn't XXE warn you when you have an element for which a namespace prefix has not been declared? Sure... when XXE runs in namespace aware mode. Please keep in mind that when the document being edited is conforming to a DTD, XXE is *not* namespace aware. (Fortunately, all this will be things of the past with the advent of DocBook 5, which is RELAX NG based.) >>PS: Are you a long time user of QTJava.zip (QuickTime)? >>Or, on the contrary, is it a recent addition to your >>working environment? > > I have no clue, this is on my office PC, and I don't have the authority to > modify stuff here (including editing the classpath). And I don't yet have > the Professional Edition of XMLmind installed on my home PC, so I can't > test this there. The fact that QTJava is ahead of the standard Java in > the classpath is bothersome, because I'm now wondering how many other > problems that will cause... > QTJava.zip was not the culprit.

