[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

[xsl] Re: XSL:FO approach for facing-page translation


Subject: [xsl] Re: XSL:FO approach for facing-page translation
From: Martin Holmes <mholmes@xxxxxxx>
Date: Fri, 07 Feb 2014 13:27:23 -0800

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