HCMC Blogs

Spent a little time (perhaps a bit ineffectually) trying to help Stew with some PHP session problems, and looking at a Cocoon/PHP problem on the ISE site.

Eventually fixed the scrollbar problems by deleting and recreating the controls. Somehow the scrollpanes had become disconnected from the text areas, and there seemed to be no way to re-connect them.

Once that was solved, I was able to get back to working on the XML output. I found that I was able to get the text content of a node using the DOM level 3 getTextContent() method, now available in Java 1.6, which simplified getting the reading and lemma text for display. Popping up dialog boxes for choosing whether a variant was substantive or not proved fairly simple, and it was easy to add/remove/modify the value of the type attribute on the <rdg> tags based on the response.

What proved remarkably difficult was serializing the XML back out as text, to go in the textarea for saving. For the record, here's the code I ended up with:

    private String saveDomDocToString(){
        try{
            javax.xml.transform.TransformerFactory transformerFactory =
                            javax.xml.transform.TransformerFactory.newInstance();
            javax.xml.transform.Transformer transformer = transformerFactory.newTransformer();
            transformer.setOutputProperty(javax.xml.transform.OutputKeys.OMIT_XML_DECLARATION, "yes");
            java.io.StringWriter xmlout = new java.io.StringWriter(); 
            javax.xml.transform.stream.StreamResult result = new
                                javax.xml.transform.stream.StreamResult(xmlout); 
            transformer.transform(new javax.xml.transform.dom.DOMSource(doc),result);
            return xmlout.toString(); 
        }
        catch(Exception e){
            JOptionPane.showMessageDialog(this, e.toString(), "Error serializing the XML",                                            JOptionPane.ERROR_MESSAGE);
            return "";
        }
    }

I've tested this fairly thoroughly, even injecting Japanese characters into the input from Collate and seeing them successfully work through to the output, so I think this is robust from the character encoding point of view. Next I need to look at the notes Cara gave me in edited files last week, and see what other concerns remain to be addressed.

This config seems to be OK so far - much more testing to be done, though.
Specifically, I need to test telephone conversations, teacher-as-source and cassette-as-source.
===== Duo.cfg =====
[RECORD VOLUME]
LINEIN=5000
MIC=90000
CD=56071
AUX=0
WAVEOUT=0
DIGITAL=58339
ANALOG=58339

[PLAY VOLUME]
LINEIN=15000
MIC=5000
CD=26025
MAIN=21000
WAVEOUT=20000
AUX=0

[PLAY MUTE]
LINEIN=0
MIC=0
CD=0
WAVEOUT=0
AUX=0
MAIN=0

[REC MUTE]
LINEIN=0
MIC=0
CD=0
WAVEOUT=0
AUX=0

[REC SELECT]
LINEIN=0
MIC=0
CD=1
ANALOG=0
AUX=-1
DIGITAL=0

[ADVANCED]
MICBOOST=1

[CD]
DIGITAL=0

With a bunch of help I have the labs in a nearly-complete state.
Really bad monitors in Lab B have been swapped for the CASStoffs and I've cached 8 or 9 for later replacement when the remaining KDS monitors go. The remaining KDS monitors look OK right now, but as they get IDed as flaky I'll swap them.
Most keyboard/mouse combos have been replaced too, though there are a handful left which I'll do as time permits.
I've received one of the new machines, without a drive - which I expected (I have a bunch of spares) - but without a second IDE channel to plug it in to - which I did not expect. I'll need to find an extra-long IDE cable and plug both optical and HD drives in to the same channel (master-slave the two). Otherwise I'll have to buy two SATA drives. I realize that SATA is preferable in terms of performance and long-term reliability but I have all those extra drives...

The XML data files includes apostrophes. When those files were read in, those were escaped to html entities. Those entities were then rendered by the browser into literal apostrophes on the page. In the case of texts that ended up as strings in javascript variables for display on mouseover, the html entity appeared as a literal string. With Mike's help, figured out the solution to the problem, which was to add another boolean to the def_xml_transform function telling that function whether to treat the output as going to HTML or not (i.e. for javascript), and then modify the call to that function from the ajax_search.php page to pass a value of false for treatAsHtml.

in xmldb.php
function def_xml_transform($xml, $stylesheet, $params = false)
becomes
function def_xml_transform($xml, $stylesheet, $params = false, $asHTML = true)

and
return $xml_result->saveHTML();
becomes
if ($asHTML) {
return $xml_result->saveHTML();
}
else {
return $xml_result;
}

in ajax_search.php

$xml_result = def_xml_transform('<root>' . $xml_result . '', '../xslt/ajax_search.xsl');
becomes
$xml_result = def_xml_transform('<root>' . $xml_result . '', '../xslt/ajax_search.xsl',false,false);

Took off half an hour early.

Began working on the parsing of the generated TEI code, and got as far as finding and iterating through all the <app> elements and finding their <lem> children, but then got stuck on getting the node value of the <lem> element. I probably have to get its text child element and use that.

Then I hit a severe problem with the GUI, which is very puzzling. All of a sudden, text areas don't scroll, even when full of text. I've tried everything to make them do so, but nothing works. This is a bit of a show-stopper, so I'll have to deal with it before I get onto anything else.

...subject to a few queries sent to the editor. Next week I'll get to the actual article.

There is no translator tag in TEI, so marking up a biblio entry which is listed under the translator is problematic. I discovered that you can use the <editor> tag with @role="translator" to specify this, so I added a bit to the XHTML and PDF stylesheets to render this appropriately. This will carry forward to teiJournal.

In the process of marking up a long bibliography, I came up against an issue where a resp statement for a translator was not appearing in the PDF or XHTML output. This was because it was part of the <analytic> element, so it was a rare occurrence. I fixed the error in both XSLT files, and then, when testing on the site, discovered that one of the other four instances of this construction (<respStmt> inside <analytic>) was encoded slightly wrongly, so a translator's name was still not showing up. Fixed that, and documented it in the <revisionDesc>.