[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XSL:FO approach for facing-page translation

Subject: Re: XSL:FO approach for facing-page translation
From: Martin Holmes <mholmes@xxxxxxx>
Date: Fri, 07 Feb 2014 13:27:23 -0800
 Re: XSL:FO approach for facing-page translation
On 14-02-07 11:27 AM, Eliot Kimber wrote:
The only way I can think of to do this would be a multi-pass process that
operates on the intermediate area tree. If you emitted both language
streams as separate flows, one for verso pages and one for recto pages,
where you included IDs on blocks to allow you to correlate the two
language versions, you could then examine the area tree to see for each
pair which was deeper and set the vertical extent of the corresponding
block to match. Re-rendering the two flows should then result in them
being properly synchronized.

See Tony Graham's paper from last year's Balisage for implementation
guidance:
http://www.balisage.net/Proceedings/vol10/html/Graham01/BalisageVol10-Graha
m01.html

Very interesting paper indeed. As far as I can see, one rendering pass is done and saved as a file, which is then passed to another rendering pass; that then decides whether the results of the former pass dictate that a different output arrangement should be used.


I can see this working, but it would presumably have to be recursive, because the results of each individual page would dictate what's going into the rendering of the next page. So:

Pass 1: render page 1 of the original and the translation, and save the results (but how to know where to stop? you'd have to do the whole thing).

Pass 2: read the results of pass 1 and compare the first page of each language. Select the largets number of paragraphs to render which allows for all of them to be completed on both pages. Render those two pages and store the results to a file. Then render the remaining contents of both language versions to another file.

Pass 3: Read the second file from pass 2, and repeat the process.

[...]

The results would be a set of final output files, one for each page-spread; a final pass could then gather those up and output them sequentially.

There's still the problem of large blocks of empty space preceding long paragraphs, and the even worse problem of paragraphs which are longer than a page; those would break the algorithm completely.

Cheers,
Martin


Cheers,


Eliot

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.