2 Replies Latest reply on Oct 15, 2012 6:00 AM by Variable Array

    XML and tables - to replace Framemaker

    Variable Array

      Hello community,


      I am new here and come with this issue with the hope for some insight into InDesign cs 6 for mac:


      We are trying to move away from framemaker, as it is no longer supported for the mac platform and our G5s are getting old.


      Now from our db we exported hundreds of .mif files, which we later made into reference books with framemaker. Table formatting was amazingly flexible. Can we achieve the same by employing xml outputs and somehow get them working in InDesign?


      We have 6 different types of rows for almost each table, some have 1 column, others have 4. Except for the first and second one, which are always of the same format in any given table, the other rows will vary in their sequence of appearance and in their quantity. One table could have 4 rows and another one up to 300 rows.


      These tables would then be made into a book. Various table of contents would be built from keywords in specific cells/rows, such as the first row content of any table and the 3rd cell of row type 4, etc.


      We can export from the database (4th dimension) many different formats, so it could be xml just as it currently is .mif.


      But how do we get all this into InDesign? What is the right format to accomplish this? I watched a video explaing templates for business cards, but our tables sometimes are short and sometimes are very long, so we can not build templates really — I would venture to say.


      And is there a handy way for this framemaker feature: When one table runs across 2 or more pages, the first row, a header, would not only repeat the title but also add additional text "cont'd" in small print, so the user knows this carries on from the previous page.


      Thanking you in advance for any insight I remain


      a variable array (Pete)

        • 1. Re: XML and tables - to replace Framemaker

          Pete/Variable Array,


          We recently incorporated XML data importing to build data tables in Indesign documents (in our case, postcards containing large data tables, and the cards were being generated by the thousands from a backend system over the course of the project).


          I can tell you that tables in XML are very tricky but certainly powerful (and flexible enough for what it sounds like you're attempting) once you get past a few hurdles.


          When starting this project I strategized that I could create a document with a table, cell styles, paragraph and character styles all in place and styled as I wanted within Indesign and export XML, look at that resulting XML and determine how to format new incoming XML. This wasn't too effective because the exported XML:


          1. contains many items you don't need


          2. doesn't contain important details you will need


          So lots of online research later-- I've learned a few things I can share, and I'll be as concise as possible here but hope to give you at least a starting point/direction for your further research.


          Tables can be in your templates as placeholders for incoming XML data if you don't plan to change the columns (number of columns, widths) beyond spanning across more than one of your (all fixed width) columns for certain cells. Importing XML data into existing fixed width tables is pretty straightforward.


          - If you need flexibility in column widths and number of columns, or styles beyond header/body, it's best to bring in the columns from scratch in your XML


          - in order to build columns from scratch take advantage of 2 namespaces in your XML--4.0 AND 5.0, and make sure both of those are present in your table tag attributes:


               xmlns:aid="http://ns.adobe.com/AdobeInDesign/4.0/" xmlns:aid5="http://ns.adobe.com/AdobeInDesign/5.0/"


          One of the red herrings that kept getting in the way of success was that even in Indesign CS5, you can export XML and it will NOT contain the 5.0 namespace in the table attributes.


            - aid will enable simple tags for your table cells such as aid:table="cell", aid:ccolwidth=, aid:crows=, aid:ccols=, aid:pstyle= (for paragraph style), and any strings of text you need to style with

            your Indesign document's character styles, cstyle (aid:cstyle="MyItalicTextStyle" for example)


            - aid5 will add an important tag for styling cells in your tables (with your existing Indesign cell styles) for rows you wish to style differently on incoming data, such as



          We started by mapping certain XML tags to cell styles in the Indesign template, but in the end you can get by with importing these attributes in the data using cellstyle and pstyle. This came in handy when we had a highlighted style of cell but needed it to contain bold text in some cases, and regular weight text in others, without having to create a duplicate cell style in Indesign.


          If you haven't already steeped yourself in XML that Indesign spits out when you "export XML" from the XML structure menu, this may all sound foreign, but hopefully will make sense once you get into breaking down the code into parts you can use.


            - tag the text box in the Indesign template's structure (create tags in Window > Utilities > Tags and apply them with your text box selected) with the same named tag that will enclose your XML table tag. So if you have more than one table in the document, clearly you will not be restricted to using the tag "Table". Your XML must match the Structure pane's structure exactly in order. So if you have a tag at the very top of the document structure, even if it is referencing a footnote in the Indesign document, you must have it at the very top of the XML, in sequence with the other tags your document is importing. * If adding a partial text piece in a text block, tag placeholder text (using ...create tags in Window > Utilities > Tags and apply them with your text box selected). I found "Edit > Edit it Story Editor", or cmd/ctrl-y) to be easier to work with than selecting text in a copy block. I also found it necessary to use a tag "staticText" which I created in Indesign and applied to all text that was not being replced (but lived between text that was being replaced) to help keep text from disappearing when sandwiched between text dynamically replaced from XML. I did not have the "staticText" tag in my XML doument, so it got ignored, but the text in the document contained in such a tag was left in tact when using the import option "merge content", in the import options. Also, "do not import whitespace-only elements" needs to be selected in the import XML options pane, or incoming data will potentially ruin your template by putting in line breaks and spaces where they don't belong.


          When testing/adjusting styles in the Indesign document, I went through hundreds of manual "import XML" rounds where I imported the sample XML document (which would ultimately get imported using applescript once our flow was built to do everything automatically) and adjusted my styles to fit the content as flexibly as possible. During these rounds, I encountered the very frustrating problem of importing data and having some local style in the document override the styles present in the XML data. An example would be that I had a table with 3 rows and one row had highlighted (color) cell fill, and yet another had bolded text with the highlighted color. This was accomplished through cell styles and paragraph styles being imported. However, on manual import, NONE of the styles took. In fact, the basic font wasn't even showing up trial after trial. This only seconds after initially trying the import with success.


          It turns out that XML imports are VERY prone to style overrides in character styles or any other style selected in your visible style palettes at the time you import... so to keep from pulling out your hair, be very sure you have no item selected (text box, picture etc.) in your Indesign document when you import (by selecting NONE or cmd/ctrl-shift-a) and also, more importantly, DESELECT any styles from your style palettes! Likewise, be careful not to apply a style  to the empty text container that will hold your imported table --in particular, do not accidentally apply a Character style, which will override any imported style.


          Oh, and I forgot to emphasize structure. At least in the templates I created, tables were always nested in a text block, somtimes two or three tables in the same block (so if one table grew, the next table would move down on the page, etc) I might have the enclosing tag "data" applied to my main text block that will contain three or more tables, and within that structure tag on my XML, I will nest 3 tables in a row, each with its own name... for example, my first table tag was

          <Summary xmlns:aid="http://ns.adobe.com/AdobeInDesign/4.0/" xmlns:aid5="http://ns.adobe.com/AdobeInDesign/5.0/" aid:table="table" aid:trows="3" aid:tcols="2">

          followed by

          <Table xmlns:aid="http://ns.adobe.com/AdobeInDesign/4.0/" xmlns:aid5="http://ns.adobe.com/AdobeInDesign/5.0/" aid:table="table" aid:trows="8" aid:tcols="6">


          <Legend xmlns:aid="http://ns.adobe.com/AdobeInDesign/4.0/" xmlns:aid5="http://ns.adobe.com/AdobeInDesign/5.0/" aid:table="table" aid:trows="1" aid:tcols="1">


          The XML data had the <data> tag to signal the targeted text box, and nested within that tag were the tags comprising the tables, and table data nested within each of those...



                    <Cell aid:table="cell" aid:ccolwidth="92"....>my cell data</Cell>

                    <Cell aid: table="cell" aid:ccolwidth="120"....>my longer cell data</Cell>

                   [... more cells as needed, to complete the table]




                    <Cell aid:table="cell" aid:ccolwidth="92"....>my cell data</Cell>

                    <Cell aid: table="cell" aid:ccolwidth="120"....>my longer cell data</Cell>

                   [... more cells as needed, to complete the table]




                    <Cell aid:table="cell" aid:ccolwidth="92"....>my cell data</Cell>

                    <Cell aid: table="cell" aid:ccolwidth="120"....>my longer cell data</Cell>

                   [... more cells as needed, to complete the table]



          Notice all tables don't have to use the tag "Table" but anything you want to be a table must be identified as a table with the opening tag attributes I have included ...declaring the namespace and using aid:table="table".


          Hope this helps but feel free to ask for a specific detail if I haven't covered it deeply enough above.

          PS reading your question again, I see that one concern is tables flowing onto additional pages. Beyond postcards, we also developed sell sheets which had a different structure and could take up more than one page. I had a text block that was linked to an additional page's text block. Yes, the headers were copied when the table flowed to the adjacent text block as long as you've identified Headers in your XML (aid:theader="")... Kudos to Adobe for thinking this through. But as far as "Continued" text appearing on the bottom, I had that as static text on the first page (and I imagine could be on the master for the second and subsequent pages) but I had to create 2 templates... one for 1 page sell sheet, and one for a front/back sell sheet. I suppose there could also be a third template for 3 or more pages... utilizing master pages that get added automatically, with linked text box and text at the top/bottom saying "continued" in appropriate places.


          We had logic in place on the back end (spitting out the XML data) directing the incoming XML to one of the two templates (A or B) based on number of data rows in the body of the table "if more than 30 rows, use template B".  I realize this is not the answer for all needs though, if you have an existing need for fully automating the process, but if you have someone deciding if it will fit and manually adding master pages of one kind or another, it might be the kernel of an idea that might work with a little more thought.


          Message was edited by: regina63


          Message was edited by: regina63 for accuracy

          • 2. Re: XML and tables - to replace Framemaker
            Variable Array Level 1

            Thank you very much indeed for your detailed reply and sharing your insight, regina63.


            I can see, that for the current project we need to rely on old and trusted Framemaker; however before we go about the things in the coming year there will be a major rethinking process.


            I truly appreaciate your valuable information and thank you for your time in writing it down.