Two-page layout in Structured FrameMaker

[4everJang]

Hello all,

I have created lots of books with a two-page layout (images on the left pages, text on the right). This layout was originally developed in the 1960s and is excellent for the machinery business but hardly used anywhere else. I have created all my documents with two flows, one connecting all the left pages where images and captions are placed, and one connecting all the right pages where the text goes. As FM does not support this two-page layout, I have to manually add pages and connect the frames when the chapter gets longer.

Of course I would like to convert everything to Structured FrameMaker, but even unstructured FM does not support the two-page layout, and I don't want to start using structured FM in docs that have two independent sets of frames - it would defeat the purpose of converting to structured FM.

My question is: is there anyone out there who has done some work on two-page layouts using an EDD that emulates this layout in a single flow ? The EDD would have to force images to the left pages and text to the right pages as much as possible. If there are restrictions or special instructions required for the author, that is not a big deal. I am researching the possibility to create this type of EDD, so any suggestions would be welcome.

Thanks for any suggestions

Jangli

[frameexpert]

Hi Jang,

The way I do it is to anchor the image paragraphs in a sidehead area, and the rest of them in the main text column. This gives you a side-to-side layout in a single flow. If you need more help with this, please contact me offlist. Thanks.

Rick Quatro
rick at frameexpert dot com
585-659-8267

[MarttiP]

Hi Jang,

I've done it once..ages ago with FM 5.6 and SGML. The application was a "per product" part catalog with explosion images on the left page and corresponding part catalog table rows on the right page from SGML source data that contained all different product data.
The customer used a fixed set of image sizes (5 different if I remember right). We developed a state machine algorithm (we used the french Balise sgml processor) that determined how many images could fit on the left page and how many can be put on the left page based on the number of part rows on the right page (either the size of graphics or the number of part rows exceeds the available page area thus causing a start of a new left/right page sequence).

We got it working well, because we were able to calculate what fits on paper in SGML (table rows always had only one line of text and the left page image sizes were fixed) and then just constructed the necessary SGML tags to control page breaks.

The problem with the approach was that the page breaks needed to be generated "blindly" and it assumes things like part info fitting to a single row etc..overflows in either pages caused the lost of sync..

BR, Martti

[Michael_Müller-Hillebrand-basb]

Jang,

I guess I would evaluate a single-page layout with a wide side-head area, as Rick suggested, and add any page numbers as a post-processing step using FrameScript or Acrobat.

- Michael

[4everJang]

Hello Michael,

If I understand you (and Rick's earlier post) correctly, or if I translate the idea to what my customer would require, I would have to use the following procedure:

1. Make all files single-sided on A3 size landscape, with the usual header and footer artwork on the left and right pages as if they were two A4 portrait pages. Then create a side-head area that spans the entire left page.

2. Simply write my text in the text flow to the right and place images in the side-head aligned to the left.

3. Post-process the A3-sized landscape pages into A4-sized portrait pages by cutting each page in two.

4. Fiddling around with the page numbers so that they count twice as fast as the original.

5. Making sure the cross-references are corrected because of the changed pagenumbers.

I am not sure how to automatically do step 3 and 4. Any ideas ?

Ciao

Jang

[Lynne A. Price]

Jang,

1. 
   
2. The advantage of the side-head approach that's been suggested is that graphics would appear not just on the page to the left of the associated text, but adjacent to that text. If that degree of placement is not necessary, you can try using paragraphs that are set to start at the top of left or right pages and using them to manually control the page breaks. Still requires manual intervention, but you won't need to add pages and connect text frames manually. For example, you can have a paragraph format with the tag LeftPage that starts at the top of the next left page. Set its line spacing and space below to 0pt so it won't take up space. After inserting a LeftPage paragraph, add the paragraphs with the graphics for that page. Then insert a RightPage paragraph which is similar to LeftPage but starts on a right page. Then insert your paragraphs with text.
   
3. Although a well-written EDD can make it a lot easier for the user to obtain the formatting, the formatting capability of structured and unstructured documents is the same. Thus, you can't achieve anything with an EDD that you can't in an unstructured document. Before designing an EDD, therefore, I suggest you decide how you will use FrameMaker's formatting capability to obtain the desired appearance. The EDD can then help apply that format automatically as you create or edit your documents.
   
4. If your chosen approach requires updating of things like pseudo-page numbers that increment twice on each FrameMaker page or the associated cross-references, you might need to use the FDK or FrameScript to automate them. In this particular case, if you decide to use the side-head approach, you might be able to avoid doing so with an "invisible" list. For example, instead of numbering pages in background text frames defined on the master pages, you might use empty list items defined on the body pages. Such an approach still requires you to control the page breaks manually. If doing so is not natural with the type of material you are publishing, you can use the FDK or FrameScript to control page breaking.
   

--Lynne

[Michael_Müller-Hillebrand-basb]

I really like the way Lynne answers questions [I am unsure of the correct adjectives to use here].

Many ideas mentioned in forums like this are like a shot in the dark and simply show one option. As you know (and I repeat it for other readers), there is more than one way to do it (TIMTOWTDI), not only with Perl.

It is my consulting experience that the product structure and therefore the documentation structure and/or constraints are different in each and every company. This is also part of the fun for me in this industry. To find the best way (best according to whatever is the most important factor) is a matter of experience and a lot of thought put into the subject.

As Lynne put it: You cannot escape the limitations of whatever DTP software you use, but using carefully designed processes and some API programming you can get results that you would not consider doing manually. And then the solution might look as if a new feature had been added to the software.

- Michael