Skip to main content
M
mramshaw1-Visitor
1-Visitor
September 14, 2011
Question

WYSIWYG for tables in Editor view?

  • September 14, 2011
  • 55 replies
  • 11926 views

Several of our users are complaining that tables in the Editor view don't look like they do when composed in a print preview. Tables have no identation in our editor view but they have the standard 1" margin when you do a print preview and I was wondering if there was any way to have the indentation in the Editor view as well, as well as make it more WYSIWYG looking. I know it's last century technology 🙂

    55 replies

    Show previous replies
    M
    mramshaw1-VisitorAuthor
    1-Visitor
    October 14, 2011

    I thought I'd resurrect this thread with another question relating to WYSIWYG. Users are complaining that in tables they cannot see a page break when the table spans across pages like in Word. Is there any way to do this without a forced page break?

    N
    naglists1-Visitor
    1-Visitor
    October 14, 2011
    Not within the Edit Window. In the Edit Window, though, Editor has no
    concept of a printed page so where the page breaks fall is unknown, let
    alone un-shown.

    Someone mentioned having a customized table output preview app that may /
    probably has it (Gareth?). Not sure how it can without rendering at least
    from the last force page break before the table.

    S
    steve.thompson41-Visitor
    1-Visitor
    October 15, 2011
    We had a customer who needed XML with page breaks that imitated the printed page, to simplify their translation efforts. This is possible, to some degree, using Print Composer, but is not supported in PE.

    It uses the "atipl tags" noted (and info linked) in Help # 722. It does "accommodate" tables, but there are a few caveats. The Help entry is about line numbering, but you will note that it mentions page numbers "displayed in the Edit window".

    It required some adaptation of the ACL found in their "line numbering application", so it's not a simple matter of loading and using the application, but can be accomplished with brief study of the Help and the linked "atipl" information.

    HTH,
    Steve Thompson
    +1(316)977-0515
    G
    GarethOakes16-Pearl
    16-Pearl
    October 17, 2011
    Hi Mike,



    I think you'll find this opens a can of worms (nest of snakes?). Arbortext
    screen view and the printed page are entirely divorced from each other. The
    guiding paradigm is that authors should never worry about the printed page,
    but concentrate on the subject matter (authored content).



    Tables, of course, throw a hairy curveball at that model because editing XML
    tables is all about knowing what size they are going to be, where the
    columns will fall and so on. We have found in our experience that a good
    halfway house is to have regular editing in Arbortext Editor but for tables
    enable a "table preview" feature. This feature extracts the currently
    selected table from the XML and sends it through print composition,
    displaying the composed result to the author/editor.



    The catch here, of course, is you are not seeing the true pagebreaks that
    will occur in the printed output, but it turns out that most of the time
    that isn't as important. The fact that users can play with the table
    rotation and table/column widths is good enough. They can then get a feel
    for the vertical size of a table and make decisions accordingly (without
    necessarily seeing the precise page break that will occur in the final
    output).



    The good news is that Arbortext print composition can do a fairly good job
    at handling page breaks in tables (eg. re-inserting table column heads and
    so on). The so-called "deepcontentsplitting" can be a bear but I suspect in
    your case the table preview feature would be good enough to address the
    concerns you have encountered. BTW, the table preview feature is not an
    out-of-the-box Arbortext thing. We have always had to write custom code to
    get that working.



    Cheers,

    Gareth



    PS. while on this topic, I can't help but describe the other radically
    different way to handle printed XML tables. What you have to do is disallow
    authors/editors from specifying table/column attributes for the widths and
    so on. This means you are not allowing them to make decisions about the
    table appearance.



    Instead: you force the print composition system to make all the decisions
    required to produce a correctly formatted table. This is an extremely
    complex task for a print composition system to perform and we have only ever
    had that working with APP/3B2 (Arbortext Advanced Print Publisher). It took
    a lot of blood, sweat and tears. It is really cool when it works though!!


    M
    mramshaw1-VisitorAuthor
    1-Visitor
    October 17, 2011

    Thanks for the responses all! This is also supposed to be accomplished automatically without hitting a button but that seems impossible as I also can't limit what to do with the table. It looks like the best I could do is write something like the suggested table preview feature. We use atipl tags for line numbering with different doctypes but never display them as that seems to frighten and confuse the user, we go through a whole custom thing where we add the atipl tags for print/preview output and then strip them off immediately. I guess I could use them and leave them on the screen for this case.

    Terms & ConditionsAccessibility statement