dm-l

dm-l@uleth.ca

2794 discussions

RE: [dm-l] what xslt can't do..?
by Binkley, Peter 08 Apr '05

08 Apr '05

I confess I haven't tried Anastasia yet, through lack of time and not of interest. Glancing at the documentation, I see that Anastasia appears to do lookups in a book file, which has (previously?) been compiled from the TEI. ("This must be an Anastasia book compiled from the XML using the Anastasia GroveMaker tool. This is designed to permit fast, real-time access to any part of the underlying XML.") Anastasia's speed is attributed to the fact that it is "interrogating not the source XML but a set of binary files (an "AnaGrove") which are optimized to permit the fastest access to information about every aspect of the source XML." GroveMaker is written in C. It would appear, then, that Anastasia would have the same syncronization requirements as the kind of pre-transformed XSL-based solution that James is talking about: if you change the TEI, you've got to remember to recompile the AnaGrove. If I've understood this correctly, then it seems to me that the correct object of comparison for Anastasia's ability to present an arbitrary page would not be a single-pass XSL against a large TEI file, but rather, say, a Cocoon pipeline using XSL to present arbitrary XML page files which have been pre-extracted from the TEI file and optimized for presentation by an XSL process along the lines of the one I hacked. The TCL scripts that Peter R. sent would be the equivalent of the matcher and generator in the Cocoon pipeline: <map:match pattern="*/*.html"> <map:generate src="path-to-texts/{1}/{2}.xml"/> ... </map:match> (where a url like "hengwrt/23.html" would be mapped to an extracted page file "path-to-texts/hengwrt/23.xml"). The output of this generator, as of the TCL scripts, is the marked-up text of a given page, ready to be styled and presented to the reader. Anastasia may well still win on speed, of course, if not in the presentation then in the preprocessing. An XSL-based extraction process will have a hard time keeping up with a custom-written C indexer. But it will be a lot easier to maintain, I submit (with apologies if I've misunderstood what Anastasia is doing). Has anyone looked at teiPublisher yet, by the way? (http://teipublisher.sourceforge.net/docs/index.php) Judging from the texts in the "Documenting the American South" project, they seem to have sidestepped the whole problem of presenting arbitrary pages, by only offering the complete text in a single HTML file. I haven't looked into it to see if there are other options, though. Final note regarding the sample text: again, I don't understand what the problem is with the last page, even with the appendix. How can any process know that that last div is an appendix and not a new section of the main text, beginning and ending on page 5? Whatever marker GroveMaker uses to make this distinction would also be available to XSL, presumably. (Perhaps my ignorance of TEI is showing...) Peter Binkley > -----Original Message----- > From: dm-l-bounces(a)uleth.ca [mailto:dm-l-bounces@uleth.ca] On > Behalf Of Peter Robinson > Sent: Friday, April 08, 2005 12:11 AM > To: dm-l(a)uleth.ca > Subject: RE: [dm-l] what xslt can't do..? > > The Digital Medievalist List (see end of message for contact > information and project URLs). > > ---------------------------------- > Peter (Binkley) has already pointed out the problems with the > XSLT approach he took. > I think even the fix he suggests, of returning a stripped > node fragment, would still lead to performance problems (for > instance..to pull a single page say out of the Hengwrt > Chaucer you would need every time to read the WHOLE document > to create the node sets for ALL pages, just so you could > extract the node set for just one, every time). There is > also a problem with the last page. Presume that we have, > indeed, what we always have: a whole bunch of other text in > separate divs in the document after the last page, as below. > Here is a new div containing an > appendix: > Peter B's approach would include that text, wrongly, in the > node set for the last page. I'm sure this could be fixed > (get the node sets only for the pbs in the div holding them) > but it is just yet another complication. (Incidentally, the > best solution to the 'missing last end of page' problem, and > ideed to various other problems, is what Steve De Rose > describes as 'trojan milestones': see > http://www.mulberrytech.com/Extreme/Proceedings/html/2004/DeRo > se01/EML2004DeRose01.html). > > I think too there is some misconception about just how the > system I use > (Anastasia) > would cope with this problem. Peter B(inkley) suggests it is > some kind of 'coded project', apparently using Java, while > Peter B(aker..this is ridiculous) seems to think I would be > using raw C. For the many who do not seem to have looked yet at > Anastasia: it provides a tcl scripting environment which lets > you manipulate XML easily in some ways (including ways very > important to us) which XLST finds difficult. Particularly -- > the whole focus of this discussion -- it is straight-forward > in Anastasia to manipulate a document according to > alternative hierarchies implicit in the element relations: so > you can show just one column or one page of a text otherwise > structured in hierarchical divisions. > > Thus, the whole Anastasia code to pull out the first two > pages of this document looks like this: > > proc begin {book me stylename} { > global pagecounter startEl > set pagecounter 0 > set startEl [findSGElement "stag(\"pb\") with attvalue(\"1\")"] } > > proc pb {me context} { > global pagecounter finish > if {$pagecounter=="2"} {set finish 1} > incr pagecounter > } > > Folks, that is all there is. The 'begin' function finds the > first page by its attribute value (there are other ways one > could do it, to be sure that this is the first page) and sets > Anastasia to start reading the document right there. > The 'pb' > function counts every page every time it hits a pb: when the > pagecounter reaches '2' > it has read two full pages and setting the 'finish' variable > to 1 stops the output. > One could include a few more proc functions to format the > headings, paragraphs, etc, or one could identify the last > page by attribute value, but that is all. > And it does this just as quick for a document with 100000 > pages as one. > > I don't have a prejudice against XSLT, which seems a fine > tool for doing most of the things one wants to do with XML. > But that does not mean it can do *everything* equally easily > (which is how this whole thread started, with musings on its > limits as a typesetting language). Some things certainly > Anastasia does much easier, and that is no surprise -- it was > designed just for that. She is open source. Go look at her > on http://anastasia.sourceforge.net Peter R(obinson) > > ***revised document with an appendix after the last page... > <div> > <head>The whole text and all the texts</head> <div> <pb > n="1"/> <head>First text</head> <p n="1">some text starts > here and goes ita<hi rend="italic">lic an<pb n="2"/>d > then</i> we get a pagebreak</p> <p n="2">so the text > finishes</p> <p n="3"> with yet another page <pb n="3"/> and > another page start </p> </div> <div> <head>Second text</head> > <pb n="4"/> <p n="1">here my new text on the next page etc > etc</p> <pb n="5"/> <p n="2">here my new text on the next > page etc etc</p> </div> <div> <p>Now here we have an appendix > and some more text after that</p> </div> </div> > > > > _______________________________________________ > Digital Medievalist Project > Homepage: http://www.digitalmedievalist.org Journal (December > 2004-): http://www.digitalmedievalist.org/journal.cfm > RSS (announcements) server: > http://www.digitalmedievalist.org/rss/rss2.cfm > Wiki: http://sql.uleth.ca/dmorgwiki/index.php > Change membership options: > http://listserv.uleth.ca/mailman/listinfo/dm-l > Submit RSS announcement: http://www.digitalmedievalist.org/newitem.cfm > Contact editorial Board: digitalmedievalist(a)uleth.ca dm-l > mailing list dm-l(a)uleth.ca > http://listserv.uleth.ca/mailman/listinfo/dm-l >

1 0

RE: [dm-l] what xslt can't do..?
by Peter Robinson 08 Apr '05

08 Apr '05

Peter (Binkley) has already pointed out the problems with the XSLT approach he took. I think even the fix he suggests, of returning a stripped node fragment, would still lead to performance problems (for instance..to pull a single page say out of the Hengwrt Chaucer you would need every time to read the WHOLE document to create the node sets for ALL pages, just so you could extract the node set for just one, every time). There is also a problem with the last page. Presume that we have, indeed, what we always have: a whole bunch of other text in separate divs in the document after the last page, as below. Here is a new div containing an appendix: Peter B's approach would include that text, wrongly, in the node set for the last page. I'm sure this could be fixed (get the node sets only for the pbs in the div holding them) but it is just yet another complication. (Incidentally, the best solution to the 'missing last end of page' problem, and ideed to various other problems, is what Steve De Rose describes as 'trojan milestones': see http://www.mulberrytech.com/Extreme/Proceedings/html/2004/DeRose01/EML2004D…). I think too there is some misconception about just how the system I use (Anastasia) would cope with this problem. Peter B(inkley) suggests it is some kind of 'coded project', apparently using Java, while Peter B(aker..this is ridiculous) seems to think I would be using raw C. For the many who do not seem to have looked yet at Anastasia: it provides a tcl scripting environment which lets you manipulate XML easily in some ways (including ways very important to us) which XLST finds difficult. Particularly -- the whole focus of this discussion -- it is straight-forward in Anastasia to manipulate a document according to alternative hierarchies implicit in the element relations: so you can show just one column or one page of a text otherwise structured in hierarchical divisions. Thus, the whole Anastasia code to pull out the first two pages of this document looks like this: proc begin {book me stylename} { global pagecounter startEl set pagecounter 0 set startEl [findSGElement "stag(\"pb\") with attvalue(\"1\")"] } proc pb {me context} { global pagecounter finish if {$pagecounter=="2"} {set finish 1} incr pagecounter } Folks, that is all there is. The 'begin' function finds the first page by its attribute value (there are other ways one could do it, to be sure that this is the first page) and sets Anastasia to start reading the document right there. The 'pb' function counts every page every time it hits a pb: when the pagecounter reaches '2' it has read two full pages and setting the 'finish' variable to 1 stops the output. One could include a few more proc functions to format the headings, paragraphs, etc, or one could identify the last page by attribute value, but that is all. And it does this just as quick for a document with 100000 pages as one. I don't have a prejudice against XSLT, which seems a fine tool for doing most of the things one wants to do with XML. But that does not mean it can do *everything* equally easily (which is how this whole thread started, with musings on its limits as a typesetting language). Some things certainly Anastasia does much easier, and that is no surprise -- it was designed just for that. She is open source. Go look at her on http://anastasia.sourceforge.net Peter R(obinson) ***revised document with an appendix after the last page... <div> <head>The whole text and all the texts</head> <div> <pb n="1"/> <head>First text</head> <p n="1">some text starts here and goes ita<hi rend="italic">lic an<pb n="2"/>d then</i> we get a pagebreak</p> <p n="2">so the text finishes</p> <p n="3"> with yet another page <pb n="3"/> and another page start </p> </div> <div> <head>Second text</head> <pb n="4"/> <p n="1">here my new text on the next page etc etc</p> <pb n="5"/> <p n="2">here my new text on the next page etc etc</p> </div> <div> <p>Now here we have an appendix and some more text after that</p> </div> </div>

4 4

RE: [dm-l] what xslt can't do..?
by Binkley, Peter 07 Apr '05

07 Apr '05

I agree with James (mind if we call you Peter, just to keep things clear?) that a multi-pass approach is likely to be more efficient than mine, just because of the overhead mine incurs in creating nodesets all the time. What my approach needs is a function that takes a node-set and returns a tree fragment containing those nodes and all their ancestors, with non-ancestors stripped out. Does XSLT2 provide such a function? I haven't got into 2 yet. If not, it probably wouldn't be too hard to write up a Java extension to do it. For situations requiring the kind of performance that Peter Robinson is talking about, XSLT will probably always have value only as a prototyping tool, to be replaced by coded projects like Peter's. But I think it has more value as a prototyping tool than Peter R. is giving it credit for. I think a better Java programmer than me (i.e. any Java programmer) would still have taken longer than I did to prototype a solution to Peter's challenge, and would have required more than 63 lines of code to do it. Peter Binkley Peter Binkley, Ph.D., MLIS Digital Initiatives Technology Librarian Information Technology Services 4-30 Cameron Library University of Alberta Libraries Edmonton, Alberta Canada T6G 2J8 Phone: (780) 492-3743 Fax: (780) 492-9243 e-mail: peter.binkley(a)ualberta.ca > -----Original Message----- > From: dm-l-bounces(a)uleth.ca [mailto:dm-l-bounces@uleth.ca] On > Behalf Of James Cummings > Sent: Thursday, April 07, 2005 05:07 AM > To: Digital Medievalist Community mailing list > Subject: Re: [dm-l] what xslt can't do..? > > The Digital Medievalist List (see end of message for contact > information and project URLs). > > ---------------------------------- > > I've always been happy to agree with Peter(Robinson) that > XSLT has some major limitations. I, like Peter(Baker) think > that a solution can be found within XSLT for this problem. > My approach would be, like > Peter(Baker) suggests, to do multiple transforms. > Increasingly I'm doing this not as a set of discrete files > (though the modularity of that is very attractive), but > through using variables in XSLT2 which can then have further > operations applied to them. i.e. creating temporary trees > since you can continue to work on so-called result tree > fragments in XSLT2. But Peter Binkley has solved the > specific problem in his post. > > However, as a general approach, I like to see the first step > as a conversion of one hierarchy to another, so converting > every element in the document to milestone like elements > indicating start and end. The priviledging that set of > milestones that are most important to you for that transformation. > > But the XML could have been encoded as such to begin with > couldn't it? > So perhaps the problem isn't that it can be difficult in XSLT > to transform from one arbitrary hierarchy to another, but > that the choice of hierarchy should be suited to the purpose. > If the aim is to display pages, then priviledge that > hierarchy and break the other ones? > > I've knocked up a quick XSLT1 stylesheet that takes any XML > document as an input, and wraps it in a document element and > creates all other elements (except <head> and <pb/> ;-) ) as > milestone elements indicating their start and end. > > So, passing the text.xml through it, I get: > -------------- > <document> > <div start="true"/> > <head>The whole text and all the texts</head> > <div start="true"/> > <pb n="1"/> > <head>First text</head> > <p start="true" n="1"/>some text starts here and > goes ita<hi start="true" rend="italic"/>lic an<pb n="2"/>d > then<hi end="true" > rend="italic"/> we get a pagebreak<p end="true" n="1"/> > <p start="true" n="2"/>so the text finishes<p > end="true" n="2"/> > <p start="true" n="3"/> with yet another page <pb > n="3"/> and another page start <p end="true" n="3"/> > <div end="true"/> > <div start="true"/> > <head>Second text</head> > <pb n="4"/> > <p start="true" n="1"/>here my new text on the > next page etc etc<p end="true" n="1"/> > <pb n="5"/> > <p start="true" n="2"/>here my new text on the > next page etc etc<p end="true" n="2"/> > <div end="true"/> > <div end="true"/> > </document> > -------------- > Then one could fairly easily use an xsl:for-each-group > solution to group elements by <pb>. For what it is worth > (and it could be done in a more sophisticated and efficient > manner) the XSLT for milestoning a document that I knocked up was: > -------------- > <?xml version="1.0" encoding="utf-8"?> > <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" > version="1.0"> > <xsl:output method="xml" indent="no" encoding="utf-8"/> > <xsl:template match="/"> > <document> > <xsl:call-template name="element-start"/> > <xsl:apply-templates/> > <xsl:call-template name="element-end"/> > </document> > </xsl:template> > <xsl:template match="*" priority="-1"> > <xsl:call-template name="element-start"/> > <xsl:apply-templates/> > <xsl:call-template name="element-end"/> > </xsl:template> > <xsl:template match="head"> > <head> > <xsl:apply-templates/> > </head> > </xsl:template> > <xsl:template match="pb"> > <pb> > <xsl:for-each select="@*"> > <xsl:attribute name="{name()}"> > <xsl:value-of select="."/> > </xsl:attribute> > </xsl:for-each> > </pb> > </xsl:template> > <xsl:template name="element-start"> > <xsl:element name="{name()}"> > <xsl:attribute name="start">true</xsl:attribute> > <xsl:for-each select="@*"> > <xsl:attribute name="{name()}"> > <xsl:value-of select="."/> > </xsl:attribute> > </xsl:for-each> > </xsl:element> > </xsl:template> > <xsl:template name="element-end"> > <xsl:element name="{name()}"> > <xsl:attribute name="end">true</xsl:attribute> > <xsl:for-each select="@*"> > <xsl:attribute name="{name()}"> > <xsl:value-of select="."/> > </xsl:attribute> > </xsl:for-each> > </xsl:element> > </xsl:template> > </xsl:stylesheet> > -------------- > > -James > -- > Dr James Cummings, Oxford Text Archive, University of Oxford > James dot Cummings at oucs dot ox dot ac dot uk > > _______________________________________________ > Digital Medievalist Project > Homepage: http://www.digitalmedievalist.org > Journal (December 2004-): > http://www.digitalmedievalist.org/journal.cfm > RSS (announcements) server: > http://www.digitalmedievalist.org/rss/rss2.cfm > Wiki: http://sql.uleth.ca/dmorgwiki/index.php > Change membership options: > http://listserv.uleth.ca/mailman/listinfo/dm-l > Submit RSS announcement: http://www.digitalmedievalist.org/newitem.cfm > Contact editorial Board: digitalmedievalist(a)uleth.ca > dm-l mailing list > dm-l(a)uleth.ca > http://listserv.uleth.ca/mailman/listinfo/dm-l >

1 0

RE: [dm-l] what xslt can't do..?
by Peter Robinson 07 Apr '05

07 Apr '05

>Now Peter, I'm perfectly happy to take on this problem, but I think we >both know that your demand that the transform be done in one pass makes >it not so much "slightly more of a challenge" as "impossible." But what >would be the problem with doing the transform in two passes, or three, >or four? One could wrap them all up in some Python or Java, and the user >wouldn't know or care. Assuming we can get past this little issue, why >yes, I think it can be done, and I'll be happy to give it a try. Notice >another qualification in my note: "when we've all got lots of time." You know, I think that is my whole point. There are indeed circumstances where the transform solution is very difficult. My document sample is one such. Notice that the first page break occurs some way into the document; and there is no explicit 'end of page' for the last page break. So figuring out the logic, by which you turn the empty page breaks into content-holding elements, is rather non-trivial. The transform solution is also going to be a real problem, for performance reasons, when you have documents of thousands of pages and you need to process them dynamically (*Not* pre-filter them through transforms). As for needing lots of time: if your tools let you do what you want directly with the document as it is, without the need for complex transforms, you don't need it. I give a summary on why the system-we-have-not-named can handle this kind of problem easily, where XSLT can not, on http://anastasia.sourceforge.net/comparexsl.html. And, she-who-we-do-not-name can indeed do many of the things listed as XSLT no-nos on the http://www.dpawson.co.uk/xsl/sect2/nono.html pages (change variable values, create an xpath expression from a variable, move entities from the input to the output file, etc etc). all the best Peter

2 1

what xslt can't do..?
by Peter Robinson 07 Apr '05

07 Apr '05

Peter Baker says... >I must say, though, Peter, that this isn't the first time you've >mentioned things that XSL can't do. I'm not sure I believe that it can't >be done. Someday, when we've all got lots of time, we'll have to have a >programming shootout. You can offer up a problem that you think XSL >can't handle, and you code it in C (or whatever it is you use), and I'll >use XSLT, and we'll see who gets there first. indeed, I have become rather a bore on this subject. And I have several times pointed out that XSLT has great difficulty with what is conceptually a simple task: just show me the text on one page. I have several times set the challenge: somebody, try and do with XSLT what we do for many thousands of pages (in the most basic form; just reproduce what we do for a single page of the Hengwrt Chaucer, for example). I have had some extremely lengthy explanations of how it *could* be done, and I am certainly prepared to believe these might actually work. In the same way, I am sure that with sufficient ingenuity one could use a lawnmower to heat a house. Just, one might find easier ways to do it. So, here is a simple example, then: <div> <head>The whole text and all the texts</head> <div> <pb n="1"/> <head>First text</head> <p n="1">some text starts here and goes ita<hi rend="italic">lic an<pb n="2"/>d then</i> we get a pagebreak</p> <p n="2">so the text finishes</p> <p n="3"> with yet another page <pb n="3"/> and another page start </p> </div> <div> <head>Second text</head> <pb n="4"/> <p n="1">here my new text on the next page etc etc</p> <pb n="5"/> <p n="2">here my new text on the next page etc etc</p> </div> </div> So, Peter, here is your challenge. Just make us an xslt file that pulls out just the text on each of the five pages. It would be a nice bonus if each page were to have a header which told us what text there is on each page (for example: page 3 contains 'First text, para 3 -- Second text, head'; page 5 contains just 'Second text, para 5'). To make it slightly more of a challenge: you should do this direct from this sample, and not from a transform of this sample. By the way, notice the problematics about the final page break. Should it be.. <head>Second text</head> <pb n="4"/> <p n="1">here OR <head>Second text<pb n="4"/></head> <p n="1">here OR <head>Second text</head> <p n="1"><pb n="4"/>here Answers on the back of a postage stamp please. all the best Another Peter

4 3

RE: [dm-l] what xslt can't do..?
by Binkley, Peter 07 Apr '05

07 Apr '05

I've just noticed that I hadn't removed some unnecessary lines, evidence of a false start; the stylesheet is now down to 63 lines. Peter -----Original Message----- From: dm-l-bounces(a)uleth.ca on behalf of Binkley, Peter Sent: Thu 4/7/2005 3:33 AM To: peter.robinson(a)dmu.ac.uk; Digital Medievalist Community mailing list; dm-l(a)uleth.ca Subject: RE: [dm-l] what xslt can't do..? The Digital Medievalist List (see end of message for contact information and project URLs). ----------------------------------

1 0

RE: [dm-l] what xslt can't do..?
by Binkley, Peter 07 Apr '05

07 Apr '05

Unless I've misunderstood the challenge, I think this 70-line, single-pass stylesheet will fill the bill: http://www.wallandbinkley.com/robinsonchallenge/paginate.xsl . Peter's XML text is available here: http://www.wallandbinkley.com/robinsonchallenge/text.xml . The output looks like this: <document> <head>The whole text and all the texts</head> <page n="1"> <pageheader>Text 1, para 1</pageheader> <div> <head>First text</head> <p n="1">some text starts here and goes ita<hi rend="italic">lic an</hi></p> </div> </page> <page n="2"> <pageheader>Text 1, paras 1, 2 and 3</pageheader> <div> <p n="1"><hi rend="italic">d then</hi> we get a pagebreak</p> <p n="2">so the text finishes</p> <p n="3"> with yet another page </p> </div> </page> ... </document> The pages are presented in discrete elements, each containing only the text of that page, with all markup preserved and all tags well-formed. The basic mechanism involves using a key to index all the text nodes by their page number: <xsl:key name="text" match="text()" use="preceding::pb[1]/@n"/> It is then easy to create a node-set containing all the text nodes for a given page, like this: <xsl:variable name="texts" select="key('text', $thispage)"/> With that we can process the ancestors of those text nodes to create the output for that page, like this: <xsl:apply-templates select="/div/*[.//text()[count(.|$texts) = count($texts)]][1]"> As it stands this stylesheet is horribly inefficient, since it has to rebuild the node-set of text nodes every time it executes a template (since you can't pass a node-set as a parameter). Perhaps there's a way to move all the processing into the main for-each loop to avoid using templates. I'm not sure I understand why the final page break is problematic. Why would you want anything other than the way it is marked up in the source? (I notice that I've neglected to include the text 2 head in the page header, as in the example "Second text, head", and my punctuation doesn't match that example, but I'm too tired to fix it now.) Peter Binkley peter.binkley(a)ualberta.ca -----Original Message----- From: dm-l-bounces(a)uleth.ca on behalf of Peter Robinson Sent: Wed 4/6/2005 3:13 PM To: dm-l(a)uleth.ca Subject: [dm-l] what xslt can't do..? The Digital Medievalist List (see end of message for contact information and project URLs). ---------------------------------- Peter Baker says... >I must say, though, Peter, that this isn't the first time you've >mentioned things that XSL can't do. I'm not sure I believe that it can't >be done. Someday, when we've all got lots of time, we'll have to have a >programming shootout. You can offer up a problem that you think XSL >can't handle, and you code it in C (or whatever it is you use), and I'll >use XSLT, and we'll see who gets there first. indeed, I have become rather a bore on this subject. And I have several times pointed out that XSLT has great difficulty with what is conceptually a simple task: just show me the text on one page. I have several times set the challenge: somebody, try and do with XSLT what we do for many thousands of pages (in the most basic form; just reproduce what we do for a single page of the Hengwrt Chaucer, for example). I have had some extremely lengthy explanations of how it *could* be done, and I am certainly prepared to believe these might actually work. In the same way, I am sure that with sufficient ingenuity one could use a lawnmower to heat a house. Just, one might find easier ways to do it. So, here is a simple example, then: <div> <head>The whole text and all the texts</head> <div> <pb n="1"/> <head>First text</head> <p n="1">some text starts here and goes ita<hi rend="italic">lic an<pb n="2"/>d then</i> we get a pagebreak</p> <p n="2">so the text finishes</p> <p n="3"> with yet another page <pb n="3"/> and another page start </p> </div> <div> <head>Second text</head> <pb n="4"/> <p n="1">here my new text on the next page etc etc</p> <pb n="5"/> <p n="2">here my new text on the next page etc etc</p> </div> </div> So, Peter, here is your challenge. Just make us an xslt file that pulls out just the text on each of the five pages. It would be a nice bonus if each page were to have a header which told us what text there is on each page (for example: page 3 contains 'First text, para 3 -- Second text, head'; page 5 contains just 'Second text, para 5'). To make it slightly more of a challenge: you should do this direct from this sample, and not from a transform of this sample. By the way, notice the problematics about the final page break. Should it be.. <head>Second text</head> <pb n="4"/> <p n="1">here OR <head>Second text<pb n="4"/></head> <p n="1">here OR <head>Second text</head> <p n="1"><pb n="4"/>here Answers on the back of a postage stamp please. all the best Another Peter _______________________________________________ Digital Medievalist Project Homepage: http://www.digitalmedievalist.org Journal (December 2004-): http://www.digitalmedievalist.org/journal.cfm RSS (announcements) server: http://www.digitalmedievalist.org/rss/rss2.cfm Wiki: http://sql.uleth.ca/dmorgwiki/index.php Change membership options: http://listserv.uleth.ca/mailman/listinfo/dm-l Submit RSS announcement: http://www.digitalmedievalist.org/newitem.cfm Contact editorial Board: digitalmedievalist(a)uleth.ca dm-l mailing list dm-l(a)uleth.ca http://listserv.uleth.ca/mailman/listinfo/dm-l

2 1

tex, unicode, etc
by Peter Robinson 06 Apr '05

06 Apr '05

> > I won't try to cover any of the ground that John > McChesney-Young has > > covered in his post, except to say that that is also my > sense of the > > state of LaTeX right now: support for UTF-8 is still clunky, and > > Unicode/OpenType fonts are not natively supported. To judge > from its > > website the promising Omega project seems to have stalled. > To follow this up: on at least one operating system, matters are rather different. In Mac OS X, there is a quite wonderful TeX implementation named XeTeX: go see http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=xetex. This does Utf-8 right out of the box -- CJK, Thai (with hyphenation tables even!!), Arabic, Mongolian, polytonic greek, just anything as far as I can see. It also seems to work nicely with OpenType font families, etc. It also works seamlessly with LaTeX, including some real tricksy bits of LaTeX (long tables, for instance, spanning many pages). I got this running from bare ground to making Arabic pdfs in about 30 minutes -- you have to install the full TeX, XeTeX, and a graphic UI, TeXShop (which creates pdfs straight out of the TeX, which is very cool), but all this is nicely explained on the XeTeX site. I don't yet know whether XeTeX works ok with the EDMAC critical edition macros, but there's no reason why it should not. I'd have to say that TeX is still, after all these years, just the best typesetting system I have seen. I agree with Dan, that it is annoying in that appartently simple things (changing page sizes!) can be hard to do in TeX. But boy, does it make up for it in its power to make really complex, really beautiful pages. I am currently setting some 10,000 pages of a historical edition (about 9,000,000 words) from XML, and for a task like this, TeX is incomparable. We use our own transformer tool to translate the xml into tex source, and away we go (as always, we have to do dicy things like make up pages from bits of other pages mosaiced together, with lots of text bounded by empty elements, so XSL does not cut it for us). all the best Peter

3 2

RE: [dm-l] TAN: Unicode, XML, and LaTeX
by Binkley, Peter 04 Apr '05

04 Apr '05

I've used FOP for some DocBook-to-PDF transformations and had no trouble with it. But I haven't pressed it very far, and I don't think there were any tables involved. There's a compliance chart at the FOP site: http://xml.apache.org/fop/compliance.html Peter Peter Binkley Digital Initiatives Technology Librarian Information Technology Services 4-30 Cameron Library University of Alberta Libraries Edmonton, Alberta Canada T6G 2J8 Phone: (780) 492-3743 Fax: (780) 492-9243 e-mail: peter.binkley(a)ualberta.ca > -----Original Message----- > From: dm-l-bounces(a)uleth.ca [mailto:dm-l-bounces@uleth.ca] On > Behalf Of Daniel O'Donnell > Sent: Sunday, April 03, 2005 09:45 PM > To: Peter Baker > Cc: Digital Medievalist Community mailing list > Subject: Re: [dm-l] TAN: Unicode, XML, and LaTeX > > The Digital Medievalist List (see end of message for contact > information and project URLs). > > ---------------------------------- > What scared me off XSL-FO was a recurring theme on TEI-L that > suggested that XSL-FO engines are too expensive or too poor > to be used very much by academics. In particular, it is > claimed that the free ones don't do tables very well, and the > ones that do do tables well are expensive. > I'll take a look at the ones you suggest; I'm also looking at > Context, though, as somebody noted, it ain't consumer > friendly in its set up. On TEI-L, it has often been suggested > that XML-ers can see LaTeX largely as a PDF engine. > > I must say that two days intensive work with LaTeX has left > me with mixed feelings. On the one hand, I can produce a very > neat looking articles suitable for immediate publication in > Phys Rev Letters. On the other hand, the whole system seems > pretty old fashioned. It claims to separate content and form, > but it doesn't really: all markup is basically format > oriented. It looks like the system the original HTML design > was probably based on. SGML and XML are a conceptual leap > forward, although SGML suffered from a terrible lack of > delivery mechanisms, and XML seems to be suffering from the > lack of a consumer oriented Print/PDF mechanism. > > So in short, I think as an old SGML/XMLer, I'd rather stick > with a concept I understand (trees and XPATH), that convert a > tree model to a process-model like LaTeX seems to be; but I'd > also prefer my output to be cheap and easy to produce, > without limitations (for example) on the type of tables I can > produce. My immediate goal for learning some kind of XML > > typesetting language is to see if I can automate the > production of Brodart call-number stickers for my personal > library (I'm a dork, as my neighbour has repeatedly noted), > something that requires me ultimately to set a very unusual > page size. This is not hard to do in XSL-FO, as far as I can > tell, but quite difficult in LaTeX: another reason to stick > with FO, if I can. > > Jargon Watch: > XSL: eXtensible Stylesheet Language (a language for > converting XML to output formats) > XSL-FO: a language for converting XML to (amongst other > things) print and PDF TeX and LaTeX: a typesetting language > (and variant) used by natural scientists (for the most part) > to typeset articles and books. > XML: an HTML-like language used for encoding text structurally. > SGML: an early version of XML > HTML: the language used to encode web pages > XPATH: an XML standard > TEI-L: mailing list of the Text Encoding Initiative > > -dan > > > > > > Peter Baker wrote: > > Dan, > > > > I won't try to cover any of the ground that John > McChesney-Young has > > covered in his post, except to say that that is also my > sense of the > > state of LaTeX right now: support for UTF-8 is still clunky, and > > Unicode/OpenType fonts are not natively supported. To judge > from its > > website the promising Omega project seems to have stalled. > > > > I'm wondering if you've considered XSL-FO as a way to get > from TEI to > > PDF. Apache's FOP (see http://xml.apache.org/fop/) is > supposed to be a > > good free implementation. If I recall correctly, earlier > versions of > > FOP used TeX or LaTeX to output PDF files, but now it > outputs directly > > to PDF. There's a great advantage to staying within XML to do a job > > like producing a PDF: you use an XSLT script to output an > FO file, and > > then send that to FOP. > > > > There are also commercial products for working with FO (here's one > > with a free academic license: > > http://www.renderx.com/download/academic.html), > > and some of them sound far easier to use than FOP. Being rather > > perverse, I'd probably stick with FOP myself. I'll bet there's some > > experience getting TEI to FOP on this list. > > > > Peter > > > > Daniel O'Donnell wrote: > > > >> The Digital Medievalist List (see end of message for contact > >> information and project URLs). > >> > >> ---------------------------------- > >> Hi all, > >> I've been playing with LaTex (actually MikTex) as a TEI2PDF > >> conversion method, and I have a question about unicode support for > >> LaTex that members of this list might have a better handle on than > >> the TUG group seems to. > >> What is the best method of handling UTF-8 XML code in LaTeX2e? > >> Recent discussion (i.e. Feb 2005) on the various mailing lists > >> archived at TUG seem to suggest this is something that is > difficult > >> to do and won't really be resolved until LaTeX 3. I'm sure members > >> here have some practical experience. > >> Thanks. > >> -dan > >> > >> P.S. I'm cross posting this in tei-l; apologies for the > double messages. > > > > > > > > -- > Daniel Paul O'Donnell, PhD > Associate Professor of English > University of Lethbridge > Lethbridge AB T1K 3M4 > Tel. (403) 329-2377 > Fax. (403) 382-7191 > E-mail <daniel.odonnell(a)uleth.ca> > Home Page <http://people.uleth.ca/~daniel.odonnell/> > The Digital Medievalist Project: <http://www.digitalmedievalist.org/> > > > _______________________________________________ > Digital Medievalist Project > Homepage: http://www.digitalmedievalist.org > Journal (December 2004-): > http://www.digitalmedievalist.org/journal.cfm > RSS (announcements) server: > http://www.digitalmedievalist.org/rss/rss2.cfm > Wiki: http://sql.uleth.ca/dmorgwiki/index.php > Change membership options: > http://listserv.uleth.ca/mailman/listinfo/dm-l > Submit RSS announcement: http://www.digitalmedievalist.org/newitem.cfm > Contact editorial Board: digitalmedievalist(a)uleth.ca > dm-l mailing list > dm-l(a)uleth.ca > http://listserv.uleth.ca/mailman/listinfo/dm-l >

1 0

TAN: Unicode, XML, and LaTeX
by Daniel O'Donnell 03 Apr '05

03 Apr '05

Hi all, I've been playing with LaTex (actually MikTex) as a TEI2PDF conversion method, and I have a question about unicode support for LaTex that members of this list might have a better handle on than the TUG group seems to. What is the best method of handling UTF-8 XML code in LaTeX2e? Recent discussion (i.e. Feb 2005) on the various mailing lists archived at TUG seem to suggest this is something that is difficult to do and won't really be resolved until LaTeX 3. I'm sure members here have some practical experience. Thanks. -dan P.S. I'm cross posting this in tei-l; apologies for the double messages. -- Daniel Paul O'Donnell, PhD Associate Professor of English University of Lethbridge Lethbridge AB T1K 3M4 Tel. (403) 329-2377 Fax. (403) 382-7191 E-mail <daniel.odonnell(a)uleth.ca> Home Page <http://people.uleth.ca/~daniel.odonnell/> The Digital Medievalist Project: <http://www.digitalmedievalist.org/>

3 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

dm-l